Comments 20
Поддержка таких систем требовала самоотверженной работы десятков специалистов, и все знания были в их головах.
И как оно, после перехода на микросервисы, стало лучше/проще/дешевле?
Стало лучше и проще в плане документации, которая типовая и полная на все микросервисы, и разработчику проще погрузиться в конкретный сервис, чем в большую систему. Многие сервисы переиспользуются на различных системах - тут явное удешевление.
Это "айтишный" ответ. А с точки зрения бизнеса какие-то выгоды получились?
если разрабы не убегают потому что задолбались работать с этим легаси это выгода
Раньше очень многие функции повторялись в различных системах. С микросервисным подходом мы уже сейчас делаем сервисы, которые используются многими системами, даже легаси. На конкретных кейсах видно, что вместо серьёзной доработки 7-8 систем, мы делаем один сервис и простую интеграцию с его API. Как раз сейчас делаем такой сервис по реализации алгоритма расчета веса перехода. Конечно это приносит выгоду бизнесу.
Спасибо за информацию, вынес для себя много заметок.
@WhiteSteelначало хорошее! А расскажите про фронт, точнее про интерфейсы? Как проектировали такую большую систему? Что используете? Как достигли единства логики интерфейса?
А логи-то чем собираете? А то на схеме над сборкой логов - Prometheus. Если эластик - как раскидываете логи отдельных компонент по индексам? Ну если не секрет )
Всегда было интересно в таких случаях узнать про накладные расходы. Насколько замедлилась работа системы из-за задержек сети? Ведь пропихнуть информацию между сервисами - это и в json/из json-а, и передать еще. Намного дольше, чем в монолите. Как с этим на реальном опыте дела обстоят?
Скорость соответствует требованиям бизнеса, нареканий нет. Ранее асинхронное взаимодействие также проходило также через кафку, так что тут координальных изменений нет. А наши монолиты представляли собой в основном БД Oracle и вся логика была там, и тоже были накладные расходы по скорости выполнения запросов, которые требовали оптимизации, нормализации/денормализации таблиц и т.п. Основные узкие места это интеграции с другими системами, а не межсервисное синхронное взаимодействие.
Спасибо за статью! расскажите ещё пожалуйста про сегменты подробнее, как что пилили и по каким критериям, сколько сервисов, как организован платформенный код
спасибо!
Расскажите, пожалуйста, про стек подробнее, если не затруднит.
Если говорить про бэк, то это микросервисы на Java 11, Spring boot. Синхронное взаимодействие через REST, асинхронное - Kafka. На фронте обычно React, дизайн система и библиотека компонентов про которые потом еще расскажем. Довольно много используем NiFi, на некоторых проектах Redis. БД на уровне сервисов обычно Postgres, легаси системы на Oracle. Для ряда специфичных задач применяем Cassandra, ClickHouse, Hadoop. Обо всем этом постараемся рассказать в следующих статьях.
Скажите пожалуйста, про планируемые итоги распила на микросервисы: планиурется сделать единую MES, или так и останутся на каждое производство что-то свое? А ведь это может помочь решить проблему с разными компонентами КМК
Единая MES сразу не получится и не факт, что она необходима. Мы стараемся сейчас выделить переисползуемые и инфраструктурные сервисы, которые могут использоваться различными MES'ми. Определенное количество прикладных сервисов скорее всего будет писаться под конкретные цеха и системы, но мы стараемся свести эту долю к минимуму за счет переиспользования и конфигурирования существующих сервисов.
Безусловно, есть специфика каждого из производств, но ее можно перенести в соответствующие специфике модули, и вызывать через коллбеки/декораторы. Но общий поток обработки информации можно же унифицировать? Я говорю не об архитектуре уровня инфраструктуры, а об архитектуре в более прикладном варианте, общей парадигме построения MES-систем.
Иначе легко можно построить вроде общую архитектуру, но работать будет по разному. Гипотетический пример: все сиситемы используют kafka для передачи событий, но одна система публикует всю информацию, связанную с ссобытием, вторая - изменения, третья, только идентификатор объекта, с которым произошло событие (а за изменением обратитесь к системе источнику). Не опасаетесь оставить после себя такой разномастный подход?
Как мы выбирали архитектуру и переносили 20-летние монолиты промышленного гиганта на микросервисы