The opening words | Service Mesh, as a new milestone in the traditional micro Service architecture
Service Mesh is an infrastructure layer that handles communication between services. The most important changes in the Service Mesh are the introduction of the concepts of data and control surfaces: Sidecar mode is used to separate the original code in SDK, replace some functions of configuration center with control surface, provide safe, fast and reliable communication between services in the form of transparent proxy, and realize the basic component functions required by microservices.
In fact, the basic components required for a Service Mesh are not that different from traditional microservices. Many companies choose to develop their own control surfaces because they are compatible with older microservice infrastructure components. You can think of a Service Mesh as a distributed microservice proxy.
As the representative of Service Mesh, Istio became an industry star thanks to the explosion of container technology
Introduction | Service Mesh: starting from the single Service, independent of the architecture of the evolution of business Service
- There is no silver bullet
Like other existing architectures and solutions, the microservices architecture is not a silver bullet. Of course, it solves many problems of single service, but it also brings some problems that do not exist in single service, such as load balancing, service governance, service registration discovery, how to split services, etc. Of course, most of these problems can be solved by technical means, but also increase the complexity of the system.
- Basic components and common terms of Service Mesh
One of the most important changes to Service Mesh is the introduction of the concepts of the data and control surfaces. This concept is not new to Service Mesh. In fact, the concepts of the control and data surfaces already exist in the SDN.
Before we begin, let’s take a quick look at the control surface and the data surface.
- Data Plane
Responsible for data forwarding, generally we common general gateway, Web Server, such as Nginx, Traefik can be considered as a kind of data plane. In the open source world of Service Mesh, Envoy is arguably the most well-known data facet.
In addition, the data surface is not limited to gateway products, in fact, some RPC frameworks can also act as data surface, such as gRPC has supported a complete xDS(data surface and control surface interaction protocol), can also be used as data surface. The data side responsible for data forwarding is usually referred to as a sidecAR.
- Control Plane
The xDS protocol is used to control the behavior of data planes, such as routing and forwarding, load balancing, and service governance. The appearance of the control surface solves the problem that both the framework and the data surface and sidecar lack control ability. In addition, the data surface can only be controlled through the batch modification of the CONF in o&M before, and the purely manual maintenance cost and greatly increased error probability caused by the scale increase are also solved.
In fact, the basic components required for Service Mesh are not that different from traditional microservices, and many companies choose their own control surfaces to be compatible with the basic components of older versions of microservices.
Let’s look at the basic components of the Service Mesh.
Service registries: Basic components for communication between services. By registering its own node, the calling service can discover the called service node to achieve the purpose of point-to-point communication between services.
Configuration center: Basic configuration updates for services to separate code from configuration. Reduce the number of service publications and configure publications to change services more quickly and in a timely manner.
API gateway: Through a unified gateway layer, it converges basic services such as the unified authentication layer and link ID generation, and aggregates back-end services to provide RESTful interfaces for clients. In addition, the API gateway is also responsible for the management of north-south traffic (extranet traffic).
Service governance: Prevent the potential avalanche of microservice architecture through basic components such as traffic limiting and fusing.
Link tracing: The entire microservice link can be clearly drawn through trace, and precise fault diagnosis can be performed, greatly reducing the difficulty of fault diagnosis.
Monitoring alarms: Draw the service status monitoring panel through basic components such as Prometheus and Grafana, and accurately monitor and alarm resources, services, and business indicators.
Having said the basic components, let me explain some common terms to help you understand the Service Mesh.
Upstream: If service A calls service B, service B is considered an Upstream service from A’s perspective. Therefore, in order to avoid language ambiguity, I will directly use upstream instead of Chinese translation. In the Chinese context, I prefer to call it the server or the called party.
Downstream: A Downstream service. If A service invokes B, A service is A Downstream service in THE view of B service. In The Chinese context, I prefer client or caller.
Endpoint: specifies the service node. For example, service A has 192.168.2.11 and 192.168.2.12 service nodes.
Cluster: refers to A Service Cluster. For example, Service A has two Service nodes 192.168.2.11 and 92.168.2.12. Therefore, Service A is A Cluster and can be directly referred to as Service.
Node: in the context of Kubernetes, refers to the server hosting pod, but in the context of microservices, is more equivalent to an Endpoint.
The Route: It refers to the route configuration in the Service Mesh. For example, Service A needs to match certain rules to access Service B. For example, the header needs to contain the Service name (-h Servicename :B) to obtain the access mode of Service B. Nodes of service B are accessed through service discovery or static lists.
Listener: Refers to the listening port of the Service Mesh. When accessing the data plane of the Service Mesh, you need to know the listening port of the data plane
Components: 01 | registry: micro service center
-
Service registration and discovery ensures that service consumers and service providers can communicate when a service changes online or offline.
Registries are the most important component of microservices and the biggest point of difference in communication with a centralized bus in an SOA architecture. Today, I’ll talk to you about the registry
-
Service Registration Discovery
The greatest use of service registration discovery is to solve the problem of manually configuring the service address in the gateway or LB. You can automatically have the calling service discover the machine node of the called service without manual configuration
Therefore, the AP system is preferred in selection.
If the technology stack is Go, but you are concerned about the maintenance of Java components, you can also consider a home-grown registry. Of course, the CP registry is not unavailable, but in the case of small service cluster size, it is also an option
Component 02 | registry: how to build a high availability, robust registry?
In addition to the traditional registry components, the discovery mechanism inside Kubernetes is also widely used in the Service Mesh. For example, Istio monitors the changes of The Kubernetes Pod to realize the function of Service discovery, so that the Service itself does not need to register the Service.
What are the advantages of the registry discovery functionality implemented in Service Mesh over traditional microservices?
- The sidecar agent does not register the service itself
Sidecar registers services by receiving configuration information delivered from the control plane. In this way, the workload of service development can be reduced compared with that of service registration, and the configuration information of registration can be consistent easily. For example, if the service is registered by itself, it is difficult to control the metadata information registered by the service, and it is difficult to restrict and upgrade the metadata information in the SDK, such as the operating environment, region, and health check method.
Sidecar agents also bring the benefit of being able to update meta information at any time. In the traditional SDK mode, when you want to dynamically adjust the weight and metadata of services, you need to republish the version or rely on the configuration center’s ability. However, the control information is scattered in various services, which makes it difficult to manage. In the Service Mesh, you only need to rely on the control plane’s ability. You can easily do that.
- Aggregate multiple and multiple registry data through control surfaces
Istio’s Pilot module, for example, supports multiple clusters on a single control plane in version 1.1. By aggregating data from multiple registries through pilot, it can effectively reduce the read and write pressure of a single registry and make it easier for the registry to scale horizontally.
In practice, for example, I aggregated data from Multiple Consul data centers through pilot module and then provided xDS protocol for service discovery, enabling seamless migration of VIRTUAL machines to Kubernetes environment.
- Provides the service correctness check function through sidecar
As we mentioned last time, one of the health checks in the registry is the registry active ping mode. In fact, if the service IP address changes and the same ping interface is used, a health check error occurs. In sidecar mode, when traffic from the ping interface is detected, the service name is detected. The service name is added to the header to verify the service name with the local service name to avoid such errors.
FQA
Hi teacher, I want to ask what is the biggest advantage of servicemesh architecture compared to traditional microservices architecture? I read a lot of articles on the Internet, but I was still a little confused
Lecturer’s reply: Most people only answer about multilanguage compatibility, don’t need to develop multiple language SDKS, but ignore the core point that infrastructure can evolve independently. For example, with traditional microservices architectures, upgrading the SDK becomes impossible as the number of services increases.
1 AP is recommended, why k8S uses ETCD?
Etcd is also known to be a performance bottleneck in large-scale K8S cluster scenarios, and many companies have already modified etCD or adopted other storage methods. Due to the bottleneck of ETCD, the cluster scale of K8S is also limited. Now it is more common to build multiple SETS of K8S clusters
Now we do not use zK, ETCD, recommend AP type here?
Lecturer’s reply: pay attention to the content of the article, “CP registry is not unavailable, in the case of small service cluster size, it is also optional”.
Eureka’s typical AP is suitable as a product of service discovery in distributed scenarios, where availability is a high priority and consistency is not particularly fatal.
CP scenario Consul also provides high availability and consistency with k-V Store service. However, Zookeeper and Etcd sacrifice availability and do not have much advantage in service discovery scenarios.