Service mesh что это

Service mesh

In this note we are grouping the studies around microservice to microservice communication with Kubernetes deployment. We are addressing:

• how ingress controller helps inside Kubernetes
• how API gateway helps for API management and service integration
• how to expose service in hybrid cloud
• how to discover service

All come back to the requirements, skill set and fit to purpose.

Definitions¶

Service meshes provide visibility, resiliency, traffic, and security control of distributed application services. They deliver policy-based networking for microservices in the contraints of virtual network and continuous topology updates. Externalizing, via declarations, the logic to support network potential issues, like resiliency, simplifies dramatically developers work.

Some misconception to clarify around microservice and APIs:

• microservices are not fine grained web services
• APIs are not equivalent to microservices
• microservices implement APIs in the scope of their domain. Separation between queries and commands may lead to two different services so the APIs will be splitted.
• microservice implements business logic

API is an interface, a way to make a request to get or change data in an application. In modern use API refers to REST web APIs using HTTP protocol, with JSON format (sometime XML is still used). Interface decouples the caller from the implementation. The caller has no idea how API is implemented.

A microservice is in fact a component. Micro refers to the granularity of the component not of the exposed interface. The following diagram illustrates all those concepts.

Container orchestration like Kubernetes are mainly doing application scheduling, cluster management, resource provisioning, platform and workload monitoring and service discovery.

When application solutions are growing in size and complexity, you need to addres the following subjects:

• visibility on how traffic is flowing between microservices, how routing is done between microservices based on requests content or the origination point or the end point
• how to support resiliency by handling failure in a graceful manner
• how to ensure security with identity assertion
• how to enforce security policy

Addressing those subjects help defining the requirements for service mesh.

Service mesh architecture defines a data and control planes:

• Control plane: supports policy and configuration for services in the mesh, and provides aggregation for telemetry. It has API and CLI to centralize control to the services deployed. In Kubernetes control planes are deployed in a system namespace.
• Data plane: handles the actual inspection, transit, and routing of network traffic. It is responsible for health checking, load balancing, authentication, authorization, inbound (ingress) and outbound (egress) cluster network traffic.

Applications / microservices are unaware of data plane.

Context¶

Traditional modern architecture involves having different components exposing reusable APIs, addressing different channels (mobile, single page application, traditional server pages or B2B apps), consuming APIs (mobile APIs, back end for front end, shared common apis like authentication, authorization. ) and backend services addressing reusable business services:

API management can be added via API gateway. This is a distributed application with cross related communication channels, where any changes to the service interface characteristics impact any of the components.

Moving to microservices architecture style adds more communication challenges and DevOps complexity but provides a lot of business values such as:

• rapid deployment of new business capabilities, co-evolving in parallel of other services.
• focusing on business domain with clear ownership of the business function and feature roadmap
• better operation procedure, automated, and with easy rollout and continuous delivery.
• A/B testing to assess how new feature deployed improve business operations
• improve resiliency by deploying on multi language cluster

As an example we can use the a classical web application with the following capabilities:

• user authentication
• user management: add / delete new user
• user self registration, reset password
• user permission control
• user profile
• asset management
• risk assessment service

Each capability could be grouped by business domain like the user management, asset management, and application access control. So domain separation can be a good microservice boundary. This is the Domain Driven Design Bounded context construct. But if the number of user reach millions then we may need to optimize the runtime processing of reading user credential, and scale the service differently, leading to a service map like the diagram below, where runtime and management are separated services.

All of these still does not address the fact that data are distributed and even more with microservices owning their data persistence. As developers and architects, we still have to address the following data integrity problems:

• two phases commit
• compensating operation
• eventual data consistency: some microservice updating data may share those updates with other microservices.
• data aggregation: adding new views on data, owned by a microservice, to support new aggregates. Examples are preparing data view for machine learning modeling, analytics, or business intelligence.

From the previous microservice allocation we can see the needs to propagate data update between services. Adding or unsubscribing a user involves updating the asset the user owns and the authentication runtime service:

