Comprehensively interpret the background and concept of service mesh

author ：xcbeyond

Blog ：https://xcbeyond.cn/ official account ： Program ape technology

all the time “ Microservices ” Is a popular word , In various technical articles 、 At the conference , There are many discussions and topics about microservices . Based on Dubbo、SpringCloud Microservice architecture of technology system , Already quite mature and well known , But with the increasing complexity of the Internet scene 、 Rapid business change and rapid response , How fast 、 Stable 、 Efficient response to unpredictable business market demand , This kind of technology system （ Such as ：Spring Cloud） The traditional microservice architecture has become more powerful , At this point, the microservice architecture is upgraded again , take Service Grid As a new generation of microservice Architecture .

This paper will start from the traditional micro service architecture , Explain the new generation of microservice Architecture – Service Grid , What problems can it solve , What it brings to users , It can be used as your cognition of service grid .

1、 background

Microservices , Also known as microservice Architecture , It's an architectural style , Compared with monomer application , It splits the application into a set of services , And combine these services to complete the whole complex business function . The following features can highly reflect its value ：

• High maintainability and testability
• loose coupling
• Independent deployment
• Organize around business capabilities
• Small teams have

After a brief review of the concept of microservice Architecture , Let's take a look at how a new generation of microservice architecture was born .

1.1 be based on Spring Cloud Our microservice system

The following diagram is based on Spring Cloud Microservice architecture diagram of technology system ：

For the above figure , From the following two aspects ：

• Technology stack ： as everyone knows ,Spring Cloud There are many related technical components , Although most of them are out of the box , Once the depth is used , The cost of learning is high , For starters （ Not Spring Cloud Users ） The threshold is very high .（ Too much , And you have to master , It's too hard ！）
  

• Realization ： All microservices need to register themselves in the registry （ Such as ：Consul、Eureka etc. ）, To complete the mutual call between services . Every microservice must rely on Spring Cloud Components （ namely ： stay pom.xml Introduction in ）, Business logic and Spring Cloud Components co-exist in the same service .

Remember Spring Cloud Related component versions upgrade The trouble of ？ In order to use a feature in the new version , Or solve the loopholes in the old version ,Spring Cloud Version upgrades are common , If you are not careful, there will be version dependency conflicts 、 Can't start, etc , After the upgrade, testers have to be arranged to test and verify . Low technical content , But it's really annoying .

The perfect program , It can't avoid zero bug. After the launch , With the diversity of system usage scenarios , Will gradually expose some problems , And if there is a problem, we have to solve it , and With great care Arrange to go online , This series of processes , You must be deeply touched , Each has a story . use “ With great care ” It is no exaggeration to describe this process , Because a small change may affect other , Even the whole system , No one wants to carry this pot , The principle of "don't change without killing" has always been a barrier that we don't want to break .

In the traditional industry （ Such as ： Bank ）, Due to the diversity of the system 、 huge 、 complexity , It is unrealistic to join the ranks of micro services , New and old systems coexist Is one of the most common phenomena . And governance between coexisting systems 、 Operation and maintenance has become a long-standing problem .

Face upgrade 、 maintain 、 The coexistence of new and old systems , Is there nothing to do ？

1.2 The challenge of traditional microservice Architecture

In the face of the problems exposed above , And under the traditional microservice Architecture , After the constant impact of practice , Facing more new challenges , in summary , The reasons for these problems are as follows ：

• Over binding specific technology stacks When it comes to heterogeneous systems , It takes a lot of effort to transform the code , Different heterogeneous systems may face different transformations .
• Code intrusion is too high Developers often need to spend a lot of energy thinking about how to work with frameworks or SDK combination , And better in-depth integration in the business , For most developers, it's a high curve learning process .
• Multilingual support is limited Microservice advocates that different components can be developed in the most suitable language , But the traditional microservice framework , Such as Spring Cloud It is Java Of the world , Multi language support is very difficult . This also leads to the helplessness in the face of heterogeneous system docking , Or choose the second best plan .
• Old systems are hard to maintain Facing the old system , It's hard to achieve unified maintenance 、 government 、 Monitoring etc. , In the transitional period, it often needs to be managed by multiple teams , More difficult to maintain .

