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

Based on Spring Boot development, Spring Cloud provides a complete set of micro-service solutions, including service registration and discovery, configuration center, full-link monitoring, API gateway, fuse, remote invocation framework, tool client and other options-neutral open source components, and some components can be extended and replaced according to requirements.

Service Mesh, here to Istio (currently a specific implementation of Service Mesh, and the highest voice) as an example to briefly illustrate its function. Istio helps reduce the complexity of these deployments and reduce the pressure on the development team. It is a completely open source service grid that can be transparently layered into existing distributed applications. It is also a platform, including API that allows it to be integrated into any logging platform, telemetry, or policy system. Istio's diverse feature set enables you to run the distributed microservice architecture successfully and efficiently and provides a unified way to protect, connect, and monitor microservices.

From the brief introduction above, we can see why there is a need to migrate Spring Cloud applications to Service Mesh. To sum up, there are four reasons:

Functional overlap

Let's take a brief look at their functional comparison:

Feature list Spring CloudIsito

Service registration and discovery

Support, based on components such as Eureka,consul, provide server, and Client management

Yes, obtain service information based on XDS interface, and rely on "virtual service routing table" to realize service discovery

Link monitoring

Supported, based on Zikpin or Pinpoint or Skywalking implementation

Support, based on sideCar proxy model, record network request information implementation

API Gateway

Supported, based on zuul or spring-cloud-gateway implementation

Support, based on Ingress gateway and egress implementation

Fuse

Support, based on Hystrix implementation

Support, based on the declaration configuration file, and finally converted into routing rule implementation

Service routing

Yes, routing forwarding based on gateway layer

Support, based on iptables rule implementation

Security policy

Support, based on spring-security components, including authentication, authentication, etc., support communication encryption

Yes, RBAC-based permission model, relying on Kubernetes implementation, while supporting communication encryption

Configuration center

Yes, springcloud-config component implementation

Not supported

Performance monitoring

Yes, collect data based on the monitoring components provided by Spring cloud, and dock with the monitoring data storage of third parties

Support, based on SideCar proxy, record service call performance data, and import third-party data monitoring tools through metrics adapter

Log collection

Support, provide client, and interface with third-party log systems, such as ELK

Support, based on SideCar agent, record log information, and import third-party log system through log adapter

Tool client integration

Support, provide message, bus, deployment pipeline, data processing and other tools client SDK

Not supported

Distributed transaction

Support, support different distributed transaction modes: JTA,TCC,SAGA, etc., and provide an implemented SDK framework

Not supported

Other

……

……

As you can see from the above table, from a functional point of view, there is a considerable amount of overlap between Spring Cloud and Service Mesh in the service governance scenario, which provides a potential possibility for Spring Cloud to migrate to Service Mesh.

Service containerization

In the current environment of the industry, there is a trend, or the status quo. More and more applications are on the road to application containerization, or in the future, containerization will become the standard form of application deployment. And no matter which kind of containerized running environment, it naturally supports the basic requirement of service registration and discovery, which leads to some functional overlap in the process of applying containers in Spring Cloud system, which may have a certain impact on the later application operation and maintenance, while Service Mesh needs to rely on the container running environment and makes up for the lack of container environment (which will be analyzed in detail later).

Specialize in the technical profession

From the perspective of software design, we have been pursuing a loosely coupled architecture and want to specialize in the field. For example, business developers hope that I only need to care about business logic, and do not need to care about the services of supporting tools such as link tracking, circuit breakers, service registration and discovery, while the platform supports developers. I hope my code does not contain any business-related content. The emergence of Service Mesh makes this situation possible.

Language barrier

At present, although Spring Cloud provides support for many protocols, it is limited by the Java technology system. This requires applications to be developed in the same language (which is not necessarily a bad thing) and, in some cases, not necessarily applicable to some work scenarios. From the point of view of micro-service design, it should not be limited by a certain language, and each service should be independent of each other. What we need is to follow the communication specification. On the other hand, Service Mesh can just remove the language barriers between services and realize the ability of service governance.

