Все еще очень новичок в изучении архитектуры приложений и испытывает проблемы с изложением некоторых идей в книге о микросервисах. В своих чтениях я натолкнулся на старую идею ESB (Enterprise Service Bus) и ее роль в координации сообщений между новыми сервисами и устаревшими приложениями. ESB рекламируются как решение проблем, связанных с двухточечной интеграцией. Кажется, что микросервисы - это подход, используемый новыми компаниями в качестве фактического стандарта для создания гибких, масштабируемых и отказоустойчивых приложений. Но разве микросервисы не используют интеграцию точка-точка? Каждый узел в приложении, построенном из микросервисов, напрямую взаимодействует с другими узлами, верно? Я чувствую, что соединяю точки, которые не следует связывать. Любая помощь очень ценится, заранее спасибо.
Не понимает, что ESB - это решение для двухточечной интеграции
Ответы (4)
Микросервисы не обязательно полагаются исключительно на двухточечную интеграцию.
Проблемы, связанные с прямым обменом данными, часто решаются в микросервисной архитектуре с помощью брокера сообщений. Если связь может быть асинхронной - «запустил и забыл» - приложение, отправляющее сообщение, не перестанет работать, если получатель выйдет из строя. И сообщения все еще будут там, когда служба-получатель вернется к работе.
Если микросервисы интегрируются через REST, вызывающей стороне необходимо знать, как реагировать, если другая служба не отвечает. Поскольку это становится непросто, когда вы сохраняете данные в разных системах (например, распределенную транзакцию), мне нравится использовать REST только для API извлечения данных. И вообще все сохраняет в результате сообщений.
Важно отметить, что ESB - это гораздо больше, чем просто обмен сообщениями. Подробнее об этом см. здесь.
ESB - это решения, которые были внедрены во многих компаниях для обеспечения взаимодействия и отслеживаемости приложений. Однако это тяжелые решения, которые не позволяют масштабироваться по горизонтали, обычно ESB принимают конфигурацию из двух узлов, активного-активного или активного-пассивного.
С другой стороны, службы в ESB обычно развертываются не по отдельности, а в пакетах развертывания вместе с другими службами, что усложняет управление доставкой и тестирование.
Микросервисы предназначены для разработки и развертывания по отдельности, чтобы внутри облачной инфраструктуры можно было легко масштабироваться по горизонтали, динамически увеличивая количество экземпляров.
Взаимодействие между приложениями в настоящее время отошло на второй план, поскольку сегодняшнее общение с помощью веб-сервисов является практически обычным явлением, хотя некоторое промежуточное программное обеспечение, которое решает проблемы подключения, все еще может потребоваться в некоторых очень старых инфраструктурах.
Оба подхода не обязательны. Микросервисы могут обмениваться данными с использованием промежуточного программного обеспечения обмена сообщениями (kafka, AMQP, акторы Akka, JMS ...) вместо прямых HTTP-каналов. Это зависит от ваших ограничений (в основном согласованности) и политик развертывания.
У каждого выбора есть свои сильные и слабые стороны, я лично советую не ограничиваться одним подходом, а использовать оба и выбирать в зависимости от каждой ситуации.
См. Микросервисы: REST против обмена сообщениями и https://capgemini.github.io/architecture/is-rest-best-microservices/
Микросервисы не заменяют ESB.
Микросервисы - это концепция для разработки серверных систем, включая их API. Противоположность микросервисному подходу - монолит. Если API используется непосредственно потребляющими системами, мы приходим к интеграции точка-точка (спагетти). Если потребитель использует промежуточное программное обеспечение, часто называемое шлюзом API, мы можем получить централизованную видимость, безопасность и отслеживание (как в случае с ESB). Шлюзы API проще, чем ESB, и поэтому лучше подходят для горизонтального масштабирования. Шлюзы API не должны включать дополнительную бизнес-логику / логику интеграции.
ESB делает то же самое, что и шлюз API (действует как прокси), но, кроме того, позволяет включать бизнес-логику, объединять несколько служб в одну и другие расширенные функции. ESB часто превращались в обременительные решения с большими накладными расходами и небольшой добавленной стоимостью, и поэтому их стали ненавидеть.
Заключение
ESB можно использовать вместе с архитектурой микросервисов, есть много компаний, которые делают ESB простой, и она почти равна так называемым шлюзам API.
Мое мнение
Шлюзы API вводят новые функции и становятся все более сложными, приближаясь к ESB.
