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

Guide reading

Recently, I have exchanged Service Mesh and its related technologies with several enterprise users, and everyone has expressed great interest in its shape and future development. However, it shows great confusion about how to integrate the current situation of enterprise applications with Service Mesh. This paper tries to combine the technical characteristics of Service Mesh with the actual situation of enterprise applications, and gives Boyun's own thoughts on how Service Mesh should deal with enterprise applications. Interested friends are welcome to discuss.

Before going into detail, let's review the definition of Service Mesh: a service grid is an infrastructure layer for handling inter-service communication, which is responsible for delivering reliable network requests for building complex cloud native applications. In practice, a service grid usually implements a set of lightweight network proxies deployed with the application, but is transparent to the application.

From the definition, we can clearly see the technical positioning of Service Mesh: "the infrastructure layer that handles communication between services." So we can't expect it to help us simplify the challenges of developing test scenarios (DevOps or application services, of course, to some extent, which can decouple the invocation relationship between the application and the underlying middleware, which will be explained in more detail later), or solve the problem of application deployment scenarios (deployment problems are more appropriately handled by the container orchestration platform).

Generally speaking, Service Mesh focuses on the communication problems in the later stage of business application deployment, while decoupling the invocation relationship between business units and basic middleware (such as service registry) to some extent. As shown in the figure:

Focusing on the areas that Service Mesh focuses on and how to serve enterprise applications, this paper focuses on four issues:

Technical characteristics of Service Mesh

The Integration of Service Mesh and Enterprise Application

Deployment management form of Service Mesh

The prospective form of Service Mesh.

Technical characteristics of Service Mesh

Considering that the current landing mode of Service Mesh is concentrated in the field of PaaS, which is led by containerization, we will also focus on the technical characteristics of Service Mesh based on containerization.

From the perspective of Service Mesh development, both the basic Docker running environment and the container orchestration environment with Kubernetes as the "de facto standard" are the cornerstone of the rapid development of Service Mesh. Taking Kubernetes as an example, Service Mesh is not a technological innovation, but more an extension of Kubernetes using CRD features and the integration of traditional technologies (firewall, DNS service discovery, etc.). Taking Isito as an example, Istio customizes dozens of its own resources based on the introduced standard specifications and Kubernetes CRD features, and relies on kubectl CLI command tools to manage these CRD uniformly.

We find that the technical characteristics of Service Mesh are mainly reflected in five aspects: container orchestration environment; data agent control; configuration management distribution; service link tracking; service communication security.

Container orchestration environment

Combined with several solutions of Service Mesh landing, container orchestration environment is one of the necessary elements for Service Mesh to land. (here we will not discuss the technical principles of containerization, such as namespace,AUFS, etc.). The characteristics of containerized orchestration environment can organize enterprise applications or business instances into business units that are easy to manage and address, and access these units in a systematic way. All kinds of Adapter of Mesh peripheral docking are also ignored here.

Data agent control

As can be seen from the definition of Service Mesh, it is a lightweight network agent bound with the application, which intercepts the outbound and inbound traffic of all service requests, and relies on the rule information provided by the standardized interface in the control plane (which is eventually transformed into the routing configuration in the firewall) to forward and control the traffic. At the same time, the call log, call link, response time are recorded and reported.

Configuration management distribution

In order to ensure the independence of the data agent function, Service Mesh decouples the configuration from the data agent. The configuration, also known as the control plane, is responsible for collecting service information from the container environment and providing data proxy services with highly abstract standard interfaces, providing reliable routing dependencies for traffic forwarding. At the same time, the control layer provides users with "declarative" rule definitions, which are stored in the container platform, generate flow control rules for routing and forwarding, and provide them to the data agent service in the form of an interface to provide management basis for routing and forwarding flow control. For example, in Istio, the rule definition is represented as the CRD resource defined by Istio, and the rule effective interface is represented as the XDS interface provided by Policy.

Service link tracking