Based on the above four reasons, in the current environment, in addition to some Internet companies that have already taken the road of Service Mesh practice (such as Ant Financial Services Group's SOFASTACK), most enterprises have begun to contact Service Mesh and try to migrate the applications built by Spring Cloud to Service Mesh.

Migration Scheme from Spring Cloud to Service Mesh

The migration from Spring Cloud to Service Mesh is roughly divided into seven steps, as shown in the figure:

Analysis of Spring Cloud Architecture

The purpose of Spring Cloud schema parsing is to determine the need to remove functions that overlap with Service Mesh from the current service in preparation for subsequent service replacements. Let's look at a typical Spring Cloud architecture, as shown in the figure:

From the figure, we can briefly analyze a Spring Cloud-based micro-service architecture, which mainly includes four parts: service gateway, application service, peripheral support components, service management console.

Service gateway

The functions covered by the service gateway include routing, authentication, flow restriction, circuit breaker, degradation and other unified interception of inbound requests. It can be further divided into external gateway (Internet-oriented) and internal gateway (service-oriented internal management).

Application service

Application service is the core of enterprise business. The application service is composed of three parts: business logic implementation, external component interaction SDK integration, and service internal operation monitoring integration.

Peripheral support assembly

Peripheral support components, covering the application service dependent tools, including registry, configuration center, message center, security center, log center and so on.

Service management console

The service management console is oriented to service operators or operators to achieve real-time monitoring of the running status of application services, as well as the management and configuration of online services dynamically according to the needs of the situation.

Which of these things can we remove or do based on the capabilities of Service Mesh (for example, Istio)? 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), link tracking and its clients (Pinpoint and Pinpoint client, replaced by SideCar and Mixer). This is what we need to accomplish in Spring Cloud parsing: to identify the supporting modules that need to be deleted or replaced.

Service transformation

The purpose of service unit transformation is to complete dependency removal or dependency replacement based on the parsing results of the first step. According to the analysis results of the first step, the transformation of the service unit is divided into three steps:

Delete components, including gateways, fuses, registries, load balancing, link tracking components, and delete the SDK of the corresponding client

Replace the component, using httpClient's SDK to support the remote call of http protocol (originally in Ribbon), from the original registry-based call to http direct call

Change configuration information, modify and delete component-managed configuration information and necessary component interaction code (according to actual application)

Of course, in the process of service unit transformation, many details will be involved, which need to be dealt with according to the application characteristics, and there is no in-depth analysis here.

Service containerization

Service containerization is the current trend of application deployment. There are many different ways of containerization itself, such as Jenkins-based pipeline implementation, docker-maven-plugin + dockerfile implementation, and, of course, many different ways. Here is an example of how to implement a demo service in Spring Cloud through docker-maven-plugin+dockerfile:

The Dockerfile of a simple service is as follows:

ROM openjdk:8-jre-alpine

ENV TZ=Asia/Shanghai\

SPRING_OUTPUT_ANSI_ENABLED=ALWAYS\

JAVA_OPTS= ""\

JHIPSTER_SLEEP=0

RUN ln-snf / usr/share/zoneinfo/$TZ / etc/localtime & & echo $TZ > / etc/timezone

CMD echo "The application will start in ${JHIPSTER_SLEEP} s..." & &\

Sleep ${JHIPSTER_SLEEP} & &\

Java ${JAVA_OPTS}-Djava.security.egd=file:/dev/./urandom-jar / app.jar

# java ${JAVA_OPTS}-Djava.security.egd=environment:/dev/./urandom-jar / app.@project.packaging@

EXPOSE 8080

ADD microservice-demo.jar / app.jar

The service port is defined in the file and the command is run.

The plug-in configuration for Maven-docker-plugin is as follows:

Microservice-demo

.

Com.spotify

Docker-maven-plugin

1.2.0

Build-image

Package

Build

Tag-image

Package

Tag

