Комментарии 12
Имеет большое число признаков распределенного монолита. Но, конечно, и такие системы имеют право на существование
30 микросервисов, каждый в своём репо с отдельным репо для синхронизаций для интеграции порядка 10 систем с первого взгляда выглядит, как оверинжиниринг.
Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?
Интересно, почему не вышло сделать в монорепо и условно 10 микросервисов адаптеров по количеству интегрируемых систем + ну максимум 3-5 сервисов общих? Если не секрет, по какому принципу делили микросервисы?
Помимо задачи интеграции этих систем были и задачи реализации дополнительной бизнес-логики (отчетность плюс заказчик добавил еще несколько достаточно сложных подсистем). Поэтому и получилось так много сервисов.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.
Ушли от монорепозиториев, потому что работали над системой совместно с разработчиками X5. И так было удобнее разделять микросервисы между командами.
Поэтому мы реализовали перехват и подсчет всех вызовов gRPC на уровне кода на стороне клиента. Когда счетчики подходят к определенному значению, вызывается метод, приводящий к переустановке соединения, и балансировщик OKD задействует незагруженный инстанс сервиса «B».
Почему не использовали настройку maxConnectionAge?
OKD -это когда денег на шифт не хватило? Я конечно могу ошибаться, но статья смахивает на то, как мы за деньги заказчика экспериментами занимались…
Не совсем понятно зачем использовать Camel внутри Composer для агрегации ответов от сервисов, это же просто REST запросы. Очень похоже на API Gateway. Не думали использовать CQRS подход с Materialized View, если сложно собирать ответ по кусочкам?
Мы реализовывали вот этот паттерн microservices.io/patterns/data/api-composition.html. В Camel просто удобно реализовывать эту функциональность, каких-то специальных средств он для этого не предоставляет.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.
Решали задачу именно сбора данных с нескольких сервисов в одну модель, поэтому Materialized View на одном из сервисов нам бы не помогли.
А можно пример «приоритизации сообщений», чтобы было лучше понятно о чем речь? Почему было не объединить эти два топика в один и не выбрать ключ сообщений таким образом чтобы обрабатывать их в правильном порядке?
В системе произвольно происходят события одного класса, но с разным приоритетом. У сервиса, который должен их обработать, есть конечный пул для обработки этих событий. Нам нужно было производить обработку неприоритетных событий только если в очереди нет приоритетных. Причем желательно без перекладки в сторонние хранилища.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграционный слой с Kafka и микросервисами: опыт построения операционной CRM контакт-центра торговой сети Пятерочка