Открыть список
Как стать автором
Обновить

Комментарии 12

Имеет большое число признаков распределенного монолита. Но, конечно, и такие системы имеют право на существование
Монолит, микросервисы, как это всё называть — дело десятое. Но если слабая связанность компонентов есть и отказ одного компонента не влечет за собой отказ всего остального — то это прекрасно.
30 микросервисов, каждый в своём репо с отдельным репо для синхронизаций для интеграции порядка 10 систем с первого взгляда выглядит, как оверинжиниринг.

Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?
Помимо задачи интеграции этих систем были и задачи реализации дополнительной бизнес-логики (отчетность плюс заказчик добавил еще несколько достаточно сложных подсистем). Поэтому и получилось так много сервисов.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.
Поэтому мы реализовали перехват и подсчет всех вызовов gRPC на уровне кода на стороне клиента. Когда счетчики подходят к определенному значению, вызывается метод, приводящий к переустановке соединения, и балансировщик OKD задействует незагруженный инстанс сервиса «B».

Почему не использовали настройку maxConnectionAge?
Некоторые методы вызываются довольно редко и сбрасывать соединение по расписанию в их случае бесполезно. В любом случае, это временный механизм, который будет выкинут, как только появится настоящий Service Mesh.
OKD -это когда денег на шифт не хватило? Я конечно могу ошибаться, но статья смахивает на то, как мы за деньги заказчика экспериментами занимались…
В продуктивной среде использовался OpenShift. OKD той же версии использовали в контуре разработки. Заказчик планировал обновление версии OpenShift, но позже, а система была нужна «прямо сейчас».
Не совсем понятно зачем использовать Camel внутри Composer для агрегации ответов от сервисов, это же просто REST запросы. Очень похоже на API Gateway. Не думали использовать CQRS подход с Materialized View, если сложно собирать ответ по кусочкам?
Мы реализовывали вот этот паттерн microservices.io/patterns/data/api-composition.html. В Camel просто удобно реализовывать эту функциональность, каких-то специальных средств он для этого не предоставляет.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.
А можно пример «приоритизации сообщений», чтобы было лучше понятно о чем речь? Почему было не объединить эти два топика в один и не выбрать ключ сообщений таким образом чтобы обрабатывать их в правильном порядке?
В системе произвольно происходят события одного класса, но с разным приоритетом. У сервиса, который должен их обработать, есть конечный пул для обработки этих событий. Нам нужно было производить обработку неприоритетных событий только если в очереди нет приоритетных. Причем желательно без перекладки в сторонние хранилища.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.