Shulou(Shulou.com)06/02 Report--

Translation | Song Song

Original text | https://www.infoq.com/articles/service-mesh-event-driven-messaging

Key points

The current popular Service Mesh implementations (Istio,Linkerd,Consul Connect, etc.) only satisfy the request-response synchronous communication between microservices.

In order to promote and adopt Service Mesh, we consider it essential to support event-driven or message-based communication.

There are two main architectural patterns for implementing messaging support in Service Mesh; the protocol broker sidecar, which is the agent for all inbound and outbound events from consumers and producers; and HTTP bridge sidecar, which converts event-driven communication protocols to HTTP or similar protocols.

No matter which bridge pattern is used, sidecar can facilitate the implementation of cross-functional features (and correct abstractions), such as observability, throttling, tracking, and so on.

Service Mesh is becoming more and more popular as a basic technology and an architecture model based on micro-services and cloud native architecture. Service Mesh is primarily a network infrastructure component that allows you to unload network communication logic from micro-service-based applications so that you can focus entirely on the service's business logic.

Service Mesh is built around the concept of agents, which collaborate with services as sidecar. Although Service Mesh is often advertised as a platform for any cloud native application, the popular Service Mesh implementations (Istio/Envoy, Linkerd, etc.) only satisfy the request/response style of synchronous communication between microservices. However, in most practical microservice use cases, communication between services occurs through a variety of patterns, such as request/response (HTTP,gRPC,GraphQL) and event-driven messaging (NATS,Kafka,AMQP). Since the Service Mesh implementation does not support event-driven communication, most of the commodity functions provided by Service Mesh can only be used to synchronize request/response services-event-driven microservices must support these functions as part of the service code itself, which contradicts the goals of the Service Mesh architecture.

It is critical that Service Mesh supports event-driven communication. This article focuses on the key aspects of supporting event-driven architecture in Service Mesh and how existing Service Mesh technologies try to solve these problems.

Implement event-driven messaging

In a typical request/response synchronous messaging scenario, you will find a service (server) and a consumer (client) that invokes the service. The Service Mesh data plane acts as an intermediary between the client and the service. In event-driven communication, the communication mode is completely different. The event generator asynchronously sends events to the event broker, and there is no direct communication channel between the generator and the consumer. The communication style can be pub-sub (multiple consumers) or queue-based (single consumer), and depending on the style, the producer can send messages to the topic or queue respectively.

The consumer decides to subscribe to a topic or queue that resides in the event broker, which is completely separate from the producer. When there are new messages available for the topic or queue, the agent pushes those messages to the consumer.

There are several ways to use Service Mesh abstraction for event-driven messaging.

01 Protocol-proxy sidecar

The protocol agent pattern revolves around the concept that all event-driven communication channels should be built through the Service Mesh data plane (that is, side car agents). To support event-driven messaging protocols such as NATS,Kafka or AMQP, you need to build protocol handlers / filters specific to communication protocols and add them to the sidecar agent. Figure 1 shows a typical communication pattern for event-driven messaging using service mesh.

Figure 1: event-driven messaging using service mesh

Since most event-driven communication protocols are implemented on top of TCP, sidecar agents can build protocol handlers / filters on top of TCP to specifically handle the abstractions needed to support various messaging protocols.

The producer microservice (microservice A) must send messages to side car through the underlying messaging protocol (Kafka,NATS,AMQP, etc.) so that the producer client uses the simplest code, while side car handles most of the complexity associated with the protocol. The Envoy team is currently implementing Kafka support for Envoy agents based on the above patterns. It's still in progress, but you can track progress on GitHub.

02

HTTP-bridge sidecar

Instead of using a proxy for an event-driven messaging protocol, we can build a HTTP bridge to transform messages that require a message protocol (to/from). One of the key motivations for building this bridging pattern is that most event agents provide REST API (for example, Kafka REST API) to use and generate messages. As shown in figure 2, existing microservices can transparently use the messaging system of the underlying event broker by controlling the sidecar that connects the two protocols. The sidecar agent is mainly responsible for receiving HTTP requests and converting them to Kafka/NATS/AMQP/ and so on. News, and vice versa.