Service link is a basic and essential function in Service Mesh. Its implementation depends on two parts: data acquisition and link presentation. Data acquisition mainly relies on the data proxy service to intercept or forward the service request to record the source IP address, destination IP address and corresponding service name and other effective information; link presentation depends on the distributed tracking system, the collected service call link information is stored in the distributed tracking system for centralized presentation, such as Zipkin and so on.

Service communication security

Security is one of the factors that enterprise applications must pay attention to, so what technical features does Service Mesh provide in the field of security? As an extension of PaaS, Service Mesh provides security protection for enterprise applications from three aspects:

First: two-way traffic encryption based on TLS. For example, Isito can open the TLS two-way authentication configuration during deployment, and rely on independent certificate management functions to realize the encryption of the service communication process.

Second, access is controlled by permissions. In order to ensure the validity of service invocation, Service Mesh provides permission access control. For example, RBAC-based access control in Isito

Third: policy-based blacklist access control and service circuit breaker control.

Of course, only relying on Service Mesh to ensure the security of enterprise applications is not enough, we also need to use other software and hardware means, such as firewalls, network security monitoring, internal anomaly detection and so on, which are not discussed in this article.

The way to integrate Service Mesh with Enterprise applications

After learning about the technical features of Service Mesh, let's focus on how Service Mesh integrates with enterprise applications.

Before we start, let's talk about the current situation and characteristics of enterprise applications: according to the results of Gartner's statistical survey of the current PaaS market, most enterprises are in the stage of transition from traditional applications (physical or virtual) to containerization, and different industries expect to be able to migrate their applications to the cloud reasonably (focus on PaaS). However, there are more or less concerns about the legacy enterprise systems, especially the PaaS on the core systems, so we divide the deployment patterns of enterprise applications into three levels (no priority):

First: core systems, containerized processing will not be considered in the short term (in the next few years), such as core databases and core systems of the financial industry.

Second: support system, which is mostly virtualized at present, and may try to service containerization.

Third: external systems, mainly virtualization, expect to migrate to the PaaS platform; at present, whether project delivery or product self-development, the vast majority focus on the third type of application systems, which is also the focus of our current consideration.

Secondly, let's analyze the characteristics of enterprise applications: enterprise applications are business-driven in most cases. According to this level, there are two situations when building a business system: integrated application and service-oriented application.

For integrated applications, integration with Service Mesh can not give full play to the effectiveness of Service Mesh (because of centralized business processing, all functional and non-functional systems are concentrated in the code itself, to a certain extent, Service Mesh integration is not meaningful). Therefore, we focus on the integration of service-oriented applications and Service Mesh. The reason for this consideration is that based on micro-services or cloud native applications is the trend of building systems, but also more in line with the law of the development of application forms.

According to the current situation and characteristics of enterprise applications, we divide the integration of Service Mesh and enterprise applications into four stages, as shown in the following figure:

Application service

There are some differences between application service and so-called micro-service construction. On the whole, the service-oriented application or the use of micro-service split principle to split the service of the application business unit, while determining the supporting components of the interdependence between services.

The difference lies in the selection of service direct interaction components, instead of using the supporting functions provided by Spring Cloud, Dubbo or other components (such as service registration and discovery, service link tracking, load balancing, etc.), but relying on container platforms (such as service registration discovery provided by kubernetes, load balancing) and Service Mesh. The purpose of this approach is to sink the application support components, help customers free themselves from the details of technical research and selection, and consider the problem entirely from a business point of view. Matters outside the business are handled uniformly by the PaaS platform and Service Mesh.