Adding a new application changes the authorization runtime service.

We are now looking at the following questions:

• how does webapp access APIs for their main service, of back end for front end service.
• how does deployed microservice access other service: discover and access?
• How data consistency can be ensured?
• is there a simpler way to manage cross microservice dependency?

The answers depend on the existing infrastructure and environment, and deployment needs.

Service routing¶

We have to dissociate intra-cluster communication versus inter clusters or cluster to external services. Without getting into too much detail of IP routing within Kubernetes some important elements of the cluster are important to remember:

• microservices are packaged as docker image and expose port. When deployed they run in a pod within a node (physical or virtual machine)
• containers can talk to other containers only if they are on the same machine, or when they have exposed port.
• Kubernetes is configured with a large flat subnet (e.g. 172.30.0.0/16) which is used for internal application traffic inside of the cluster. Each worker node in the Kubernetes cluster is assigned one or more non-overlapping slices of this network, coordinated by the Kubernetes master node. When a container is created in the cluster, it gets assigned to a worker node and is given an IP address from the slice of the subnet for the worker node.

• Kube-proxy intercepts and controls where to forward the traffic, either to another worker node running your destination pod, or outside of the cluster
• Kube-proxy watches the API Server on the Master Node for the addition and removal of Services endpoints. It configures the IPtable rules to capture the traffic for its ClusterIP and forwards it to one of the endpoints.
• Worker nodes have internal DNS service and load balancer

Within Kubernetes, Ingress is a service that balances network traffic workloads in your cluster by forwarding public or private requests to your apps. You use ingress when you need to support HTTP, HTTPS, TLS, load balancing, expose app outside of the cluster, and custom routing rules.

One ingress resource is required by namespace. So if microservices are in the same namespace you can define a domain name for those services (e.g. assetmanagement.greencompute.ibmcase.com) and defined path for each service:

The following diagram shows how Ingress directs communication from the internet to a deployed microservice:

1. A user sends a request to your app by accessing your app’s URL. DNS name abstracts the application from the underlying infrastructure. Inter clusters microservice to microservice should use the same approach
2. A DNS system service resolves the hostname in the URL to the portable public IP address of the load balancer
3. Based on the resolved IP address, the client sends the request to the load balancer service that exposes the Application Load Balancer (ALB)
4. The ALB checks if a routing rule for the app path in the cluster exists. If a matching rule is found, the request is forwarded according to the rules that you defined in the Ingress resource to the pod where the app is deployed. If multiple app instances are deployed in the cluster, the ALB load balances the requests between the app pods. To also load balance incoming HTTPS connections, you can configure the ALB to you can use your own TLS certificate to decrypt the network traffic.
5. Microservice to microservice can use this DNS name to communicate between them.

Using Ingress, the global load balancer can support parallel, cross region clusters.

Service exposition¶

There is an architecture style focusing on APIs which proposes to have different SLA and semantic for external, internet facing API versus internal back end APIs only exposed within intranet.

Backend data services are not exposed directly to internet. API Gateway provides a secure end point for external web app to access those business functions.

So the decisions on how to expose service are linked to:

• do you need to do API management
• do you need to secure APIs
• do you need to expose to internet
• do you need to support other protocol then HTTP
• do you need to have multiple instances of the application

When deploying a microservice to Kubernetes it is recommended to use Ingress rule as presented above.. The following yaml file exposes the BFF service using ClusterIP:

Service discovery¶

When deploying on Kubernetes cluster, microservices use the DNS lookup to discover deployed microservice.

ISTIO¶

ISTIO provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, traffic flow management, monitoring, etc. By deploying a special sidecar proxy (called Envoy) throughout your environment, all network communication between microservices is intercepted and controlled by ISTIO control panel.

The control plane manages the overall network infrastructure and enforces the policy and traffic rules.

Asynchronous loosely coupled solution using events¶

