В системе произвольно происходят события одного класса, но с разным приоритетом. У сервиса, который должен их обработать, есть конечный пул для обработки этих событий. Нам нужно было производить обработку неприоритетных событий только если в очереди нет приоритетных. Причем желательно без перекладки в сторонние хранилища.
Мы реализовывали вот этот паттерн microservices.io/patterns/data/api-composition.html. В Camel просто удобно реализовывать эту функциональность, каких-то специальных средств он для этого не предоставляет.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.
Некоторые методы вызываются довольно редко и сбрасывать соединение по расписанию в их случае бесполезно. В любом случае, это временный механизм, который будет выкинут, как только появится настоящий Service Mesh.
В продуктивной среде использовался OpenShift. OKD той же версии использовали в контуре разработки. Заказчик планировал обновление версии OpenShift, но позже, а система была нужна «прямо сейчас».
Помимо задачи интеграции этих систем были и задачи реализации дополнительной бизнес-логики (отчетность плюс заказчик добавил еще несколько достаточно сложных подсистем). Поэтому и получилось так много сервисов.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.