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

Каждый микросервис включает в себя свой стек технологий, выбор которого осуществляется непосредственным разработчиком. Вместо единой базы данных в каждом микросервисе используется собственный инструмент хранения информации, причем выбор реляционной или нереляционной СУБД, способа организации данных, атрибутивного состава и программных интерфейсов для предоставления данных также ни с кем не согласуется.

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

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

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

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

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

Ценность 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