If we change of paradigm and use a messaging approach or better an event approach of the data update requirements, we will implement a loosly coupled solution with a pub/sub communication protocol. We need to think about the activities that apply within each service and how they can be of interest to other components. Internal microservice tasks are becoming facts about something happened and those facts may be published as events for others to consume. The first level of refactoring may become:

An event is a fact that happens in the past and carry all the data needed, and it becomes a source of record. It becoming consistent if it is played in a messaging backbone via topics.

But the persistence of data can be externalized to consumer and then simplify the architecture:

Then we can use the history of the persisted events to add features not address before, and outside of the direct scope of a microservice. For example to compute the number of users added last month, just a query on the users topic will get the answer: no or very limited coding needed.

What is Service-Mesh and what it brings to Microservices

An introduction to the new application architecture pattern of Service Mesh

Wow, has application architecture evolved in the last five years or what? The monolithic application has become a bunch of independent microservices. Collectively, they are building the same product/functionality as it’s monolithic version. As these many microservices need to work as a team, they need to continually communicate Egress or Ingress with each other and exchange the data with fast, secure, and reliable into account.

Service-Mesh means networking of services, Istio is a project which developed different components collaboratively work as a service mesh product to manage and control the networking between microservices. In other words, separating the business logic in your microservice and it’s communication and networking layer.

We can achieve this by injecting another container in the same application pod running in Kubernetes platform called sidecar (envoy), so now we have two different containers in one pod, one is for running your business application, and other is managing its interaction with other services in the mesh, we can also allocate different resources to these containers as per the application requirement.

To some extent, monolithic applications are protected by their single address space. Once a monolith has been broken up into microservices, however, the network becomes a substantial attack surface. More services mean more network traffic, which, for hackers, means more opportunities to attack the flow of information. This is the reason why service meshes provide the ability (and infrastructure) to secure network calls.

The security-related benefits of service meshes revolve around three core areas:

Что такое сетка сервисов?

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

Зачем нужна сетка сервисов?

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

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

Существует два основных фактора внедрения сеток сервисов, о которых мы подробно расскажем ниже.

Наблюдаемость за уровнем обслуживания

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

Контроль уровня обслуживания

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

В чем преимущества сетки сервисов?

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

Обнаружение сервисов

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

Балансировка нагрузки

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

Управление трафиком

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

Разделение трафика

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

Запрос зеркального отображения

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

Развертывание пробного выпуска

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

Безопасность

Сетки сервисов предоставляют функции безопасной связи, такие как взаимное шифрование по протоколу TLS (MTLS), аутентификация и авторизация. Mutual TLS обеспечивает проверку личности при обмене данными между сервисами. Это помогает обеспечить конфиденциальность и целостность данных за счет шифрования трафика. Можно также применять политики авторизации, чтобы контролировать доступ сервисов к определенным адресам или выполнение определенных действий.

Мониторинг

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

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

Как работает сетка сервисов?

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

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

В архитектуре сетки сервисов есть два основных компонента – плоскость управления и плоскость данных.

Плоскость данных

Плоскость данных – это компонент обработки данных сетки сервисов. Он включает в себя все прокси-серверы Sidecar и их функции. Когда сервис хочет связаться с другим сервисом, прокси-сервер Sidecar выполняет следующие действия:

1. Sidecar перехватывает запрос
2. Он инкапсулирует запрос в отдельное сетевое соединение
3. Он устанавливает безопасный и зашифрованный канал между исходными и целевыми прокси-серверами

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

Плоскость управления

Плоскость управления выступает в качестве центрального уровня управления и настройки сетки сервисов.

С помощью панели управления администраторы могут определять и настраивать сервисы в сетке. Например, они могут указать такие параметры, как адреса обслуживания, правила маршрутизации, политики балансировки нагрузки и параметры безопасности. После определения конфигурации плоскость управления распределяет необходимую информацию в плоскость данных сетки сервисов.

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

Реализации сетки сервисов обычно включают в себя следующие возможности на уровне управления:

• Реестр сервисов, который отслеживает все сервисы в сети
• Автоматическое обнаружение новых сервисов и удаление неактивных
• Сбор и агрегирование телеметрических данных, таких как метрики, журналы и распределенная информация о трассировке

Что такое Istio?

Istio – это проект сеток сервисов с открытым исходным кодом, предназначенный в основном для работы с Kubernetes. Kubernetes – платформа для оркестрации контейнеров с открытым исходным кодом, позволяющая развертывать контейнерные приложения и управлять ими в любом масштабе.

Компоненты панели управления Istio функционируют как самостоятельные рабочие нагрузки Kubernetes. В качестве основы для создания прокси Sidecar используется Kubernetes Pod – тесно связанный набор контейнеров с одним IP-адресом.

Прокси-сервер Istio уровня 7 работает как другой контейнер в том же сетевом контексте, что и основной сервис. С этой позиции он может перехватывать, проверять и управлять всем сетевым трафиком, проходящим через модуль. Тем не менее, основной контейнер не нуждается в изменениях или даже знании того, что это происходит.

В чем заключаются проблемы внедрения сеток сервисов с открытым исходным кодом?

Вот некоторые распространенные проблемы сетки сервисов, связанные с платформами с открытым исходным кодом, такими как Istio, Linkerd и Consul.

Сложность

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

Операционные накладные расходы

Сетки сервисов сопряжены с дополнительными накладными расходами на развертывание, управление и мониторинг прокси-серверов плоскости данных и компонентов плоскости управления. Например, вам нужно сделать следующее:

• Обеспечьте высокую доступность и масштабируемость инфраструктуры сетки сервисов
• Отслеживайте состояние и производительность своих прокси-серверов
• Решайте проблемы с обновлениями и совместимостью

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

Проблемы интеграции

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

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

Как AWS обеспечивает соответствие вашим требованиям к сетке сервисов?

AWS App Mesh – это полностью управляемая и высокодоступная сетка сервисов от Amazon Web Service (AWS). App Mesh – это новая технология, которая упрощает мониторинг, контроль и отладку взаимодействия между сервисами.

App Mesh использует Envoy, прокси‑сервер с открытым исходным кодом для сети сервисов, развертывая его рядом с контейнерами микросервисов. Это решение можно использовать с контейнерами микросервисов, которыми управляют Эластичный контейнерный сервис Amazon (Amazon ECS), Эластичный сервис Amazon Kubernetes (Amazon EKS), AWS Fargate и Kubernetes на AWS. Его также можно использовать с сервисами в Эластичном вычислительном облаке Amazon (Amazon EC2).

Что такое service mesh простыми словами

Всё больше компаний переходят на микросервисы. Такой выбор вполне оправдан: при должной реализации они решают множество проблем монолита. За последние несколько лет микросервисная архитектура сильно эволюционировала и обросла вспомогательными технологиями, одна из которых service mesh. В статье разберём, какую роль service mesh играет в развёртываниях микросервисов и как помогает упростить работу разработчиков.

Зачем нужен service mesh

Service mesh — инструмент, позволяющий контролировать, как разные части приложения обмениваются данными между собой. В отличие от других систем управления, он представляет собой отдельный слой инфраструктуры, встроенный прямо в приложение. Этот слой документирует, насколько хорошо взаимодействуют микросервисы, поэтому становится проще оптимизировать это взаимодействие и избегать простоев по мере роста приложения.

Многие думают, что микросервисы уже являются решением всех проблем, которые возникали с монолитом. Однако, наблюдая за реализацией микросервисной архитектуры в реальном мире, мы обнаруживаем, что большинство функций, поддерживаемых централизованной шиной (ESB), теперь реализованы на уровне микросервисов. То есть мы решаем один и тот же набор фундаментальных проблем, просто делаем это в разных измерениях.

