Shulou(Shulou.com)06/01 Report--

This article mainly explains "how Spring Cloud migrates to Service Mesh framework". The explanation in this article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "how Spring Cloud migrates to Service Mesh framework".

1. Background

Micro-service is a hot term in software architecture in recent years, and it is also a big concept. Different people have different understandings of it, and even a number of micro-service architecture products appeared in the early micro-service architecture. Some people simply introduce Spring Boot and Spring Cloud framework into the micro-service architecture, but only regard it as the Web container of the service.

With the popularity of micro-services, more and more teams begin to practice, landing micro-services and putting them into production one after another. However, with the continuous growth of the scale of micro-services, with each addition of micro-services, some dependent infrastructure and third-party configurations, such as Kafka instances, may be added, and the corresponding CI/CD configuration will also be increased or adjusted. At the same time, with the increase in the number of micro-services, the improvement of business complexity and the diversity of requirements (for example, interfacing with third-party heterogeneous systems, etc.), the communication between services is complex, which makes micro-services more bloated step by step. Service governance is also more difficult, and these problems can be easily solved in a single architecture. For this reason, some people begin to doubt whether micro-service is a wise choice, and even consider returning to traditional monolithic applications.

As shown in the figure below, microservices in PPT are always beautiful, but in reality, microservices are a mess, and the more you want to get rid of them, the worse you get. Is there nothing you can do about it?

1.1 challenges faced by traditional microservice architectures

In the face of the problems exposed above, and under the traditional micro-service architecture, we are faced with more new challenges through the continuous impact of practice. to sum up, the reasons for these problems are as follows:

Too bound to a specific technology stack. When faced with heterogeneous systems, it takes a lot of energy to transform the code, and different heterogeneous systems may face different transformations.

The code intrusion is too high. Developers often need to spend a lot of energy to think about how to integrate with the framework or SDK, and better integration in the business, which is a high curve learning process for most developers.

Multilingual support is limited. Microservices advocate that different components can be developed in the language most suitable for it, but under the Spring Cloud framework, Java dominates the world, and multi-language support is very difficult. This also leads to the helplessness or the second best solution in the face of heterogeneous system docking.

The old system is difficult to maintain. In the face of the old system, it is difficult to achieve unified maintenance, governance, monitoring and so on. In the excessive period, multiple teams are often needed to manage it, which makes it more difficult to maintain.

All these problems are inevitable. We all know that the technological evolution comes from the continuous exploration in practice, which abstracts, decouples, encapsulates and services the functions. With these problems exposed by the traditional micro-service architecture, there will be new challenges for everyone to look for other solutions.

1.2 usher in a new generation of micro-service architecture

In order to solve the problems faced by traditional micro-services and meet the new challenges, the micro-service architecture has further evolved, which finally led to the emergence of Service Mesh and ushered in a new generation of micro-service architecture, also known as the next generation of micro-services. In order to better understand the concept and meaning of Service Mesh, let's review this evolution.

1.2.1 Coupling Pha

In the micro-service architecture, service discovery, circuit breaker, governance and other capabilities are important components of the micro-service architecture. After micro-service, the service becomes more decentralized and more complex. At first, developers encapsulate functions such as circuit breaker and timeout with business code, so that the service has the ability to control the network, as shown in the following figure.

Although this scheme is easy to implement, it has some defects from the design point of view.

Infrastructure functions (such as service discovery, load balancing, circuit breakers, etc.) are highly coupled with business logic.

Each microservice repeats the code that implements the same function.

It is difficult to manage. If the load balance of a service changes, the related services that call it need to be updated.

Developers can't just focus on business logic development.

1.2.2 Common Library SDK

Based on the above problems, it is easy to think of designing infrastructure functions as a common library SDK to reduce the coupling of service business logic with these functions and improve reuse. More importantly, developers only need to pay attention to the dependence and use of the common library SDK, rather than the implementation of these common functions, so as to focus more on the development of business logic. For example, the Spring Cloud framework is a similar approach. As shown in the following figure:

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

