This article is participating in “Java Theme Month – Java Development in Action”, see the activity link for details

As a new generation of microservice architecture system, Service Mesh technology effectively solves the pain points in the process of Spring Cloud microservice architecture and Service governance, and has aroused great response since its launch. In the past year or so, Service Mesh has been on the crest of a wave of cloud-native activity. It has gone from stranger to stranger, and some startups are trying to make money from it. For startups or brand new products, Service Mesh becomes a much easier choice because there is no migration issue. However, for most enterprises or mature product systems, such a large architectural transformation would be difficult to implement, requiring a lot of trade-offs, and forcing Service Mesh to embrace its benefits.

At present, many enterprises still use traditional sdK-BASED microservice frameworks (such as Dubbo and Spring Cloud) for Service governance. With the popularity of Service Mesh, more and more enterprises begin to lay out their own Service Mesh framework system. However, most companies do not start out aggressively migrating all their services to Serivice Mesh, because it is too risky and too slow. For example, Java technology stack applications still retain the original framework, while non-Java technology stack applications use the Service Mesh framework. Different development languages can use different technical frameworks, but services cannot be separated by the framework. Then how do application services interconnect under the two architecture systems? How to unify the management of micro services? How do traditional microservices migrate smoothly to the Service Mesh?

How to solve these problems? Today we will discuss many problems in the process of constructing Spring Cloud-based migration to Service Mesh framework, and try our best to provide a set of perfect solutions and migration ideas for your reference.

1, the background

Microservice is a hot term in software architecture in recent years, and it is also a big concept. Different people have different understandings of it. Even in the early microservice architecture, a batch of different microservice architecture products appeared. It’s just a Web container for the service.

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 instances, 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.1 Challenges faced by traditional microservices architectures

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 in the language that best suits them, but inSpring CloudUnder the framework is the world of Java, multi-language support is very difficult. This leads to the helplessness of heterogeneous system docking, or 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, and we all know that technological evolution comes from the practice of constant exploration, abstraction, decoupling, encapsulation, and servitization of functions. As these problems are exposed in traditional microservices architectures, new challenges will emerge, leaving everyone looking for alternative solutions.

1.2 Usher in a new generation of microservices 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.2.1 Coupling stage

In microservice architecture, service discovery, circuit breaker, governance and other capabilities are important components of microservice architecture. After microservitization, services become more decentralized and more complex. At the beginning, developers encapsulate functions such as circuit breaker and timeout together with business codes to enable services to have network control capability, 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.2 Common library SDK

Based on the above problems, it is easy to think of infrastructure functions would be regarded as a public library SDK, let the business logic of the service and the decoupling function, improve the utilization rate of repeat more importantly developers only need to pay attention to the dependence and use of public library SDK, rather than having to focus on function of the public to focus more on the development of the business logic, The Spring Cloud framework, for example, is similar. As shown below:

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

• These common library SDKS have 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 library SDKS are generally implemented in a specific language, lack of multi-language support, and have certain limitations when integrating existing systems.
• The management and maintenance of the common library SDK still requires a lot of effort from developers and requires specialized personnel to manage and maintain it.

1.2.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 zero intrusion into the service, and is not limited to 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. The 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 below is obtained, which is called 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.

1.3 What is Service Mesh

Before I dive into the topic, I thought it was important to give a general overview of the Service Mesh to help understand it and make it easier to read.

1.3.1 Service Mesh

Service Mesh translates as “Service grid” and acts as an infrastructure layer for communication between services. Lightweight, high-performance network agent that provides secure, fast, and reliable interservice communication, in conjunction with actual application deployments, but transparent to applications. As the initiator of the service, the application only needs to send the request in the simplest way to the local service grid agent, which then performs subsequent operations such as service discovery, load balancing, and finally forwards the request to the target service.

The purpose of Service Mesh is to solve the communication and governance problems between services after the system architecture is microservified. The service grid consists of Sidecar nodes. The essence of this pattern is to decouple the data side (business logic) from the control side. In the microservice architecture, a Sidecar is deployed synchronously for each microservice instance.

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

