Detailed explanation of the three major communication methods between microservices: Gateway API, RPC and SideCar

[[442456]]

0. Introduction

I believe everyone is familiar with microservices. Traditional monolithic applications have many disadvantages, such as centralized management of code data, low development efficiency, slow startup, poor reliability, and single technology. Microservices, on the other hand, have many advantages, such as functional splitting, autonomy, loose coupling, cross-language, and lightweight communication.

Let's break down the details step by step. First, we will introduce the three major communication methods between microservices: gateway API-based, RPC-based, and SideCar-based.

1. Based on Gateway API

In simple terms, the functions of the gateway API can be divided into four parts:

1). Request access

Provide unified service access for various applications

Process all access requests

2) Governance strategy

Including load balancing, current limiting, circuit breaking, timeout retry, grayscale release, protocol adaptation, traffic monitoring, log statistics, etc.

3). Authentication

Including user authentication, identity verification, blacklist and whitelist management, web attack prevention, etc.

4). Unified management

Manage all services and policies

Provides tools for configuration management

2. RPC-based

RPC refers to remote process call. If two applications A and B are deployed on two servers respectively, if A wants to call a function on application B, what should it do since they are not in the same memory space? In this case, the semantics of the call and the data of the call need to be expressed through the network.

Mainstream RPC frameworks include Dubbo, gRPC, bRPC and Thrift

From the github star, Dubbo > gRPC > bRPC > Thrift.

3. Based on SideCar

When talking about SideCar, we always associate it with Service Mesh. What is Service Mesh? Service Mesh represents a relationship between services after SideCar technology is applied on the cloud, as shown in the following figure:

SideCar can be said to be a technology born in the post-Kubernetes era. Its relationship with native Kubernetes is shown in the following figure:

In native K8S, each node has a kube-proxy, while in Service Mesh, each pod has a proxy (SideCar). This proxy (the blue part in the above picture) can be deployed as an independent container or deployed in the same container with the business process (the green part in the above picture). Multiple proxies in a node are identical copies of the same proxy. This is also easy to understand! If each business process has a different proxy, then the existence of SideCar is meaningless.

Using Service Mesh does not mean that it will break with Kubernetes, but it will happen naturally. The essence of Kubernetes is to manage the application lifecycle through declarative configuration, while the essence of Service Mesh is to provide traffic and security management and observability between applications.

The representative technology of SideCar is istio, and its control plane implementation is Envoy.

Istio Service Mesh can use services in Kubernetes for service registration. It can also connect to other service discovery systems through the platform adapter of the control plane, and then generate the configuration of the data plane (using CRD statements, stored in etcd), a transparent proxy for the data plane.

The "transparent proxy" is deployed in the sidecar container in each application service pod. These proxies need to request the control plane to synchronize the proxy configuration. The reason why it is a transparent proxy is that no application container is fully aware of the proxy. The process kube-proxy component likes to block traffic, but kube-proxy blocks the traffic of the Kubernetes node, and the sidecar proxy blocks more information outside the pod.