С архитектурой ESB вы можете легко использовать встроенные возможности для создания виртуальных сервисов и функциональных возможностей, которые полезны для межсервисного взаимодействия:

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

Самая сложная задача при реализации микросервисной архитектуры заключается не в создании самих сервисов, а в обеспечении связи между ними. Для выполнения своей функции одному сервису может потребоваться запросить данные у нескольких других микросервисов. Но что, если некоторые микросервисы будут перегружены запросами? Здесь на помощь приходит service mesh — технология направляет запросы от одного сервиса к другому, оптимизируя совместную работу всех частей приложения.

Разве микросервисы уже не делают это?

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

Связь между сервисами — то, благодаря чему микросервисная архитектура работает. Логику, управляющую этой связью, можно закодировать в каждом сервисе и без уровня service mesh, но по мере усложнения взаимодействия сервисов ценность service mesh возрастает. Для облачных приложений с микросервисной архитектурой service mesh — это способ объединения большого количества отдельных сервисов в функциональное приложение.

Как это работает

Service mesh не вводит новые функциональные возможности в среду выполнения приложения — приложения в любой архитектуре нуждались в правилах, определяющих, как запросы доставляются из точки А в точку Б. Отличие service mesh, заключается в том, что эта технология выводит логику, управляющую взаимодействием между сервисами, на уровень инфраструктуры.

Service mesh встраивается в приложение в виде массива сетевых прокси.

В service mesh запросы маршрутизируются между микросервисами через прокси-серверы на их собственном уровне инфраструктуры. Отдельные прокси-серверы в service mesh иногда называют «сайдкарами», так как они работают вместе с каждым сервисом, а не внутри него. В совокупности прокси-серверы, отделенные от каждого сервиса, образуют сеть:

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

Разные реализации

Linkerd и Istio — популярные реализации service mesh с открытым исходным кодом. Они имеют схожую архитектуру, но разные механизмы. Здесь можно почитать о сравнении инструментов.

Как service mesh оптимизирует коммуникации

Каждый новый сервис усложняет коммуникационную среду и создаёт новые точки отказа. В сложной микросервисной архитектуре становится практически невозможно определить причину проблемы без service mesh.

Service mesh фиксирует все аспекты взаимодействия между сервисами в качестве показателей производительности. Если в каком-то сервисе происходит сбой, service mesh собирает данные о том, сколько времени прошло до успешной повторной попытки. По мере накопления данных о времени сбоя можно подготовить правила для определения оптимального времени ожидания перед повторным запуском сервиса. Это гарантирует, что система не будет перегружена ненужными повторными попытками.

Плюсы и минусы

Кратко перечислим основные плюсы и минусы service mesh.

Плюсы

Минусы

— стандартные функции реализованы вне кода микросервиса и могут использоваться повторно

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

— больше свободы, когда дело доходит до выбора языка реализации микросервисов: не нужно беспокоиться, поддерживает ли язык или библиотека для создания функций сетевого приложения

— наличие service mesh резко увеличивает количество экземпляров среды выполнения, которые есть в данной реализации микросервиса

— service mesh решает только проблемы взаимодействия между сервисами, однако помимо этого существуют и другие проблемы вроде сложной маршрутизации, которые тоже необходимо решать в бизнес-логике микросервиса

— технология service mesh ещё слишком молода для крупномасштабного развёртывания

Коротко о главном

Service mesh решает ключевые проблемы, связанные с реализацией микросервисной архитектуры. Технология позволяет сосредоточиться на бизнес-логике и не тратить время на сетевые функции между сервисами. Благодаря service mesh микросервис не взаимодействует напрямую с другими сервисами. Кроме того, обеспечивается встроенная поддержка сетевых функций: отказоустойчивости, маршрутизации, контроля доступа и др. При этом service mesh не зависит от языка: поскольку микросервис всегда находится на вершине стандартных протоколов (HTTP1.x/2.x, gRPC), вы можете использовать любые технологии — они все равно будут работать с service mesh.

Больше о service mesh

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