• An intermediate layer of communication between applications.
• Lightweight network proxy.
• The application is not aware.
• Decouple application retry/timeout, monitoring, tracing, and service discovery.

The emergence of Service Mesh solves the pain points in traditional microservices frameworks, allowing developers to focus on the business itself and at the same time, separating Service communication and related management functions from the business to the infrastructure layer.

1.3.2 Functions of Service Mesh

So what does a Service Mesh do?

As the infrastructure layer responsible for network communication in microservice architecture, Service Mesh has most functions of network processing. Here are some of the main features:

• Dynamic routing. You can dynamically route to the requested service based on routing rules, facilitating dynamic route adjustment in different environments and versions.
• 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 various fault tests of the system.
• Fusing. Service degradation is used to terminate potential association errors.
• Security. 在Service MeshTo implement security mechanisms (e.gTLS), and it is easy to do security updates at the infrastructure layer.
• Multilingual support.Run as stand-alone and transparent to the businessSidecarThe agent,Service MeshEasily support heterogeneous systems in multiple languages.
• Multi-protocol support. Like multilanguage, multiprotocol is supported.
• Metrics and distributed link tracking.

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

• Visibility: Runtime metrics telemetry, distributed tracking.
• Manageability: service discovery, load balancing, dynamic routing at run time, etc.
• Robustness: Elastic capabilities such as timeout, retry, and fusing.
• Security:Inter-service access control,TLSEncrypt communication.

1.3.3 What problem does Service Mesh Solve

From the introduction and functions of the Service Mesh above:

• The infrastructure layer is the orientation of Service Mesh and addresses the standardization, configuration, servitization, and productization of microservice infrastructure.
• The communication between services is a technical pair problem of Service Mesh, which shields the complexity of micro-service communication and solves the communication governance problem of micro-service.
• The reliable delivery of the request isService MeshThe goal of.
• The lightweight web proxy isService MeshThe deployment mode of.
• Transparency to the application isService MeshThe bright spot and the characteristic, realizes to the business does not invade.

In summary, Service Mesh mainly solves users’ pain point needs from the following three dimensions:

• Perfect microservice infrastructure

  By sinking the microservices communication to the infrastructure layer, the complexity of microservices dealing with various communication problems is shielded, and the abstract protocol layer between microservices is formed. Developers do not need to care about the implementation of the communication layer or all the details of RPC communication (including Service discovery, load balancing, traffic scheduling, traffic degradation, monitoring statistics, etc.). Microservices are truly used as local calls, and the communication related work together is directly left to the Service Mesh.

• Language-independent communication and link governance

  In terms of function, Service Mesh does not provide any new features and capabilities. All the communication and Service governance capabilities provided by Service Mesh can be found in the technologies before Service Mesh. For example, Spring Cloud has implemented complete support for microservice RPC communication and Service governance.

  Service Mesh change is communication and Service management ability to provide way, by the ability to realize decoupling from the business implementation language, sinking to the level of infrastructure, in a more general and standardized way, shielding the differences of different languages, different platforms, facilitates communication and Service governance ability of iteration and innovation, It makes business implementation more convenient.

  Service Mesh avoids duplication in multi-language Service governance and helps improve the efficiency of multi-language technology stacks through language-independent communication and Service governance capabilities of Service Mesh.

• Standardization of communication and service governance

  • Micro service governance.Service MeshIt is a standardized, systematic, non-invasive distributed governance platform.
  • Standardization aspect.SidecarBecome the constraint standard for all microservice traffic communications, whileService MeshThe data platform and control plane also interact through standard protocols.
  • Systematization, from a global perspective, to provide multi-dimensional observable capability of microservices (Metric,Trace,Logging), and provide systematic service governance capabilities, such as current limiting, fusing, security, gray scale, etc.

  Standardization provides consistent service governance experience, reduces communication and conversion costs caused by inconsistent service governance standards among multiple services, and improves the efficiency of global service governance.