Figure 2:HTTP bridge allows services to communicate with event agents through HTTP

Similarly, you can use the HTTP bridge to allow Kafka / NATS / AMQP-based microservices to communicate directly with HTTP (or other request/response messaging protocols) microservices, as shown in figure 3. In this case, sidecar receives Kafka / NATS / AMQP requests, forwards them to HTTP, and converts the HTTP response back to Kafka / NATS / AMQP. Efforts are under way to add support for this pattern on Envoy and NATS (for example, AMQP / HTTP Bridge and NATS / HTTP Bridge, both in Envoy).

Figure 3:HTTP Bridge allows services based on event-driven messaging protocols to use HTTP services

Although the HTTP-bridge pattern is suitable for some use cases, it is not powerful enough to serve as a standard for handling event-driven messaging in the service mesh architecture. Because there are always some limitations to request/response-based event-driven messaging protocols. It is more or less an approach that applies to some use cases.

Key functions of event-driven service mesh

The functionality of traditional service mesh based on request/response-style messaging is somewhat different from that of service mesh that supports messaging paradigms. Here are some unique features that a service mesh that supports event-driven messaging will provide:

Consumer and producer abstraction: for most messaging systems, such as Kafka, the broker itself is fairly abstract and simple (dumb pipes in the context of microservices), while your service is intelligent endpoints (most intelligence exists in producer or consumer code). This means that producers or consumers must have a large number of message protocol codes next to the business logic. By introducing service mesh, you can move features related to messaging protocols, such as partition rebalancing in Kafka, to sidecar and focus entirely on the business logic in the microservice code.

Message passing semantics: there are many message passing semantics, such as "at most once", "at least once", "just once", and so on. Depending on what the underlying messaging system supports, these tasks can be transferred to Service Mesh (similar to supporting circuit breakers, timeouts, and so on in the request/response paradigm).

Subscription semantics: you can also use the service-mesh layer to handle subscription semantics, such as persistent subscriptions to consumer-side logic.

Flow limiting: message limits (rate limits) can be controlled and managed according to various parameters (such as number of messages, message size, etc.).

Service discovery (agent, topic, and queue discovery): Service-mesh sidecar allows you to discover the agent location, topic, or queue name during message production and use. This involves dealing with different topic hierarchies and wildcards.

Message authentication: validating messages for event-driven messaging is becoming more and more important because most messaging protocols (such as Kafka, NATS, etc.) are protocol independent. Therefore, message authentication is part of the consumer or producer implementation. Service Mesh can provide this abstraction so that consumers or producers can transfer message validation. For example, if you use Kafka and Avro together for schema validation, you can use sidecar for validation (that is, get the schema from an external scheme registry, such as Confluent, and validate messages against that schema). You can also use it to check messages for malicious content.

Message compression: some event-based messaging protocols, such as Kafka, allow data to be compressed by producers, written to the server in a compressed format, and decompressed by consumers. You can easily implement these functions at the sidecar-proxy level and control them on the service-mesh control plane.

Security: you can secure communication between agents and consumers / producers by enabling TLS at the service-mesh sidecar level, so that your producer and consumer implementations don't have to worry about secure communication, but can communicate with sidecar in plain text.

Observability: since all communication occurs on the service-mesh data plane, metrics, tracking, and out-of-the-box logging can be deployed for all event-driven messaging systems.

About the author

Kasun Indrasiri is the director of integration architecture for WSO2 and the author / communicator of microservices architecture and enterprise integration architecture. He is the author of "Micro Services Enterprise (Apress) and start WSO2 ESB (Apress)". He is an Apache submitter and a former product manager and architect for WSO2 Enterprise Integrator. He has attended O'Reilly Software Architecture Conference, GOTO Chicago 2019 Conference and most WSO2 conferences. He attended most of the microservices meetings in the San Francisco Bay area. He created Silicon Valley microservices, API and integration conferences, which are vendor-neutral microservices conferences in the Bay area.

This article is originally translated and published by Boyun Research Institute. Please indicate the source when reproduced.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.