This is the first day of my participation in the Gwen Challenge in November. Check out the details: the last Gwen Challenge in 2021

Microservice is a hot term in software architecture in recent years, and it is also a very big concept. Different people have different understandings of it, and even a batch of different microservice architecture products appeared in the early microservice architecture. Some people call application services that simply introduce frameworks such as Spring Boot and Spring Cloud as microservices architecture, but this is just a Web container for services.

With the popularity of micro-services, more and more teams have begun to practice micro-services and put them into production. However, as microservices continue to grow in scale, each additional microservice may increase some dependent infrastructure and third-party configuration, such as Kafka, Redis instances, etc., and the corresponding CI/CD configuration may also be increased or adjusted. At the same time, with the increase of the number of microservices, the improvement of business complexity and the diversity of demands (such as the connection with third-party heterogeneous systems), the complexity of communication between services makes microservices more bloated step by step, and service governance is also more difficult. These problems can be easily solved in a single architecture. For this reason, some people are beginning to question the wisdom of microservitization and even consider returning to traditional monolithic applications.

As shown in the figure below, micro services in PPT are always good, but in reality micro services are a mess of cake, want to throw off, more and more look bad. Is there nothing to be done?

1. Challenges faced by traditional microservices architecture

In the face of the problems exposed above, and in the traditional micro-service architecture, after continuous impact of practice, it faces more new challenges. In summary, the reasons for these problems are as follows:

  • Too much binding to a particular technology stack. When faced with heterogeneous systems, it needs to spend a lot of energy to carry out code transformation, and different heterogeneous systems may face different transformation.
  • Code intrusion is too high.Developers often have to spend a lot of energy thinking about how to interact with the framework orSDKCombining, and better deep integration in the business, is a high-curve learning process for most developers.
  • Multi-language support is limited.Microservices advocate that different components can be developed using the language that best suits them, but traditional microservices frameworks such asSpring CloudIt isJavaIn the world of multilingual support is very difficult. This leads to the helplessness in the face of heterogeneous system docking, or choose the next best solution.
  • Old systems are difficult to maintain. In the face of the old system, it is difficult to achieve unified maintenance, governance, monitoring and so on. In the transition period, multiple teams are often needed to manage it, making maintenance more difficult.

All of these problems are inevitable in traditional microservice architectures. We all know that technological evolution comes from practice, which abstracts, decoubles, encapsulates, and servifies functions. As these problems are exposed in traditional microservices architectures, new challenges will emerge, leaving everyone looking for alternative solutions.

2. Usher in a new generation of micro-service architecture

In order to solve the problems faced by traditional microservices and meet the new challenges, the microservice architecture is further evolved, which eventually gives birth to the emergence of Service Mesh, ushering in a new generation of microservices architecture, also known as the “next generation of microservices”. To better understand the concept of Service Mesh and why it exists, let’s review this evolution.

1.1 Coupling Stage

In microservice architecture, service discovery, load balancing, fuse and other capabilities are important components of microservice architecture. After microservitization, services become more decentralized and more complex. At the beginning, developers encapsulate functions and business codes, such as circuit breaker and timeout, so that services have the ability of network control, as shown in the figure below.

Although this scheme is easy to implement, it has some defects in terms of design.

  • Infrastructure functions (e.g., service discovery, load balancing, fuses, etc.) and business logic are highly coupled.
  • Each microservice repeats code that implements the same functionality.
  • Management difficulties. If a service’s load balance changes, the related services that call it all need to update the change.
  • Developers can’t just focus on business logic development.

1.2 Common library SDK

Based on the above problems, it is easy to think of designing the infrastructure functions as a public library SDK, so that the business logic of the service and these public functions can reduce the coupling degree, improve the reuse rate, and more importantly, developers only need to focus on the dependence and use of the public library SDK, rather than the implementation of these public functions. To focus more on business logic development, such as the Spring Cloud framework, in a similar way. As shown below:

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

  • These common librariesSDKThere is a steep learning cost, requiring developers to spend some time and effort integrating with existing systems, or even to consider modifying existing code for integration.
  • These common librariesSDKThey are generally implemented by specific languages, lack of multi-language support, and have certain limitations in the integration of existing systems.
  • The public librarySDKThe management and maintenance still need to consume a lot of energy of developers, and need specialized personnel to manage and maintain.

1.3 sidecars mode

Inspired by the common library SDK above, plus cross-language issues, updated distribution and maintenance, it was found that a better solution was to use it as a proxy through which the service could do all traffic control transparently.

This is the typical Sidecar proxy pattern, also translated as “Sidecar” proxy, which acts as a bridge to communicate with other services, provides additional network features for the service, and is deployed independently of the service, with no intrusion into the service, and is not limited by the development language and technology stack of the service, as shown in the figure below.

The communication proxy in Sidecar mode realizes the complete isolation between the basic implementation layer and the business logic, which brings convenience in deployment and upgrade, and achieves the complete decoupling between the real infrastructure layer and the business logic layer. Sidecar, on the other hand, can provide more flexible extensions to application services more quickly, without requiring a significant overhaul of application services. Sidecar provides the following functions:

  • Service registration. Help the service register with the appropriate service registry and perform relevant health checks on the service.
  • Service routing.When an application service calls another service,SidecarYou can find the corresponding service address from the service discovery and complete the service routing function.
  • Service governance. SidecarIt can completely intercept the incoming and outgoing traffic of the service, and perform corresponding operations such as call chain tracing, fusing, degrade, and log monitoring. The service governance function is centralized inSidecarIn the implementation.
  • Centralized control.All services in the entire microservices architecture can passSidecarTo carry out centralized control and complete the flow control and offline of services.

As a result, application services can finally be developed across languages and more focused on business logic.

1.4 Service Mesh

When the Sidecar mode is fully applied to a huge micro-service architecture system, a Sidecar agent is deployed for each application Service to complete the complex communication between services. Finally, a network topology as shown in the figure below is obtained, which is Service Mesh, also known as “Service Mesh”.

At this point, a new generation of microservice architecture, Service Mesh, is ushered in, which completely solves the problems faced by traditional microservice architecture.