These problems are inevitable , We all know that technological evolution comes from constant exploration in practice , Abstract function 、 decoupling 、 encapsulation 、 As a service . With the traditional microservice architecture exposed these problems , There will be new challenges , Let's look for other solutions .

1.3 Ushering in a new generation of microservice architecture

In order to solve the problems faced by traditional micro Services , To meet new challenges , Microservice architecture is also evolving , Finally, the service grid （Service Mesh） Appearance , Ushered in a new generation of microservice Architecture , Also known as the next generation of microservices . Just to understand Service Mesh The concept and significance of being , Let's review the four stages of this evolution .

• The coupling phase ： Highly coupled 、 Repeated implementation 、 Difficult to maintain , It is most prominent in the design of coupling architecture , Monomer architecture is a typical example .
• public SDK： Make infrastructure functional design public SDK, Improve utilization , Is the most effective way to untie the lotus root , such as Spring Cloud In a similar way . But learning costs are high 、 Specific language implementation , But stopped some people outside the door .
• Sidecar Pattern ： Deep decoupling again , Not just functional decoupling , More from cross language 、 Update release and operation and maintenance , Achieve zero intrusion into business services , It is more rooted in the development language and a single technology stack , Complete isolation , For deployment 、 Upgrading brings convenience , The real infrastructure layer is completely decoupled from the business logic layer . On the other hand ,Sidecar It can provide more flexible extension for application services more quickly , It doesn't need a lot of transformation of application services .
• Service Mesh： hold Sidecar The pattern is fully applied to a huge microservice architecture system , Deploy one for each application service Sidecar agent , Complete complex communication between services , Finally, you will get a network topology , This is it. Service Mesh, Also known as “ Service Grid “. It essentially solves the problems faced by traditional microservices .

2、 Introduction to service grid

This section starts with the definition of service grid 、 The core value of 、 Architecture, etc , Let you have a full understanding of it 、 understand .

2.1 Definition of service grid

Service Grid （Service Mesh）, As the infrastructure layer of inter service communication . It is a lightweight high-performance network agent , Provide safe 、 fast 、 Reliable inter service communication , Together with practical application deployment , But transparent to applications . The application as the initiator of the service , Just send the request to the local service grid agent in the simplest way , Then the grid agent does the following , Such as service discovery , Load balancing , Finally, forward the request to the target service .

Sum up , Here's the picture ：

2.2 The core value of service grid

Realize the separation of business logic and non business logic .

• To make it possible to sink into infrastructure ： Sink microservice communication to the infrastructure layer , It shields the complexity of microservices in dealing with various communication problems .
• Help apply lightweight , Focus on business ： Developers do not need to care about the specific implementation of communication layer and service governance , Really use microservices like local calls , All work related to communication is directly entrusted to Service Mesh, Let developers pay more attention to business development .
• Realize the cloud original biochemistry of the application ： Accelerate application to the cloud , Realize cloud original biochemistry

2.3 Main functional features

So what practical functions can service grid bring ？

• flow control ： Provide intelligent routing for applications （ Such as , Release of canary 、A/B Testing, etc ）、 Time out to try again 、 Fuse 、 fault injection 、 Traffic image and other control capabilities .
• Strategy ： You can set quotas for traffic 、 Black and white list and other strategies .
• Network security ： Provide inter service access control 、 TLS Encrypted communication .
• Observability ： Generate detailed telemetry data for all communications , Including indicator data 、 journal 、 track , Provide the application system with complete monitoring capability .

2.4 The overall architecture

The overall architecture of the service grid is shown in the figure below ：

The main core content is divided into ：