1.3.4 Selection of Service Mesh framework

The following table compares the common Service Mesh frameworks in the market:

function	Linkerd 2	Envoy	Istio	Conduit
The agent	Finagle + Jetty	Envoy	Envoy	Conduit
fusing	Support. Connection based fusesFast FailAnd request-based fusesFailure Accrual.	Support. By setting specific criteria, such as maximum number of connections, maximum number of requests, maximum number of pending requests, or maximum number of retries.	Support. By setting specific criteria such as maximum number of connections and maximum number of requests.	Not supported yet.
Dynamic routing	Support. By setting theLinkerdthedtabRules implement dynamic routing of different versions of service requests.	Support. This is done by the version or environment information of the service.	Support. This is done by the version or environment information of the service.	Not supported yet.
Traffic diversion	Support. Triage is implemented in an incremental and controlled manner.	Support. Triage is implemented in an incremental and controlled manner.	Support. Triage is implemented in an incremental and controlled manner.	Not supported yet.
Service discovery	Support. Supports multiple service discovery mechanisms, such as file-based service discovery,Consul,Zookeeper,KubernetesAnd so on.	Support. Integrate with different service discovery tools by providing platform-independent service discovery interfaces.	Support. Integrate with different service discovery tools by providing platform-independent service discovery interfaces.	Only supportKubernetes.
Load balancing	Support. Provides multiple load balancing algorithms.	Support. Provides multiple load balancing algorithms, such asRound Robin, weighted minimum request, hash ring,MaglevAnd so on.	Support. Provides multiple load balancing algorithms, such asRound Robin, weighted minimum request, hash ring,MaglevAnd so on.	Support. Currently only HTTP requests are supported basedP2C + least-loadedLoad balancing algorithm based on.
Secure communication	supportTLS.	supportTLS.	supportTLS.	supportTLS.
Access control	Is not supported.	Is not supported.	Support. Based on theRBACAccess control.	Not supported yet.
visibility	Distributed tracking (Zipkin), runtime indicators (InfluxDB,Prometheus,statsd)	Distributed tracking (Zipkin), runtime indicators (statsd)	Distributed tracking (Zipkin), runtime indicators (Prometheus,statsd), monitoring (NewRepic,Stackdriver)	Runtime metrics (Prometheus)
Deployment patterns	sidecarorper-hostmodel	sidecarmodel	sidecarmodel	sidecarmodel
Control plane	Namerd	No, but it can be done through the API.	Pilot,Mixer,Citadel	Conduit
Protocol support	HTTP/1.x,HTTP/2,gRPC	HTTP/1.x,HTTP/2,gRPC,TCP	HTTP/1.x,HTTP/2,gRPC,TCP	HTTP/1.x,HTTP/2,gRPC,TCP
Operation platform	Platform independent	Platform independent	Currently supportedKubernetesPlatform independence is the ultimate goal.	Only supportKubernetes.

Any of the above Service Mesh frameworks should meet your basic needs. Istio has by far the most functionality and flexibility of any of these service grid frameworks, and flexibility means complexity, and therefore requires more team preparation. If you just want to use basic Service Mesh governance, Linkerd is probably the best choice. Conduit may be your best choice if you want to support a heterogeneous environment with both Kubernetes and VM and do not need the complexity of Istio, which currently also offers support for a heterogeneous environment with both Kubernetes and VM.

On the other hand, the Istio community is rapidly iterating in response to various scenarios and striving to serve as a benchmark for The Service Mesh. In this paper, the Istio framework is selected as the final migration framework.

1.4 Framework migration is imminent

In order to better capture the market and meet the needs of more business scenarios, traditional microservice architectures (such as those based on the Spring Cloud framework) face 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 microservices architecture?

For Spring Cloud framework, the migration of microservices to Service Mesh framework is imminent. Should we start from scratch or migrate step by step? And if so, what?

2. Service Mesh migration scheme