These common libraries SDK have steep learning costs, which take developers a certain amount of time and manpower to integrate with existing systems, and even need to consider modifying existing code for integration.

These common libraries SDK are generally implemented in specific languages, lack of multi-language support, and have some limitations in the integration of existing systems.

The management and maintenance of the common library SDK still requires a lot of energy from developers, and special personnel are needed to manage and maintain it.

1.2.3 Sidecar mode

Inspired by the above common library SDK, coupled with cross-language problems, updated release and maintenance, people find that a better solution is to use it as an agent, and the service controls all traffic through this transparent agent.

This is a typical Sidecar agent pattern, which is also translated as a side car agent, which acts as a bridge to communicate with other services, provides additional network features for services, and is deployed independently of services, with zero intrusion into services, not to mention limited by the development language and technology stack of services, as shown in the following figure.

The communication agent based on Sidecar mode realizes the complete isolation between the basic implementation layer and the business logic, brings convenience in the deployment and upgrade, and achieves the complete decoupling of the real infrastructure layer and the business logic layer. On the other hand, Sidecar can provide more flexible extensions for application services more quickly, without the need for a large number of modifications of application services. Sidecar can implement the following main functions:

Service registration. Help the service to register with the appropriate service registry and do related health check-ups for the service.

Service routing. When the application service invokes other services, Sidecar can help to find the corresponding service address from the service discovery and complete the service routing function.

Service governance. Sidecar can completely intercept the traffic in and out of the service, and perform corresponding call chain tracking, circuit breaker, degradation, log monitoring and other operations, and centralize the service governance function in Sidecar.

Centralized control. All the services under the whole micro-service architecture can be centrally controlled through Sidecar to complete the flow control, offline and so on.

As a result, application services can finally develop across languages and focus more on the development of business logic.

1.2.4 Service Mesh

Fully apply the Sidecar pattern to a huge micro-service architecture system, deploy a Sidecar proxy for each application service, complete the complex communication between services, and finally get a network topology shown below, which is Service Mesh, also known as "service grid".

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

1.3What is Service Mesh

Before moving on to the topic, I think it is necessary to make a unified exposition of Service Mesh, which will help to understand it and make it easier to read the rest of the content.

1.3.1 introduction to Service Mesh

Service Mesh is translated as "service grid" and serves as the infrastructure layer for communication between services. Lightweight high-performance network agent that provides secure, fast and reliable communication between services, together with real-world application deployment, but transparent to applications. As the initiator of the service, the application only needs to send the request to the local service grid agent in the simplest way, and then the grid agent carries out subsequent operations, such as service discovery and load balancing, and finally forwards the request to the target service.

The purpose of Service Mesh is to solve the problem of communication and governance between services after the microservice of the system architecture. The service grid is composed of Sidecar nodes, and the essence of this pattern is to decouple the data plane (business logic) from the control plane. Specific to the micro-service architecture, that is, each micro-service instance is synchronously deployed a Sidecar.

In the Service Mesh deployment network structure diagram, the green square is the application service, the blue square is SideCar, and the application services communicate through Sidecar. The whole service communication forms the blue network connection in the diagram, and all the blue parts in the diagram form the Service Mesh. It has the following main characteristics:

The middle layer of communication between applications.

Lightweight network agent.

The application is not aware.

Decouple application retry / timeout, monitoring, tracking, and service discovery.

The emergence of Service Mesh solves the pain point in the traditional micro-service framework, makes developers focus on the business itself, and separates the service communication and related control functions from the business to the infrastructure layer.

1.3.2 functions of Service Mesh

So what exactly can Service Mesh do?

As the infrastructure layer responsible for network communication in the micro-service architecture, Service Mesh has most of the functions of network processing. Some of the main features are listed below:

Dynamic routing. The requested service can be dynamically routed through routing rules, which is convenient for dynamic routing adjustment in different environments, different versions, and so on.

