Взаимодействие между службами и управление микрослужбами

задняя часть Микросервисы балансировки нагрузки Эксплуатация и техническое обслуживание

Взаимодействие между службами и управление микрослужбами — две основные проблемы на уровне реализации архитектуры микрослужб.

В этой статье мы надеемся поделиться соответствующим опытом, объединив практики в среде производства гребешков (живая сцена на миллион дней).

Межсервисная связь

С точки зрения типов связи существует примерно три типа: синхронные вызовы, асинхронные вызовы и широковещательные рассылки.

В микросервисах, предназначенных для того, чтобы в начале отношений и вызовов было ясно, что нужно синхронизировать, что может быть асинхронно, что нужно транслировать, лучше всего внутренняя команда имеет единое понимание.

Затем необходимо определить протокол вызова.Например, распространенные варианты:


  • Синхронные вызовы: HTTP REST, gRPC, экономия и т. д.
  • Асинхронный вызов: Sidekiq, Celery и т. д., соответствующий бэкэнд, Redis, всевозможные достижения AMQP, Kafka и т. д.
  • Трансляция: различные реализации AMQP, Kafka и т. д.

Для того, чтобы выбрать, мы должны думать со многих сторон. В Интернете есть тонны статей «X против Y» или вопросов и ответов. На самом деле, это не что иное, как с нескольких точек зрения: производительность, зрелость, простота использования, экология, техническая команда. Наше предложение: отдавайте приоритет тем, которые активны в сообществе и совместимы с технологическим стеком вашей команды. Технологии, которые активны в сообществе, часто олицетворяют тренды и экологию, а совместимость стека технологий команды — гарантия успеха.

например, выбор гребешков в то времяgRPCВ качестве протокола интерфейса для синхронных вызовов. Основное внимание уделяется двум моментам: 1. Активное сообщество и очень быстрая разработка 2. Основанный на HTTP/2, он совместим с нашим стеком технологий.

В дополнение к выбору протокола важнее быть управлением интерфейсной документации. Лучше всего использовать документацию и код, чтобы быть сильным, так же, как прото и сгенерированный код GRPC. В противном случае люди часто имеют инертные, которые могут изменить документацию.

Таким образом, что касается межсервисного взаимодействия, нам нужно преуспеть:


  • Определите спецификацию интерфейса, какой использовать синхронный вызов, какой использовать асинхронный и какой использовать широковещательный; какой протокол использовать для синхронного вызова и что использовать асинхронно.
  • Определите протокол интерфейса и подумайте об управлении документом интерфейса, как установить прочную связь между документом интерфейса и кодом.

Служба управления

Управление услугами — очень большая тема, и если мы действительно хотим ее распространить, может не хватить нескольких статей. Здесь мы хотели бы кратко остановиться на проблемах, которые должно решить управление услугами, а также на некоторых текущих решениях и тенденциях развития.
Наконец, принимайте морские гребешки в качестве примера, чтобы кратко представить, как управление услугами осуществляется в реальной производственной среде с миллионами повседневной деятельности.

Что такое управление услугами

Микросервисизация дает много преимуществ, таких как декомпозиция и снижение сложности за счет разделения сложной системы на несколько микросервисов, что упрощает понимание и обслуживание этих микросервисов небольшой группой разработчиков. Однако это также создает множество проблем, таких как: подключение микросервиса, регистрация сервиса, обнаружение сервиса, балансировка нагрузки, мониторинг, тестирование AB, канареечный выпуск, ограничение тока, контроль доступа и т. д.
Эти проблемы и составляют основу управления услугами.

Существующая программа

Проблема управления сервисами существует уже давно, особенно после распространения микросервисов. Основные решения: основаны на таких средах, как Spring Cloud или Dubbo. Но проблемы с этими решениями: 1. Внедрение в код, а это значит, что если вы хотите изменить фреймворк, вам придется менять много чего. 2. Специфика языка (Java), если мы используем Go/Python или если наши микросервисы не все на Java, мы не можем этого сделать.