How to migrate to the Service Mesh framework for an enterprise or product that has not yet entered the Service Mesh framework and whose traditional microservice architecture has been built using the Spring Cloud framework? What factors should be considered? Is there any basis for it?

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

2.1 Migration Scenario

Traditional microservice framework, we take the most typical Spring Cloud framework as an example to explain the migration. First, let’s take a look at a migration scenario where the current microservices architecture looks like this, on the left side of the figure below:

• An application is deployed on a VM or physical server. (The service is not containerized yet)
• The framework is based onSpring CloudFramework development. The business logic contained in the service andSpring CloudComponent dependencies, business and framework coupling is too high)
• The development language is Java. (There are cross-language issues)
• The registry usesConsul 或 Eureka. (Services need to introduce registry dependencies, there is some coupling)

Open source Istio has become the de facto standard for Service Mesh and the trend for the next generation of microservice architectures. Therefore, the company wants to try to migrate to Istio framework with the hope that the end result will be something like the one on the right.

2.2 Migration Path

When deciding to introduce a Service Mesh in the above migration scenario, it is necessary to thoroughly understand the specific migration path of the Service Mesh.

First, evaluate your project as follows:

• Whether it is really necessary to introduce migration toService MeshOn the?
• Under the current microservice architecture, are there any challenges that traditional microservice architecture faces?
• Is the current microservices architecture hindering or impacting future business development?
• Whether the company or technical team has the ability, manpower and energy to investService MeshThe migration?

Secondly, the establishment of Service Mesh micro-service platform is completed. Whether the current phase already supports containerization and Kubernetes. If the current Service is running on Kubernetes, the migration of the Service Mesh will be smooth. If the current Service is not running on Kubernetes, the typical Istio framework of Service Mesh may not be able to migrate directly from Spring Cloud to Istio framework because of excessive dependence on Kubernetes. Even customizing Istio to get in touch with Kubernetes dependencies would be costly. There are usually two migration paths to choose from.

Path 1: NoKubernetesIn the environment, connect to fusionmanager firstSidecar

If the current Service cannot be quickly containerized and the Service Mesh needs to be introduced, you can connect Sidecar first to meet the pain points of the current Service. When introducing Sidecar, we should pay attention to its future evolution direction and consider that it may continue to migrate to Service Mesh in the future. Once the time is ripe and Kubernetes container is introduced, it can smoothly evolve from Sidecar to Service Mesh directly.

Service Mesh’s current typical Istio framework is not well supported in non-Kubernetes (it is said that the future will be completely independent of Kubernetes), and customizing Istio to support non-Kubernetes environments would be costly. Not particularly strong demand and strong technical reserves, generally not recommended to do so, especially for some small and medium-sized companies.

If you must introduce a Service Mesh in a non-Kubernetes environment, the data plane can be Envoy and the control plane can be customized according to the XDS protocol.

Path 2: Proceed firstKubernetesContainer transformation, re-accessService Mesh

If the company has a cloud platform or container team, it can use the company’s resource sharing method to complete the Kubernetes container transformation with other teams first, and then access the Service Mesh.

** Finally, ** gradually migrates business applications to Service Mesh based on the constructed Service Mesh framework.

2.3 Migration Rules

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

• Progressive migration: To avoid risks during the migration of Service Mesh, the principle of progressive migration must be adopted. Only a small number of services must be migrated each time. After the migration, observe the migration for a long time and continue the migration until there is no problem.

• Service transparency: To reduce the impact of Service Mesh migration on services and reduce migration resistance, ensure that services are completely transparent and do not need too many changes or modifications at the initial stage of migration.

  To ensure that the migration is transparent to services, transparent interception can be adopted in data plane communication to transparently intercept service request traffic.

• Compatibility: In the migration phase, two modes (Spring Cloud and Service Mesh framework) will inevitably coexist. In the migration process, the compatibility of the two modes should be fully considered to make the network open before and after the migration, and at least ensure that the unmigrated and migrated parts can communicate.

2.4 Migration Scheme