Fault injection. By introducing faults to simulate the problems in network transmission (such as delay) to verify the robustness of the system, it is convenient to complete all kinds of fault testing of the system.

Fuse. Terminate potential correlation errors through service degradation.

It's clear. Implement security mechanisms (such as TLS) on Service Mesh, and it is easy to update security mechanisms at the infrastructure layer.

Multilingual support. As a stand-alone and business-transparent Sidecar agent, Service Mesh can easily support heterogeneous systems in multiple languages.

Multi-protocol support. Like multiple languages, multiple protocols are also supported.

Metrics and distributed link tracking.

To sum up, Service Mesh is mainly reflected in the following four aspects:

Visibility: runtime indicator telemetry, distributed tracking.

Manageability: service discovery, load balancing, runtime dynamic routing, etc.

Robustness: elasticity such as timeout, retry, fuse and so on.

Security: Inter-service access control, TLS encrypted communication.

1.3.3 what problem does Service Mesh solve

Judging from the introduction and functions of the above Service Mesh:

The infrastructure layer is the positioning of Service Mesh, which aims to solve the problems of standardization, configuration, service and production of micro-service infrastructure.

Inter-service communication is a problem faced by Service Mesh technology layer, which shields the complexity of micro-service communication and solves the problem of communication governance of micro-service.

Reliable delivery of requests is the goal of Service Mesh.

Lightweight network agents are the way Service Mesh is deployed.

Transparency to applications is the highlight and feature of Service Mesh, which is non-intrusive to the business.

To sum up, Service Mesh mainly addresses the pain point needs of users in the following three dimensions:

Perfect micro-service infrastructure

By sinking the micro-service communication to the infrastructure layer, the complexity of dealing with various communication problems of micro-service is shielded, and the abstract protocol layer between micro-services is formed. Developers do not need to care about the specific implementation of the communication layer, nor do they need to pay attention to all the details of RPC communications (including service discovery, load balancing, traffic scheduling, traffic degradation, monitoring and statistics, etc.). They really use micro-services like local calls, and the communication-related work is directly handed over to Service Mesh.

Language-independent communication and link governance

Functionally, Service Mesh does not provide any new features and capabilities, and all the communication and service governance capabilities provided by Service Mesh can be found in previous technologies of Service Mesh. For example, Spring Cloud implements perfect micro-service RPC communication and service governance support.

Service Mesh changes the way communication and service governance capabilities are provided. By decoupling these capabilities from the business implementation of various languages, sinking them to the infrastructure level, and providing them in a more general and standardized way, shielding the differences of different languages and platforms, it is conducive to the iteration and innovation of communication and service governance capabilities, and makes business implementation more convenient.

Service Mesh avoids the repeated construction of multilingual service governance and helps to improve the efficiency of multilingual technology stack through Service Mesh language-independent communication and service governance capabilities.

Standardization of communication and service governance

At the level of micro-service governance, Service Mesh is a standardized, systematic, non-intrusive distributed governance platform.

In terms of standardization, Sidecar has become the constraint standard for all micro-service traffic communication, and the data platform and control plane of Service Mesh also interact with each other through standard protocols.

In terms of systematization, considering the overall situation, it provides multi-dimensional micro-service observability (Metric, Trace, Logging), and provides systematic service governance capabilities, such as current limiting, circuit breaker, security, grayscale, etc.

Through standardization, it can bring consistent service governance experience, reduce the communication and conversion costs caused by inconsistent service governance standards among multi-businesses, and improve the efficiency of global service governance.

1.3.4 Service Mesh framework selection

The following is a summary of the comparison of the common Service Mesh frameworks on the market, as shown in the following table:

Any of the above Service Mesh frameworks can meet your basic needs. To the former, Istio has the most functionality and flexibility in the framework of these services. Flexibility means complexity, so the team needs to be more prepared. If you only want to make basic Service Mesh governance functions, Linkerd may be the best choice. If you want to maintain a heterogeneous environment that includes both Kubernetes and VM, and does not require the complexity of Istio, then Consul may be your best choice, and pre-Istio also provides support for heterogeneous environments that include both Kubernetes and VM.