${project.build.finalName}: ${project.version}

${docker.registry.name} / ${project.build.finalName}: ${project.version}

${project.basedir} / src/main/docker

${project.build.finalName}: ${project.version}

/

${project.build.directory}

${project.build.finalName}. ${project.packaging}

By adding docker-maven-plugin, you can load Dockerfile when executing mvn package and automatically build a container image of the service (the premise is to install the docker runtime environment locally, or to configure the remote connection environment of Docker in the development tool through environment variables), so as to complete the service containerization transformation.

Container environment construction

The container environment determines the deployment form of the Service Mesh. The deployment process of the container environment is not described in detail here. Interested friends can refer to the https://github.com/easzlab/kubeasz open source project, which provides Kubernetes ansible-based automated deployment scripts. We also recommend choosing Kubernetes to build the container environment. Here are the considerations for the construction of the container environment:

1. Cluster deployment scheme

The cluster deployment scheme mainly considers many factors, such as multi-cluster, cross-data center, storage selection, network scheme, cluster internal host label division, cluster internal network address planning and so on.

two。 Cluster scale

Cluster size mainly considers the size of etcd cluster, the size of running instances in the cluster (used to configure ip range), the size of highly available nodes in the cluster and other factors.

To consider the deployment scheme of containerized environment based on the above two points, the key is reasonable planning to avoid waste of resources.

Construction of Service Mesh environment

The construction of Service Mesh environment depends on the construction of container environment, which mainly considers two aspects. Take Isito as an example:

1. Deploy plug-ins

Istio deployment plug-ins need to consider the plug-in integrity, such as prometheus,kiali, whether to enable TLS and so on, according to the required scenarios. For more information on installation options, please see https://preliminary.istio.io/zh/docs/reference/config/installation-options/.

two。 Cross-cluster deployment

Consider whether a cross-cluster deployment scheme that supports Isito is needed according to the container environment.

Service injection

Service injection is used to connect containerized services to the Service Mesh platform, there are two main ways. Taking Isito as an example, it mainly includes automatic injection and manual check-in. The purpose of choosing manual injection is that the service access can be artificially controlled according to the internal launch process of the enterprise. Automatic injection can be faster and more convenient. At this point, the service migration has actually been completed.

Service management console

At present, Service Mesh is mostly based on declarative configuration files to achieve the effect of service governance, so it is impossible to deliver the execution results in real time. For this reason, an independent Service Mesh management console is needed, on the one hand, it can view the running status and policy implementation of each service, on the other hand, it can support the dynamic configuration management of policies in the running process of the service. At present, kiali can be selected as a console implementation during Isito installation, and of course, a large number of enterprises will provide specialized services in the future.

Through the above seven steps, we can help enterprise applications migrate from Spring Cloud to Service Mesh to a certain extent, but there must be a process of continuous trampling in the process of migration, which needs to be evaluated and planned in advance according to the characteristics of the application.

Analysis of advantages and disadvantages of migration

Is it good and harmless for Spring Cloud to move to Service Mesh?

First of all, starting from the containerized environment, the subsequent Knative,Kubernetes,Service Mesh will inevitably build a relatively complete containerized PaaS solution, so as to complete the construction of the containerized PaaS support platform. Service Mesh will provide escort for the container running state.

Secondly, as far as the current implementation of Service Mesh implementation is concerned, there is a lack of monitoring granularity for some specific requirements, such as calling thread stack monitoring (of course, from the network layer, or not within the scope of Service Mesh), but it is precisely within the scope of many service governance scenarios. We also need to consider the implementation plan in view of this situation.

Finally, everyone has been criticizing the performance and security issues. It has been strengthened, but it is still complained.

On the whole, Spring Cloud is the status quo of the micro-service implementation service governance platform, while Service Mesh is the future, and of course it cannot be completely replaced. After all, the design ideas and priorities are different, and whether to migrate depends on the business scenario.

This article is originally published by Boyun Research Institute. Please indicate the source when reproduced.

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.