The migration from Spring Cloud to Service Mesh framework is generally divided into four steps: Spring Cloud architecture analysis, container transformation, Service Mesh micro-service platform construction and application migration.

2.4.1 Analysis of Spring Cloud architecture

The purpose of the Spring Cloud architecture analysis is to re-understand all of the functionality under our current microservices architecture so that we can prepare for the migration to the Service Mesh, consider which functionality needs to be migrated, which features do not need to be migrated, and which features need to be modified. Let’s take a look at a fully built microservices architecture solution based on Spring Cloud, as shown in the figure below.

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

• Proxy and gateway: provides unified external and internal access, including unified processing such as routing, authentication, traffic limiting, fusing, and degradation.
• Registry: Provides registration and discovery of services.
• Application service: covers the entire business service, including business logic implementation, framework SDK, external component dependency interaction, etc.
• Middleware & Data Storage: Provides additional support for application services.
• CI&CD: Continuous integration, continuous deployment.

Which of these parts can we remove or do based on Service Mesh (in the case of Istio)? Components that can be replaced include the Gateway (Gateway or Zuul, replaced by Ingress Gateway or egress), fuse (Hystrix, replaced by Sidecar), and Registries (Eureka and Eureka Client, replaced by Polit and Sidecar), responsible for balancing (Ribbon, replaced by Sidecar), etc.

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

2.4.2 Container transformation

Container transformation, mainly for the current has not introduced Kubernetes container scene.

Before container transformation, it is necessary to know the advantages and requirements of transformation.

Advantages of container transformation:

• More economical: great resource utilization efficiency, maximizing the extraction and sharing of physical resources, multiple projects can better reflect the advantages of containerization, saving deployment IT costs.
• Faster: Second start to achieve faster development iterations and delivery deployment of business systems.
• Elastic: The container can be flexibly expanded based on the service load.
• Convenience: Containerized service deployment supports publishing and rolling back blue-green/grayscale/Canary, which is more flexible and convenient.
• Flexible: Monitors the health status of underlying nodes and flexibly schedules nodes to the optimal deployment.
• Consistency: The container packages the environment and code in an image, ensuring consistency between the test and production environments.

Requirements for container transformation:

• Master Docker technology: Developers need to be familiar with Docker containerization technology and skilled in writing Dockerfile files.

• Master Kubernetes arrangement system: familiar with Kubernetes containerized arrangement system, familiar with component resource list compilation, high availability, RBAC security policy, etc.

Containerization transformation is mainly divided into the following two stages:

• Containerized build:Will be based onSpring CloudAll services built to achieve container build, implementationDockerImage packaging.
• Containerized management:Based on theKubernetesManage service containers.

2.4.2.1 Containerized Build

Containerization construction needs the help of Dockerfile file written, and the production of Docker image is completed automatically by Jenkins. This section uses a simple serviceProvider service (developed based on the Spring Cloud framework) as an example to illustrate the construction process.

Create a Dockerfile file.

In service serviceProvider/SRC/main/docker directory to create a Dockerfile file, the content is as follows:

FROM java:8
RUN mkdir /microservice
WORKDIR /microservice
ADD/ service provider - 1.0. Jar/microservice /
EXPOSE 8001
ENTRYPOINT ["java"."-Djava.security.egd=file:/dev/./urandom"."-jar"."/ microservice/service provider - 1.0. The jar." "]
Copy the code

(2) Configure the POM docker-maven-plugin.

In the Pom. XML of the serviceProvider service, configure the build section as follows:

<! --> <build> <defaultGoal> Install </defaultGoal> <! The default value is ${artifactId}-${version}. --> <finalName>service-provider-${project.version}</finalName> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <! Install maven: install maven: GroupId > </groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.4.13</version> <execution> <phase>install</phase> < Goals > <goal>build</goal> <goal>tag</goal> </goals> </execution> </executions> <configuration> <! To change the DOCker node IP address, open remote management port 2375 of the Docker node. -> <dockerHost>http://dockerip:2375</dockerHost> <imageName>${project.build.finalName}</imageName> <baseImage>java</baseImage> <! -djava.security. egd -- this configuration is used when Tomcat8 is started. <entryPoint> [" Java ", "-djava.security. egd=file:/dev/./urandom", "-jar", "/${project.build.finalName}.jar"] </entryPoint> <resources> <resource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>${project.build.finalName}.jar</include> </resource> </resources> <image>${docker.image.prefix}/${project.build.finalName}</image> <newName>${docker.image.prefix}/${project.build.finalName}:${docker.tag}</newName> <forceTags>true</forceTags> <! PushImage = false</pushImage> </configuration> </plugin> </plugins> </build>Copy the code

(3) Pack.

When MVN package is executed, the Docker image will be automatically packaged according to the build configuration in POM. XML and pushed to the Docker server.

At this point, the containerization build is successfully completed, and this step has little impact on the original service. Once the packaging is successful, you only need to conduct verification tests to ensure that there are problems with the image packaging.

2.4.2.2 Container-based management

Container management is actually the service container through Kubernetes arrangement system, to complete the service deployment, management, etc., need to have a certain understanding of Kubernetes, will be skilled in using it, see reference before writing “Kubernetes from the entry to master” series of articles.

2.4.3 Service Mesh Microservice platform construction

We select THE Istio framework for Service Mesh. Please refer to the previous article: Linkerd, Envoy, Istio, Conduit for the selection of Service Mesh framework.

2.4.3.1 Setting up an ISTIO infrastructure

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

• Control plane: provides service grid control instruction delivery, service configuration, permission control and other functions.
• Data platform: provides service governance, service monitoring, operation and maintenance, traffic control and other functions.

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

Istio architecture diagram is as follows:

At this point, an Istio infrastructure has been built that provides 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, adopt isTIO solutions for VIRTUAL machines, and run in virtual machine environments. However, if there is a multi-platform supported scenario, 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 the support for other platforms. (Multi-platform support is not currently supported by IStio, but isTIO documentation indicates that it will eventually be supported, so we’ll just have to wait and see.)

The coupling of Istio to Kubernetes mainly has the following aspects, so it needs specific adaptation modification.

(1) The dependency of API resource management layer on Kubernetes API Server

Resource management is where Istio relies most heavily on Kubernetes. Istio manages core resources based on Kubernetes CRD and uses Kubectl as a command line entry. Kubectl calls API Server and stores resources in ETCD. The resource change event notification is triggered by the Kubernetes CRD mechanism, and the module concerned about Istio resource change events is notified to process them.

If you want to unbind Istio to Kubernetes, you need to implement this SET of API management methods, and do it platform-independent.

(2) The dependence of communication access level on KUbe DNS

At the communication level, before the client sends a request, it obtains the virtual IP address of the service through DNS. Istio’s DNS implementation follows the Kubernetes DNS solution and implements direct access through the service name based on DNS. Therefore, the coupling with Kubernetes needs to be exposed at the DNS solution level and a platform-independent DNS solution is used.

2.4.3.3 Coexistence of the two frameworks

For businesses with a large volume, it is impossible to migrate them all at once. Instead, they need to follow the principle of “progressive migration” and migrate gradually. Therefore, in the actual migration process, they may face the following demands:

• Some existing services run on virtual machines or physical machines. There is no container transformation plan for the time being, but we hope to use Service Mesh to implement Service governance.

• New businesses or existing non-critical businesses can be used as a pilot. Container and Service Mesh should be implemented first, while other businesses still adopt the original operation mode and micro-service framework.

• The storage applications that have not been migrated and the Service Mesh applications that have been migrated can still maintain Service communication.

In the face of these real and reasonable demands, it is inevitable that two kinds of frameworks coexist in the construction of Service Mesh micro-service platform. As shown in the figure below, the left side is the stock Service that has not been migrated, and the right side is the pilot Service that has been containerized and integrated with Service Mesh. However, services in this mode are different from each other. And can not be unified governance.

So when the two frameworks coexist, how to interconnect services and unify governance?

It is a popular saying in the industry that any problem in computer science can be solved by adding an indirect middle layer.

Also, we can write about the control plane of the Service Mesh. We can use the Custom control plug-in (WASM) to incorporate the functions of the existing registry in the Spring Cloud framework. The control plane provides the existing Service registration and discovery capabilities. In addition, the Ingress and ServiceEntry resources in Istio are configured to realize service communication and unified management. The logical 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 built the Service Mesh micro-service platform, how can we gradually migrate Spring Cloud applications to Service Mesh on this platform?

2.4.4.1 Removing overlap function

Let’s take a look at the overlap between the Spring Cloud framework and Istio framework:

Feature list	Spring Cloud	Isito
Service registration and discovery	Supported, based on Eureka, Consul and other components.	Support, based onXDSInterface to obtain service information, and rely on the “virtual service routing table” service discovery, flexible expansion of any registry.
Link to monitor	Support, based onZikpin 、 PinpointorSkywalkingThe implementation.	Support, based onSidecarProxy model, which records network request information.
The service gateway	Support, based onzuulorSpring-Cloud-gatewayThe implementation.	Support, based onIngress gatewayAs well asegressThe implementation.
fuse	Support, based onHystrixThe implementation.	Support, based on the declaration of the configuration file, finally converted to the implementation of routing rules.
Service routing	Supports routing and forwarding based on the gateway layer.	Supported. Implemented based on iptables rulesVirtualService 和DestinationRuleFlexible configuration.
The security policy	Support, based onspring-securityComponent implementation, including authentication, authentication, support communication encryption.	Support, based onRBACPermissions model, dependencyKubernetesImplementation, at the same time support communication encryption.
Configuration center	Support,Spring Cloud ConfigComponent implementation.	Is not supported.
Performance monitoring	Support, based onSpring cloudProvided monitoring components collect data and connect to third-party monitoring data stores.	Support, based onSidecarProxy to record service invocation performance data and import third-party data monitoring tools through the Metrics Adapter.
Log collection	For example, connect to a third-party log systemELK.	Support, based onSidecarProxy, log information, and passlog adapterTo import a third-party log system.

According to the functions in the above table, there are a lot of overlapping functions, so overlapping functions in Spring Cloud and Istio should be removed and missing functions should be retained, which can be easily removed in theory. For Spring Cloud, most of these overlaps can be easily done by removing the dependency packages, associated configuration, and annotations in the code from PEM.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 realize the proxy of the grid when the application service is deployed to the grid.

Sidecar injection, including manual injection and automatic injection:

• Manual injection: The applied CRD YAML is reconstructed by manually executing istioctl kube-inject.

• Auto-injection: Webhook callback istio-Sidecar-Injector service to retool the CRD YAML of the application via Kubernetes mutable webhook.

As shown below:

Whether manual or automatic, the essence of Sidecar injection is to fill the injection template with the image address, startup parameters, connected Istio clusters (Pilot, Citadel, Galley), and configuration information needed to run Sidecar. Add it to the CRD YAML of the application, and finally persist the resource through Kubernetes and pull up the POD of the application and Sidecar.

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

3, summarize

This paper introduces the Service Mesh step by step from the traditional microservice architecture, and puts forward the challenges faced by the traditional microservice architecture. In view of the current situation, how to better meet the market demand without being eliminated by the market, and introduces the process of how to smoothly migrate the traditional microservice to the Service Mesh. Some solutions, steps and ideas are given for your reference.

Hope to help you solve the problems encountered in the actual migration process, can help you to do architecture evolution or migration to bring some thinking and inspiration.

References:

1. Istio. IO/latest/docs…
2. Service Mesh Microservice Architecture Design by Junhai Liu
3. Mp.weixin.qq.com/s/y9PZLgHhV…
4. www.servicemesher.com/blog/servic…
5. Mp.weixin.qq.com/s/-MszFJORu…
6. www.servicemesher.com/blog/neteas…