Istio practice manual ｜ meeting the new generation of microservice architecture

author ：xcbeyond

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

《Istio Practice Manual 》, Starting from the concept of service grid , Will gradually penetrate into Istio In the specific details , To help Istio Learners' 、 Users quickly master relevant knowledge points , Can be used as Istio Study 、 Practice Manual .

The article was first published in 《Istio Practice Manual 》

Microservice is a hot term in software architecture in recent years , It's also a big concept , Different people have different understanding of it , Even in the early microservice architecture, a number of microservice architecture products appeared , Some people introduce simplicity into Spring Boot、Spring Cloud The application services of such frameworks are also called micro service architecture , But this is just a service Web It's just a container .

With the popularity of micro Services , More and more teams are starting to practice , Micro services will be launched one after another , And put it into production . But with the growing scale of micro Services , Every time you add a micro service , It is possible to increase some dependent infrastructure and third-party configuration , such as Kafka 、Redis Examples, etc , The corresponding CI/CD The configuration will also be increased or adjusted . At the same time, as the number of micro services increases 、 The increase of business complexity and the diversity of demand （ Such as , Docking with third-party heterogeneous systems, etc ）, The complexity of inter service communication , Step by step, micro services will become more bloated , Service governance is even more difficult , These problems are easy to solve in a single architecture . So , Some people began to doubt whether micro service was a wise choice at the beginning , Even consider returning to traditional monomer applications .

As shown in the figure below ,PPT Micro services in the Internet are always beautiful , But the reality of micro services is a mess , I can't get rid of it , The more I look at it, the worse I feel . Is there no way ？

chart 2.1.1： Realistic neutralization PPT Comparison of microservices in

1、 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 in the traditional microservice Architecture , 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 .

2、 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 , At last, it gave birth to Service Mesh Appearance , Ushered in a new generation of microservice Architecture , Also known as “ Next generation microservices ”. Just to understand Service Mesh The concept and significance of being , Let's review this evolution .

1.1 The coupling phase

In the microservices architecture , Service discovery 、 Load balancing 、 Fusing and other capabilities are important components of microservice architecture . After micro service , Services are more decentralized , It's getting more complicated , At first, developers will be like 、 Time out and other functions are encapsulated with business code , Make the service have the ability of network management and control , As shown in the figure below .

chart 2.1.2： The coupling phase

Although this scheme is easy to implement , But from the design point of view, there are some defects .

• Infrastructure functions （ Such as , Service discovery , Load balancing 、 Fuses, etc. ） Highly coupled with business logic .
• Each microservice repeats the code that implements the same function .
• Management is difficult . If the load balance of a service changes , The related services that call it need to be updated and changed .
• Developers can't just focus on business logic development .

1.2 The public library SDK

Based on the above problems , It's easy to think of designing infrastructure functions as a public library SDK, Reduce the coupling between the business logic of the service and these common functions , Improve reuse , More importantly, developers only need to focus on public libraries SDK The dependence and use of , Instead of focusing on realizing these common functions , So as to focus more on the development of business logic , such as Spring Cloud Framing is a similar way . As shown in the figure below ：

chart 2.1.3： The public library SDK Stage

In fact, even so , It still has some shortcomings .

• These public libraries SDK There are steep learning costs , It takes a certain amount of time and manpower for developers to integrate with the existing system , You even need to consider modifying existing code to integrate .
• These public libraries SDK It's usually implemented in a specific language , Lack of multilingual support , There are some limitations in the integration of existing systems .
• The public library SDK It still takes a lot of effort for developers to manage and maintain , And need special personnel to manage and maintain .

1.3 Sidecar Pattern

With the Public Library above SDK Inspired by the , Plus cross language issues 、 The issue and maintenance of the update , People have found that a better solution is to use it as an agent , The service controls all traffic through this transparent agent .

That's typical Sidecar The proxy pattern , Also translated as " Side car " agent , It serves as a bridge to communicate with other services , Provide additional network features for services , And independently deployed with services , Zero intrusion into services , It will not be limited by the development language and technology stack of services , As shown in the figure below .

chart 2.1.4：Sidecar Mode phase

With Sidecar Mode for communication agent , It realizes the complete isolation between the basic implementation layer and the business logic , In the deployment 、 Upgrade 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 .Sidecar It can realize the following main functions ：

• Service registration . Help the service register with the corresponding service registry , And do the relevant health examination for the service .
• Service routing . When an application service calls another service ,Sidecar It can help to find the corresponding service address from the service discovery , Complete the service routing function .
• Service governance . Sidecar It can completely intercept the traffic in and out of the service , And the corresponding call chain tracking 、 Fuse 、 Downgrade 、 Log monitoring and other operations , Focus the service governance function on Sidecar To realize .
• Centralized control . All the services under the whole microservice architecture can pass through Sidecar For centralized control , Complete the flow control of services 、 Offline, etc .

therefore , Finally, application services can be developed across languages 、 And more focused on business logic development .

1.4 Service Mesh

hold Sidecar The model 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 as shown in the figure below , This is it. Service Mesh, Also known as “ Service Grid “.

chart 2.1.5：Service Mesh Stage

thus , Ushered in a new generation of microservice Architecture ——Service Mesh, It will completely solve the problems faced by the traditional microservice Architecture .