From another point of view, the Istio community is rapidly iterating to deal with various scenarios, and strive to serve as a benchmark for Service Mesh. This paper chooses the Istio framework as the final migration framework.

1.4 Framework migration is imminent

In order to better occupy the market and meet the needs of more business scenarios, traditional micro-service architecture (for example, micro-service architecture based on Spring Cloud framework) faces many new challenges, and the emergence of Service Mesh just solves these problems. In the face of the new framework, how to deal with the traditional micro-service architecture?

It is urgent to migrate the micro-services of Spring Cloud framework to Service Mesh framework. Is it to be overturned and restarted, or to migrate sequentially? What if you migrate?

2. Service Mesh migration scheme

For enterprises or products that are not yet involved in Service Mesh, if their traditional micro-service architecture has been built using Spring Cloud framework, how to migrate to Service Mesh framework at this time? What factors need to be taken into account? Is there any evidence to support it?

Next, we will provide some suggestions and ideas for your reference on the construction of Spring Cloud-based migration to Service Mesh framework.

2.1 Migration scenario

For the traditional micro-service framework, we take the most typical Spring Cloud framework as an example to illustrate the migration. First of all, let's take a look at such a migration scenario. The current micro-service architecture looks like this, as shown on the left side of the figure below:

Applications are deployed on virtual machines or physical machines. (the service has not been containerized yet)

The framework is developed based on the Spring Cloud framework. (the business logic contained in the service is dependent on Spring Cloud components, and the business and framework coupling is too high.)

The development language is based on Java. (there are cross-language problems)

The registry uses Consul or Eureka. (the service needs to introduce registry dependency package, which is coupled to some extent)

At present, open source Istio has become the de facto standard of Service Mesh, but also the development trend of the new generation of micro services architecture, so the company hopes to try to migrate to the Istio framework, hoping to eventually form something similar to the right part of the following figure.

2.2 Migration path

Faced with the above migration scenarios, when you decide to introduce Service Mesh, it is necessary to thoroughly understand the specific path of Service Mesh migration.

First of all, make the following evaluation of your project:

Is it really necessary to introduce migration to Service Mesh?

Under the current micro-service architecture, do you face the challenges faced by the traditional micro-service architecture?

Has the current micro-service architecture hindered or affected the development of future business?

Does the company or technical team have the ability, manpower, and energy to invest in the migration of Service Mesh?

Secondly, complete the construction of Service Mesh micro-service platform. Whether containerization and Kubernetes are supported at the current stage. If the current business is already running on Kubernetes, the migration of Service Mesh will be very smooth; if the current business is not running on Kubernetes, because the current typical Istio framework of Service Mesh is over-dependent on Kubernetes, it may not be able to migrate directly from Spring Cloud to Istio framework, even if you customize and modify Istio to get in touch with the dependence on Kubernetes, it will pay a high price. There are usually two migration paths to choose from.

Path 1: connect to Sidecar first in non-Kubernetes environment

If the current service cannot be quickly containerized, and there is an urgent need to introduce Service Mesh, you can first connect to Sidecar to meet the pain point needs of the current business. When introducing Sidecar, we should pay attention to its future evolution direction, and consider that it may continue to migrate to Service Mesh. Once the time is ripe and Kubernetes containerization is introduced, it will be able to evolve directly from Sidecar to Service Mesh.

Service Mesh's current typical Istio framework is not well supported under non-Kubernetes (it is said that it will completely break away from the dependence on Kubernetes in the future). Customized modifications to Istio to support non-Kubernetes environment will pay a high price, not particularly strong demand and strong technical reserves, which is generally not recommended, especially for some small and medium-sized companies.

If Service Mesh must be introduced in a non-Kubernetes environment, the data plane can use Envoy, and the control plane can self-develop according to the XDS protocol.

