Сетка обслуживания (как Istio) против Даже Управляемой Архитектуры микросервисов - PullRequest
Новая
       125

Сетка обслуживания (как Istio) против Даже Управляемой Архитектуры микросервисов

2 голосов
/ 05 апреля 2019

Привет, Микросервис Гуру,

У меня возник вопрос по сервису сервисной коммуникационной архитектуре Микросервисов. Istio или любая сервисная сетка могут упростить управление маршрутизацией, обнаружением и отказоустойчивостью связи Microservices. Однако он не охватывает важные аспекты транзакций, охватывающих более одного микросервиса (тип распределенных транзакций), который хорошо включен в архитектуру микросервисов, основанную на событиях. Тем не менее, очевидно, что управляемая событиями архитектура упускает аспекты, которые хорошо покрывает сетка обслуживания. Итак, было интересно, что является лучшим подходом или может быть способ смешать оба сервиса с сеткой, управляемой событиями, чтобы использовать преимущества обоих шаблонов. Но если такое сочетание возможно, то управляемая событиями шина (например, Kafka) не будет мешать внутренним рабочим схемам прокси-серверов боковой машины / плоскости управления, которую использует Istio.

Ответы [ 2 ]

4 голосов
/ 05 апреля 2019

Вы смешиваете несколько вещей.

  • Istio, linkerd и т. Д. Решают некоторые фундаментальные проблемы проектирования / архитектуры, которые возникают при работе с облачными, контейнерными микросервисами.например, обнаружение сервисов, автоматические выключатели и т. д. Эти проблемы обычно решались с помощью библиотек, встроенных в приложения, таких как Spring cloud, hystrix, ленты и т. д. Сервисные сетки решают эту проблему в рамках парадигмы мира контейнеров.

Но сервисные сетки не решают никаких других проблем обмена данными между сервисами, которые решаются с помощью Kafka или любого другого брокера сообщений.Ваши микросервисы могут быть даже управляемыми или нет - сервисная сетка не будет мешать этому.

0 голосов
/ 15 апреля 2019

ваши вопросы: сервисная сетка не охватывает важные аспекты транзакций, охватывающих более одного микросервиса (тип распределенных транзакций), который хорошо включен в архитектуру микросервисов, основанную на событиях, что не так.Service Mesh хорошо работает в аспекте распределенной микросервисной связи, но сервисная сетка хорошо работает для поддержки синхронных RESTful и общих взаимодействий запрос-ответ, она не поддерживает асинхронные, управляемые событиями взаимодействия, а также не подходит для подключения нативных облачных микросервисов сустаревшие приложения.Для управляемой событиями архитектуры вы должны выглядеть как Event Mesh, а не как Service Mesh.Проверьте ссылку ...

https://solace.com/use-cases/event-mesh/

...