• Control plane ： Control and manage data in the data plane Sidecar agent , Complete configuration distribution 、 Service discovery 、 Traffic routing 、 Authorization, authentication and other functions , To achieve unified management of the data plane .
• Data plane ： By... In the whole grid Sidecar The composition of the agency , These agents are based on Sidecar Deployed together with application services . These agents are responsible for coordinating and controlling all network communication between application services . every last Sidecar Will take over the traffic entering and leaving the service , And cooperate with the control plane to complete the functions of flow control and so on .

2.5 Istio frame

Istio By Google 、IBM and Lyft The open source service grid framework . The project is in progress. 2017 Launched in 2013 , So far... Has been released 1.10.1 edition .

Istio Provides a complete solution , Provide behavior insight and operation control for the whole service grid , To meet the diverse needs of microservice applications .

2.5.1 Istio Data plane

Istio Default data plane for Envoy , Is based on Envoy Added some extensions （ namely ：istio-proxy）,C++ Language writing .

The main duties and responsibilities ：

• Service discovery ： Probe all available upstream or downstream service instances .
• Health detection ： Detect whether the upstream or downstream service instance is healthy , Are you ready to receive network traffic .
• Traffic routing ： Route network requests to the correct upstream or downstream services .
• Load balancing ： When requesting upstream or downstream Services , Select the appropriate service instance to receive the request , At the same time, it is responsible for handling timeout 、 Open circuit 、 Try again, etc .
• Authentication and Authorization ： stay istio-agent And istiod With the help of , Authenticate network requests 、 Authority verification , To determine whether and how to respond , Use mTLS Or other mechanisms to encrypt the link, etc .
• Link tracking ： For each request , Generate detailed statistics 、 Logging and distributed tracking data , So that the operator can understand the call path and debug in case of problems .

2.5.2 Istio Control plane

since Istio 1.5 Version start , The control plane is dispersed from the original 、 Three components deployed independently （Pilot、Citadel、Galley） Integrate into an independent istiod, It becomes a single process 、 Multi module organization （ Below, right ）, It greatly reduces the complexity of the original deployment .

• Pilot： be responsible for Istio Data plane xDS Configuration Management , Including service discovery 、 Configure rule discovery 、xDS Configure distribution .
• Citadel： Be responsible for the management and issuance of safety certificates , Realize authorization, authentication and other operations .
• Galley： Responsible for configuration verification 、 Functions such as extraction and processing , take Istio And the underlying platform ( Such as ,Kubernetes) Decoupling .

among ,Citadel、Galley Components are gradually weakening , stay Istio In the version iteration , They are almost invisible .（ Has been continuously integrated into other components ）

Next , Focus on Pilot Components .

Pilot yes Istio The core component of , Used to manage and configure deployment in a specific environment Istio All in the service grid Sidecar Proxy instance . It manages Sidecar Routing traffic rules between agents , And configure the fault recovery function , Such as overtime 、 Retry and fuse, etc .

Key modules ：

• Abstract model （Abstract model）： In order to realize the registration of different services （ Such as ,Kubernetes、Consul） Support for , Complete the abstraction of data from different input sources , Form a unified storage format .
• Platform adapter （Platform adapters）： With the help of platform adapter Pilot Implement the data transformation from service registry data to abstract model .
• xDS API： It's from Envoy Standard data plane for the project API, Distribute the service information and traffic rules to the data plane Sidecar. By adopting this standard API, Istio Understand the control plane and the data plane , For multiple data planes Sidecar Implementation provides the possibility , Such as ： Ant financial open source Golang Version of MOSN.
• user API（User API）： It provides business oriented high-level abstraction , It can be understood and used by operation and maintenance personnel .

3、 summary

Let's review ,Spring Cloud Microservice architecture and Service Mesh Microservice architecture ：

In order to solve the invasive problem of microservice framework , We introduce the service grid .

---

Reference material ：

1. https://microservices.io/
2. Build on Spring Cloud towards Service Mesh Framework migration solutions and ideas