Использование Apache Camel в микросервисной архитектуре

Мне очень трудно понять, почему Enterprise Service Bus, фундаментальный монолит, может использоваться в микросервисной архитектуре.

ESB имеет несколько возможностей, полезных для микросервисной архитектуры. Он позволяет:

• передачу и преобразование сообщений, см. Корпоративные интеграционные шаблоны
• применение межсервисных политик (например, защита на уровне сообщений, авторизация, ..) [ 112]
• отделение конечной точки службы от ее реализации (управление версиями службы)
• предоставляет такие стандартные услуги, как обмен сообщениями, обработка событий, мониторинг, хедлинг исключений и т. Д.
• смягчение двухточечной связи
• .. еще немного ..

Действительно, ESB обычно работает как отдельное приложение (или контейнер в вашем случае) и, реализовав все возможности, это не всегда самое легкое приложение (по сравнению с простыми одноцелевыми микросервисами). При правильной реализации ESB должен оказывать минимальное влияние на задержку ответа или нагрузку на инфраструктуру.

Предоставление стандартных услуг и межсервисных возможностей. ИМХО, вы можете рассматривать ESB не как отдельный сервис, а как часть инфраструктурных сервисов, используемых в реализации микросервисов.

Возможно, Apache Camel используется для оркестровки? Но это противоречит духу микросервисов.

Apache Camel - это фреймворк, он может использоваться внутри приложений, автономно или также есть продукты ESB, построенные поверх Apache Camel (RedHat Fuse ESB, Talend ESB, Apache ServiceMix, ..).