Path 2: transform Kubernetes into containment first, then connect to Service Mesh

If the company has a cloud platform or containerized team, you can share the company's resources with the help of other teams to complete the Kubernetes containerization transformation, and then connect to Service Mesh.

Finally, based on the built Service Mesh framework, the business applications are gradually migrated to Service Mesh.

2.3 principles of migration

When implementing a migration, the following migration principles must be followed at all times.

Progressive migration: in order to avoid the risks in the process of Service Mesh migration, we must adopt the principle of gradual migration, migrate only a small number of services at a time, and wait long enough after the migration, and then continue the migration after there is no problem.

Business transparency: in order to reduce the impact of Service Mesh migration on the business and reduce the resistance to business migration, the initial stage of migration must ensure that the business is completely transparent and does not require too many changes and modifications.

In the scheme, in order to ensure the complete transparency of the migration to the business, the way of supporting transparent interception can be adopted in the data plane communication to transparently intercept the business request traffic.

Compatibility: in the migration phase, there must be two modes (Spring Cloud and Service Mesh framework) coexisting. In the process of migration, the compatibility of the two modes needs to be fully considered to make the network open before and after migration, at least to meet the communication between the unmigrated and migrated parts.

2.4 Migration scenario

Generally speaking, the migration from Spring Cloud to Service Mesh framework is divided into four steps: Spring Cloud architecture analysis, containerization transformation, Service Mesh micro-service platform construction and application migration.

2.4.1 Spring Cloud Architecture Analysis

The purpose of Spring Cloud architecture analysis is to re-understand all the functions under our current micro-service architecture, so as to prepare for the migration to Service Mesh and consider which functions need to be migrated, which do not need to be migrated, and which need to be modified. Let's first take a look at the fully built micro-service architecture solution based on Spring Cloud, as shown in the following figure.

From the analysis of the above picture, we can know that it is mainly composed of the following parts:

Proxy-gateway: provides unified external or internal access, including routing, authentication, current restriction, circuit breaker, degradation and other unified processing.

Registry: provides the registration and discovery function of services.

Application service: covers the whole business service, including business logic implementation, framework SDK and external component dependent interaction, etc.

Middleware-data storage: provides additional support for application services.

CI&CD: continuous integration, continuous deployment.

Which of these parts can be removed or done based on Service Mesh (for example, Istio)? After analysis, it is found that the components that can be replaced include gateways (Gateway or Zuul, replaced by Ingress gateway or egress), fuses (hystrix, replaced by Sidecar), registry (Eureka and Eureka client, replaced by Polit,Sidecar), equalization (Ribbon, replaced by Sidecar) and so on.

At this stage, we have a rough idea of what can be handled by Istio in Spring Cloud and what can continue to be used.

2.4.2 containerization transformation

Containerization transformation is mainly aimed at the scenarios where Kubernetes containerization has not been introduced yet.

Before the containerization transformation, we need to know the advantages and requirements of the transformation.

Advantages of containerization transformation:

More saving: great resource utilization efficiency, maximize extraction and sharing of physical resources, multi-projects can better reflect the multi-advantages of containerization, and save the cost of deploying IT.

Faster: start in seconds to achieve faster development iteration and delivery deployment of business systems.

Elasticity: the elastic container can be expanded and expanded according to the business load.

Convenience: container-based business deployment supports blue-green / grayscale / canary and other releases, rollback, more flexible and convenient.

Flexibility: monitor the health status of the underlying node nodes and flexibly schedule to the optimal node deployment.

Strong consistency: the container packages the environment and code in a mirror, ensuring strong consistency between the test and production environments.

Containerization transformation requirements:

Master Docker technology: developers should be familiar with Docker containerization technology and be proficient in writing Dockerfile documents.

Master Kubernetes orchestration system: familiar with Kubernetes containerization orchestration system, familiar with the compilation of component resource list, high availability, RBAC security strategy, etc.

Containerization transformation is mainly divided into the following two stages:

Containerized construction: implement containerized construction of all services built based on Spring Cloud to achieve Docker image packaging.

Containerization management: management of service containers based on Kubernetes.

2.4.2.1 containerized construction

Containerization construction needs the help of the written Dockerfile file, and through Jenkins automation to complete the production of the Docker image. Here is an example of a simple serviceProvider service (developed based on the Spring Cloud framework) to illustrate the construction process:

(1) create Dockerfile file.

Create a Dockerfile file under the service serviceProvider/src/main/docker directory, as follows:

FROM java:8RUN mkdir / microserviceWORKDIR / microserviceADD / service-provider-1.0.jar / microservice/EXPOSE 8001ENTRYPOINT ["java", "- Djava.security.egd=file:/dev/./urandom", "- jar", "/ microservice/service-provider-1.0.jar"]

(2) configure pom docker-maven-plugin plug-in.

Configure the build section in the pom.xml of the service serviceProvider, as follows:

Install service-provider-$ {project.version} org.springframework.boot spring-boot-maven-plugin com.spotify docker-maven-plugin 0.4.13 install Build tag http://dockerip:2375 ${project.build.finalName} java ["java" "- Djava.security.egd=file:/dev/./urandom", "- jar" "/ ${project.build.finalName} .jar"] / ${project.build.directory} ${project.build.finalName} .jar ${docker.image.prefix} / ${project.build.finalName} ${docker.image.prefix} / ${project.build.finalName}: ${docker.tag} true false

(3) packing.

When mvn package is executed, the Docker image is automatically packaged and pushed to the Docker server according to the build configuration in pom.xml.

At this point, the containerization construction has been successfully completed, and this step basically has no impact on the original service. After successful packaging, you only need to carry out verification testing to ensure that there are problems with the image packaging.

2.4.2.2 containerization management

Containerization management is actually the service container through the Kubernetes orchestration system to complete the service deployment, management, etc., you need to have some understanding of Kubernetes, will be proficient in using it, see the previous written "Kubernetes from beginner to proficient" series of articles.

2.4.3 Construction of Service Mesh micro-service platform

Service Mesh We choose the Istio framework, about the selection scheme can refer to the previous article: comparative analysis of Service Mesh framework selection: Linkerd, Envoy, Istio, Conduit.

2.4.3.1 Construction of istio infrastructure

Build the Istio infrastructure framework based on the Istio framework, and provide the following capabilities in the control plane and data platform, respectively:

Control plane: provides functions such as service grid control instruction issuance, service configuration, authority control and so on.

Data platform: provide service governance, service monitoring and maintenance, traffic control and other functions.

The above functions can be found in the Istio framework and can be completed through the appropriate resource list configuration.

The Istio architecture diagram is as follows:

At this point, an Istio infrastructure has been built and can provide all the capabilities of Service Mesh.

2.4.3.2 istio extension and customization

As mentioned in the migration path, for non-Kubernetes environments, it is recommended to introduce Sidecar first and adopt the istio support scheme for virtual machines to run in the virtual machine environment. However, if there are scenarios supported by multiple platforms, such as both Kubernetes environment and virtual machine environment, istio needs to be customized to remove the strong dependence and coupling on Kubernetes and increase support for other platforms. (currently, istio does not support multi-platform support, but it can be seen from the official istio documentation that multi-platform support will eventually be supported. We just need to wait and see. )

The coupling of Istio to Kubernetes mainly has the following aspects, so targeted adaptation modification is needed.

(1) dependence of API resource management on Kubernetes API Server

Resource management is where Istio relies most on Kubernetes. Istio manages core resources on the basis of Kubernetes CRD and uses kubectl as the command line operator. Kubectl calls API Server to store resources in etcd, and triggers resource change event notification through Kubernetes CRD mechanism, notifying modules concerned about Istio resource change events for related processing.

If you want to unbind Istio from Kubernetes, you need to implement this set of API management methods on your own, and be platform-independent.

(2) the dependence of communication access layer on kube DNS

