#apache-camel #openshift #openshift-origin
#apache-camel #openshift #openshift-origin
Вопрос:
Я наблюдал тенденцию к увеличению числа людей, использующих Apache Camel в микросервисной архитектуре. Например, на контейнерной платформе Openshift.
Я изо всех сил пытаюсь понять, почему корпоративная служебная шина, фундаментальный монолитный, может использоваться в микросервисной архитектуре.
Возможно, Apache Camel используется для оркестровки? Но это противоречит духу микросервисов.
Может кто-нибудь просветить меня по этому поводу, пожалуйста? Я не могу обмозговать это.
Комментарии:
1. Apache Camel — это не ESB, а платформа интеграции (по сути, Camel — это просто набор JAR-файлов, которые вы добавляете в свое существующее приложение и встраиваете их вместе). Существует множество статей, видео, блогов и т.д. Об использовании Camel с микросервисной архитектурой и контейнерных технологий. Вы можете предположить, что Camel — это ESB или какая-то его часть, потому что Camel был создан 11 лет назад, но даже в этом случае он всегда задумывался как облегченная платформа интеграции. И он использовался в качестве движка внутри некоторых ESB, таких как ServiceMix, и некоторых продуктов коммерческих поставщиков.
2. спасибо, я предполагаю, что Apache Camel будет запускаться внутри контейнера и служить маршрутизацией для других микросервисов, развернутых в других контейнерах?
3. Вы можете запускать маршруты camel в своих контейнерах для интеграции с другими технологиями. Например, было бы легко выполнить преобразование SOAP в REST.
4. Да, Camel работает вместе с вашим микросервисом — (просто как набор дополнительных JAR в classpath) и с Camel ваши микросервисы могут легко выполнять интеграцию, маршрутизацию и другие функциональные возможности, которые предоставляет Camel.
Ответ №1:
Apache Camel не является ESB. Вместо этого это облегченная платформа интеграции с множеством соединителей для баз данных, очередей сообщений, платформ потоковой передачи и популярных API. Он также поддерживает около 50 форматов данных и поддерживает множество сред выполнения, включая Springboot и поддержку Quarkus с Camel 3.
Почему это здорово для микросервисов?
- Поддержка Springboot и Quarkus (не удается получить ни одного микро, кроме этого atm).
- Каждому микросервису необходимо взаимодействовать с другими сервисами или внешним миром, а инструментарий интеграции Camel с несколькими компонентами, форматами данных упрощают это.
- REST DSL позволяет очень легко создавать интерфейс REST
- Компоненты JMS и Kafka упрощают разработку микросервисов, управляемых событиями.
- Поддержка OpenTracing обеспечивает распределенную трассировку.
- Показатели, экспортируемые через JMX (можно использовать с prometheus jmx exporter), помогают инструментировать ваши приложения camel.
Надеюсь, это поможет.
Ответ №2:
Я изо всех сил пытаюсь понять, почему корпоративная служебная шина, фундаментальный монолитный, может использоваться в микросервисной архитектуре.
ESB обладает множеством возможностей, полезных для микросервисной архитектуры. Это позволяет:
- посредничество и преобразование сообщений см. в разделе Шаблоны корпоративной интеграции
- принудительное применение межведомственной политики (например, безопасность на уровне сообщений, авторизация, ..)
- отделение конечной точки сервиса от ее реализации (управление версиями сервиса)
- предоставляет стандартные сервисы, такие как обмен сообщениями, обработка событий, мониторинг, обработка исключений, ..
- смягчение взаимодействия «точка-точка»
- .. еще немного..
Действительно, ESB обычно запускается как отдельное приложение (или контейнер в вашем случае) и, реализовав все возможности, это не всегда самое легкое приложение (по сравнению с простыми одноцелевыми микросервисами). При правильной реализации ESB должен оказывать минимальное влияние на задержку ответа или нагрузку на инфраструктуру.
Предоставление стандартных сервисов и кросс-сервисных возможностей, по моему мнению, вы можете рассматривать ESB не как отдельный сервис, а как часть инфраструктурных сервисов, используемых реализациями микросервиса.
Возможно, Apache Camel используется для оркестровки? Но это противоречит духу микросервисов.
Apache Camel — это фреймворк, его можно использовать внутри приложений, автономно или также существуют продукты ESB, построенные поверх Apache Camel (RedHat Fuse ESB, Talend ESB, Apache ServiceMix, ..).
Ответ №3:
У Camel есть java / kotlin DSL для написания потоков и служб оркестровки.
Camel имеет набор компонентов интеграции, который позволяет интегрировать его с различными конечными точками / протоколами.
DSL предоставляет вам стандартный «язык» для написания потоков оркестровки — с использованием шаблона fluent.
У Camel также есть платформа тестирования, которая упрощает написание тестов потока и макетов конечных точек.
Поддержка Camel как обрабатывать исключения, повторные попытки, постоянный потребитель (https://camel.apache.org/components/latest/eips/idempotentConsumer-eip.html )
Camel реализует набор шаблонов корпоративной интеграции, см.https://camel.apache.org/components/latest/eips/enterprise-integration-patterns.html
При создании большого количества микросервисов без группировки сервисов это может привести к некоторому беспорядку…
Camel предоставляет вам дополнительный инструмент, который связывает все вместе.
Это не должно смешиваться с потоковым или реактивным программированием, потоковым API Kafka и так далее weiter….it это слой над этим материалом….