Service Mesh

2017 Появилась Service Mesh, которая заставила наши глаза сиять. В Интернете есть много вводных сведений о Service Mesh, вы можете поискать в Интернете. Насколько я понимаю, основная идея Service Mesh заключается в «прокси-трафике». Service Mesh перенаправляет/получает весь трафик для микросервисов через «агентов» один за другим.Управляя этими агентами, ряд функций, связанных с управлением сервисом, таких как подключение к сервису, регистрация, обнаружение, балансировка нагрузки, объединение, мониторинг и т. д. Код сервис больше не нуждается в реализации управления сервисом, другими словами, управление сервисом прозрачно для разработчика микросервиса. Как показано на рисунке ниже: зеленый квадрат — это микросервис, синий квадрат — это прокси сервисной сетки, а синяя линия — это межсервисное взаимодействие. Вы можете видеть, что синие квадраты и линии составляют всю сетку. Эта сеть является Service Mesh.


Обычно считается, что существует два поколения Service Mesh: первое поколение Linkerd/Envoy и второе поколение Istio/Conduit. Первое поколение является относительно зрелым и стабильным и может использоваться непосредственно в производственной среде.Второе поколение в настоящее время (начало 2018 г.) несовершенно и не рекомендуется для производства.

Сервисная сетка Scallop реализована на основе Envoy с Kubernetes.

Обнаружение сервисов, балансировка нагрузки и RateLimit для gRPC

В этом разделе в качестве примера используются морские гребешки, чтобы кратко представить, как мы осуществляем управление услугами.

Во-первых, вводятся некоторые предварительные условия: все микросервисы Scallop контейнеризованы, а система оркестровки основана наkubernetes, синхронный вызов основан наgRPC, асинхронно на основеcelery[rabbitmq]. язык разработки дляpython3, nodejs, goглавный. Service Mesh 基于Envoy

Общий план таков:EnvoyотDaemonSetразвертывается в видеkubernetesкаждогоNodeна, используяHostсетевой режим. все микросервисыPodвсе будетgRPCзапрос отправлен наNodeизEnvoy,Зависит отEnvoyсделать балансировку нагрузки. Как показано ниже:


Вот несколько подробных пояснений.


  1. EnvoyсерединаRouteпохожий наNginxизLocation,Clusterпохожий наNginxизupstream,EndpointсоответствуетNginxизupstreamвход в .
  2. Почему выбираютEnvoyи бесполезныйLinkerd, потому что в то времяEnvoyправдаHTTP/2Поддержите лучших. И меньше потребление ресурсов.
  3. Почему выбираютHostСетевой режим предназначен для максимальной производительности.
  4. заEnovyС точки зрения обнаружения услуг, чтобы сказатьEnvoy, каждыйClusterIP-адрес экземпляра за службой (соответствуетKubernetesэтоPodИП) это что.
  5. Первоначальное обнаружение службы заключается в использованииKubernetesизDNS, поэтому при созданииServiceКогда вы используетеClusterIP: None.
  6. Последующее обнаружение сервисов основано наKubernetesизEndpointAPI реализованEnovyизEDS(В будущем мы откроем исходный код этого проекта на GitHub).
  7. заEnvoyЧто касается предохранителей, покаrate limit serviceВот и все. Мы основаны наLyft/ratelimitРеализован сервис ограничения скорости.
  8. Призвание ситуации между микросервами доступна черезEnvoyизstatisticAPI отражает это, поэтому мы отслеживаем и предупреждаем о вызовах службы для статистического API.
  9. Точно так же можно использовать журнал вызововEnvoyизAccess Logреализовать.

Продолжение следует

Что касается управления услугами, в наших следующих статьях мы также поделимся с вами практикой DevOps, системой мониторинга и оповещения, построением системы логов и так далее. Наконец, если вас также интересуют микросервисы, k8s, service mesh, devops, добро пожаловать!


---

Добро пожаловать, чтобы следовать за нашимиЗнакомство с колонкой: Команда архитектуры Scallop Technology


Категории