In the communication layer, before the client sends the request, the virtual IP address of the service is obtained through DNS. The DNS implementation of Istio follows the Kubernetes DNS scheme, and the direct access is realized through the service name based on DNS. Therefore, you need to get in touch with the coupling with Kubernetes at the DNS solution level and use a platform-independent DNS solution.

2.4.3.3 coexistence of the two frameworks

For large businesses, it is impossible to migrate at once, and you need to abide by the principle of "progressive migration" and migrate step by step, so you may face such demands in the actual migration process:

Some old stock businesses run on virtual machines or physical machines, and there are no plans for containerization for the time being, but they hope to do service governance through Service Mesh.

New business or stock of non-critical business can be used as a pilot, first container, Service Mesh, other services still use the original mode of operation and micro-service framework.

For unmigrated stock applications and migrated Service Mesh applications, business interoperability can still be maintained.

In the face of these real and reasonable demands, when building a Service Mesh micro-service platform, there will inevitably be two scenarios in which two frameworks coexist. As shown in the following figure, there are unmigrated inventory services on the left and containerized and Service Mesh pilot services on the right, but these services are different from each other and cannot be managed uniformly.

So when the two frameworks coexist, how to communicate with each other and govern uniformly?

There is a popular saying in the industry: any problem in the field of computer science can be solved by adding an indirect middle layer.

Similarly, we can do some articles on the control plane of Service Mesh. Through the custom control plug-in (WASM), we incorporate the functions of the original registry in the Spring Cloud framework, and the control plane provides the original service registration and discovery capabilities, and combines the Ingress and ServiceEntry resource configuration of the ingress gateways in Istio to achieve interoperability between services and unified governance. The entire implementation logic architecture is shown in the following figure.

So far, the coexistence of two frameworks based on Spring Cloud and Istio has been realized.

2.4.4 Application Migration

Now that we have completed the construction of the Service Mesh micro-service platform, how can we gradually migrate Spring Cloud applications to Service Mesh on such a platform?

2.4.4.1 removal of overlap function

Let's first look at the functional overlap between the Spring Cloud framework and the Istio framework:

From the function of the above table, there are a large number of overlapping functions, so the overlapping functions in Spring Cloud and Istio need to be removed, and the missing functions are retained, which can be easily removed in theory. For Spring Cloud, most of these overlapping functions can be easily accomplished by removing dependency packages, related configurations and code annotations in pom.xml, leaving a relatively clean application.

2.4.4.2 Application injection

Application injection refers to the injection of Sidecar into the application service to implement the grid proxy when the application service is deployed to the grid.

Sidecar injection is divided into manual injection and automatic injection:

Manual injection: the CRD yaml of the application is reconstructed by manually executing istioctl kube-inject.

Automatic injection: restructure the application's CRD yaml through Kubernetes's mutable webhook callback to the istio-sidecar-injector service.

As shown in the following figure:

Whether manual injection or automatic injection, the essence of Sidecar injection is to populate the image address, startup parameters, connected Istio clusters (Pilot, Citadel, Galley) and configuration information needed to run Sidecar into the injection template, and add them to the application's CRD yaml, and finally persist the resources through Kubernetes and pull up the POD of the application and Sidecar.

At this point, the application has been successfully migrated and deployed to Service Mesh.

3. Summary

This article introduces the traditional micro-service architecture to Service Mesh step by step, and puts forward the challenges faced by the traditional micro-service architecture. In view of the current situation, how to better meet the market demand without being eliminated by the market, this paper introduces the process of the smooth migration of traditional micro-services to Service Mesh, and gives some solutions, steps and ideas for your reference.

I hope it can help you solve the problems encountered in the actual migration process, and help you bring some thinking and inspiration when doing architecture evolution or migration.

Thank you for your reading, the above is the content of "how Spring Cloud migrates to Service Mesh framework". After the study of this article, I believe you have a deeper understanding of how Spring Cloud migrates to Service Mesh framework, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.