• istio_codes.png - Istio response-flags на распечатку.

Микросервисная архитектура = метод создания распределённых приложений в виде набора независимо разрабатываемых и развёртываемых в изолированном окружении небольших служб. Является частным случаем SOA.

Признаки микросервисной архитектуры:

• Каждый сервис имеет свой домен (предметную область), сиречь занимается управлением своего собственного набора бизнес-сущностей либо своим особенным набором функций. Например, сервис формирования отчётов, сервис приёма данных в архив, сервис поиска и выдачи данных, сервис сбора метрик или логов. Поэтому такие сервисы и микро-.
• Каждый сервис обычно разрабатывается отдельной командой, возможно даже в отдельном релизном цикле.
• Каждый сервис имеет свой отдельный репозиторий. Команды не мешаются друг другу.
• Каждый сервис имеет свой CI/CD/CDP pipeline и может быть отправлен в ПРОД независимо от других (идёт собственным дистрибутивом).
• Каждый сервис может (но не обязан) включать в себя свой стек технологий. Например, один написан на Golang, другой на Java, третий на C# — на усмотрение команды разработки.
• Каждый сервис имеет свою БД (и СУБД).

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

Поскольку асинхронное событийное взаимодействие — практически стандарт в микросервисной архитектуре, то надо разбираться в создании событийной архитектуры (Event Driven Architecture, см. статью https://habr.com/ru/company/dataart/blog/280083/), а сами микросервисы должны соответствовать требованиям Reactive.

Минусы микросервисной архитектуры

• скорее всего вы будете вынуждены перейти на асинхронное событийное взаимодействие;
• рост накладных расходов — общее снижение скорости работы в сравнении с "монолитом", состоящим из модулей, взаимодействие между которыми вы вынесли вынесли на сетевой уровень, увеличение вероятности потери данных при транспортировке;
• сложнее организовать транзакции.* Транзакция = способ группировки операций чтения / записи в одну логическую единицу, в рамках которой эти операции либо выполняются целиком либо не выполняются с возможностями прерывания и отката.
• архитектура интерационных взаимодействий усложнится, скорее всего вам понадобится организовать трейсинг запросов для облегчения разбора различных проблем;
• теперь критически важно актуальность поддерживать контрактов API (CDC);
• логов теперь больше и они в разных местах — у каждого сервиса свои.

Зачем в микросервисы?

Кто использует service mesh

Крупные корпорации, банки и прочие предприятия, имеющие сотни (микро)сервисов с очень нагруженной коммуникацией между ними, а также те, кто является владельцем целых платформ.
Пионерами в микросервисной архитектуре и service mesh в ИТ являются Lyft, Netflix и Twitter (ныне — X).
В российских реалиях внедрение происходит в топ-банках и, например, Авито.

Ценность service mesh: предоставление функций, критически важных для работы современного серверного ПО, единообразным для всего стека и независимым от кода приложения образом.

Суть

Service mesh = архитектурный подход, который

• в условиях наличия сотен (микро)сервисов + использования облаков с тысячами инстансов + использования контейнеризации + необходимости обработки больших объёмов межсервисных коммуникаций
• за счёт добавления в инфраструктуру userspace-прокси (data plane), расположенных "рядом" с сервисами, и набора управляющих процессов (control plane)
• позволяет реализовывать такие функции как service discovery + routing + balancing + tracing + authentication + authorization + encryption + circuitBreaking + autoscaling и другие

Data plane перехватывает вызовы между сервисами, производя над ними необходимые манипуляции.
Control plane координирует поведение прокси и обеспечивает доступ для оператора к API, позволяя манипулировать сетью, изменяя её как единое целое.

Service mesh занимается эксплуатационной логикой, а не смысловой. Занятие смысловой логикой было главным недостатком сервисной шины предприятия (ESB).
Сохранение этого разделения помогает service mesh избежать той же участи.

Некоторые технологии и инструменты из области Service mesh

• Linkerd самый первый service mesh framework, активно развивается. Использует встроенный прокси, написанный на Rust
• Istio service mesh framework, продвигаемый Google + IBM + LYFT. В качестве прокси использует Envoy.
• gRPC — RPC фреймворк, использующий protobuf и HTTP/2
• HTTP/2
• TLS со взаимной аутентификацией.
• protobuf (protocol buffers)
• В качестве прокси: Nginx или Envoy
• Jaeger как инструмент распределённой трассировки запросов
• Prometheus cloud-native инструмент сбора метрик
• Grafana дашборды для метрик
• Kubernetes как фреймворк оркестрации контейнеров
• Openshift и RHL

(для себя) поясняющая схемка взаимосвязи некоторых сущностей Openshift, Istio, k8s.
В OSE для входа используется Route, в "голом" istio / kubernetes — Ingress.
Разобраться с EnvoyFilter.

Пример набора сущностей для маршрутизации запросов на какой-то внешних хост через эгресс: # Service. Объявлен граничный порт для сервиса граничного прокси. kind: Service apiVersion: v1 metadata: name: svc-egress labels: app: i-egressgateway app-group: "some-egress" app.kubernetes.io/part-of: istio app.kubernetes.io/instance: istio-controlpanel release: istio app.kubernetes. io/component: gateways istio: i-egressgateway maistra-version: 2.0.2 app.kubernetes.io/name: gateways chart: gateways heritage: Tiller spec: ports: - name: http-7074 protocol: TCP port: 7074 targetPort: 7074 selector: app: i-egressgateway istio: i-egressgateway type: ClusterIP status: loadBalancer: {} ---------------------------------------- # ServiceEntry. Описаны для целевого хоста граничный порт и порт удалённой машины apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: se-egressgateway spec: exportTo: - . hosts: - remotehostname.com location: MESH_EXTERNAL ports: - name: http-7074 number: 7074 protocol: HTTP - name: https-8881 number: 8881 protocol: HTTPS resolution: DNS ---------------------------------------- # VirtualService. Описана маршрутизация в направлении целевого хоста с граничного порта на целевой порт удалённой машины. apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: vs-egressgateway labels: app-group: "some-egress" spec: exportTo: - . gateways: - mesh - gw-egressgateway hosts: - remotehostname.com http: - match: - gateways: - mesh port: 7074 rewrite: authority: remotehostname.com route: - destination: host: svc-egress port: number: 7074 - match: - gateways: - gw-egressgateway port: 7074 rewrite: authority: remotehostname.com route: - destination: host: remotehostname.com port: number: 8881 ---------------------------------------- # Gateway. Для эгресса в направлении внешнего хоста указан граничный порт. apiVersion: networking.istio.io/v1beta1 Kind: Gateway metadata: name: gw-egressgateway labels: app-group: "some-egress" spec: selector: app: i-egressgateway istio: i-egressgateway servers: - hosts: - remotehostname.com port: name: http-7074 number: 7074 protocol: HTTP ---------------------------------------- # DestinationRule. В направлении внешнего хоста указан целевой порт и необходимые для MTLS сертификаты + ключ. apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: dr-egressgateway labels: app-group: "some-egress" spec: exportTo: - . host: remotehostname.com trafficpolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 8881 tls: cacertificates: /etc/ssl/certs/caCertificates.pem clientCertificate: /etc/ssl/certs/tls.crt mode: MUTUAL privatekey: /etc/ssl/certs/tls.key sni: remotehostname.com outlierDetection: consecutive5xxErrors: 7 interval: 5m baseEjectionTime: 15m