Application service has two purposes: to split the application business unit and to sort out the business unit call chain. (need to be further explained: to abandon the service registration and discovery component is not to abandon its capabilities, but to change to a more convenient implementation. In the development environment, the joint debugging of various services can directly use the invocation framework of HTTP or other protocols for remote service invocation; in the test or production environment, replace the service address with the Service address registered on the container platform, so as to have the ability of service registration discovery and service load.

Of course, for business systems that have been developed based on Spring Cloud or Dubbo, they can also be integrated with Service Mesh without changing the original architecture, but there will be some conflicts at the service governance level. at present, the most effective solution is to give the support capability to the platform itself, decouple the business from the support, and achieve complete service.

Application containerization

As mentioned above, containerization is a necessary condition for the existence of Service Mesh in current landing practice (it can be de-containment, of course, but it is undoubtedly costly). At present, there are many ways to realize the containerization transformation after the split of the application service. The most direct thing is to use the DevOps tool chain to build an application service container image. Of course, it can also be implemented independently for different platforms or languages, such as the docker plug-in of Maven, the CI process provided by github, the pipeline provided by Jenkins, etc., which can well implement the service containerization operation, which is not discussed here. It should be pointed out that the focus of service containerization is to build a set of control process norms in line with the enterprise system and style, in which the technical factor is not the dominant factor, which needs to be decided according to the situation of the enterprise itself.

Apply Mesh integration

Application service and application containerization can solve the vast majority of scenarios in which applications migrate to PaaS platform. However, the first two only solve the problem of service orchestration and deployment, and do not provide more functions for the management support after the service is launched, and Service Mesh is located in this field. So how do applications integrate with Mesh? This can be done in four steps, as shown in the figure:

The first step is the integration of Service Mesh and PaaS infrastructure. Take advantage of the powerful orchestration and deployment capabilities of the PaaS platform to deploy the control plane of Service Mesh (specific projects such as Isito). Each component will automatically initialize the environment required by Mesh and collect the required information from the PaaS platform at startup, and when necessary, Mesh can be used as part of the infrastructure of the PaaS platform.

Second, configure the PaaS platform. Make it have the function of automatic injection of agents in Mesh (such as the configuration of automatic injection of Sidecar in Istio). Of course, this step can be omitted and then manually injected by users, in order to intercept service requests and forward traffic.

The third step is to deploy business applications directly using PaaS platform. At this time, the application has been bound with Mesh to share the entire network stack resources, realizing the preliminary integration of the application and Service Mesh.

The fourth step is to set the service communication rules by using the Service Mesh control plane entrance deployed in the second step, so as to control the communication between services, and finally complete the integration of application and Mesh.

Mesh management control

Service Mesh management control is the only entrance for customers to intervene in inter-service communication. On the other hand, the control of Service Mesh based on "declarative" rules will determine that there are more rule setters in the process of enterprise management, but there is no condition for real-time verification of the validity of the rules. Therefore, it is necessary to monitor whether the current service meets the expectations in combination with other peripheral components. For example, interfacing with Prometheus, obtaining the operation data of the service (including the number of tcp connections, the number of successful requests, the length of requested links, etc.), and managing the alarm policy based on AlterManager, or interfacing with the ELK log platform to uniformly analyze and manage the logs of service calls. Of course, there are other systems, known as Adapter.

Generally speaking, applications are the source of data generation, Service Mesh is responsible for service communication control, service data collection and service data reporting, and other platforms are responsible for data processing. Only by working together can Service Mesh be integrated with enterprise applications to maximize its effectiveness.

Service Mesh deployment management form

Considering the current technical implementation, the deployment form of Service Mesh needs to rely closely on the underlying implementation of the PaaS platform, especially on the containerized environment. Whether it is a single cluster or praise cluster deployment, the official documentation provides a detailed deployment solution, which is not explained here. You can refer to the implementation of Istio (https://preliminary.istio.io/zh/docs/concepts/multicluster-deployments/).

The best way to manage Servie Mesh is to integrate with PaaS and add various functions of service governance on top of PaaS's own capabilities, which will help PaaS platform to better integrate resources. Service Mesh is also a supplement to PaaS, thus forming a full set of PaaS solutions: including DevOps tool form, PaaS orchestration deployment form, and Mesh service governance form. At this point, you have the ability to centralize control over all stages of the application life cycle.

Service Mesh prospective form

This is a bold prediction, no matter from a technical point of view, or the development trend of the industry, Service Mesh will inevitably become one of the main tools of service governance in the future. Its biggest advantage for enterprise applications is to decouple the application business, and the enterprise can thoroughly consider the problem from the business point of view. Compared with the pure micro-service architecture, it is another step forward, and the integration with the container orchestration deployment platform may eventually become the standard form of enterprise application orchestration deployment and service governance.

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.