Интеграционный слой с Kafka и микросервисами: опыт построения операционной CRM контакт-центра торговой сети Пятерочка

[sse]

Имеет большое число признаков распределенного монолита. Но, конечно, и такие системы имеют право на существование

[swapper9]

Монолит, микросервисы, как это всё называть — дело десятое. Но если слабая связанность компонентов есть и отказ одного компонента не влечет за собой отказ всего остального — то это прекрасно.

[xeeaax]

30 микросервисов, каждый в своём репо с отдельным репо для синхронизаций для интеграции порядка 10 систем с первого взгляда выглядит, как оверинжиниринг.

Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?

[Ivan8b]

Помимо задачи интеграции этих систем были и задачи реализации дополнительной бизнес-логики (отчетность плюс заказчик добавил еще несколько достаточно сложных подсистем). Поэтому и получилось так много сервисов.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.

[Hixon10]

Поэтому мы реализовали перехват и подсчет всех вызовов gRPC на уровне кода на стороне клиента. Когда счетчики подходят к определенному значению, вызывается метод, приводящий к переустановке соединения, и балансировщик OKD задействует незагруженный инстанс сервиса «B».

Почему не использовали настройку maxConnectionAge?

[Ivan8b]

Некоторые методы вызываются довольно редко и сбрасывать соединение по расписанию в их случае бесполезно. В любом случае, это временный механизм, который будет выкинут, как только появится настоящий Service Mesh.

[it2manager]

OKD -это когда денег на шифт не хватило? Я конечно могу ошибаться, но статья смахивает на то, как мы за деньги заказчика экспериментами занимались…

[Ivan8b]

В продуктивной среде использовался OpenShift. OKD той же версии использовали в контуре разработки. Заказчик планировал обновление версии OpenShift, но позже, а система была нужна «прямо сейчас».

[morror51]

Не совсем понятно зачем использовать Camel внутри Composer для агрегации ответов от сервисов, это же просто REST запросы. Очень похоже на API Gateway. Не думали использовать CQRS подход с Materialized View, если сложно собирать ответ по кусочкам?

[Ivan8b]

Мы реализовывали вот этот паттерн microservices.io/patterns/data/api-composition.html. В Camel просто удобно реализовывать эту функциональность, каких-то специальных средств он для этого не предоставляет.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.

[naa]

А можно пример «приоритизации сообщений», чтобы было лучше понятно о чем речь? Почему было не объединить эти два топика в один и не выбрать ключ сообщений таким образом чтобы обрабатывать их в правильном порядке?

[Ivan8b]

В системе произвольно происходят события одного класса, но с разным приоритетом. У сервиса, который должен их обработать, есть конечный пул для обработки этих событий. Нам нужно было производить обработку неприоритетных событий только если в очереди нет приоритетных. Причем желательно без перекладки в сторонние хранилища.