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

Guide reading

In the current practice of micro-services, Spring Cloud,Dubbo, as the mainstream landing solution, plays a more and more important role in enterprise application architecture. This paper discusses how enterprise application architecture evolves from micro-service architecture to Service Mesh architecture, and forms a landing solution. Special note: the architecture discussed in this article is currently suitable for ordinary enterprise applications, and other industries (such as the Internet) need to be further expanded.

Before we discuss it, we need to be clear about the fact that enterprise applications must revolve around the business. No matter what architecture is adopted, it is to better serve the application business. Considering the characteristics of enterprise applications, it mainly includes: stability, security, expansibility, fault tolerance.

Around these characteristics of enterprise applications, let's look at a typical micro-service enterprise architecture model, as shown in the figure:

Service access layer: enterprises are exposed to the entrance of external access, usually through firewalls and so on.

Gateway layer: the service gateway is the middle layer between the client and the server. All external requests will first go through the service gateway to provide a unified access control entry for enterprise applications. Service gateway is the comprehensive embodiment of service splitting, aggregation, routing, authentication and flow control under micro-service architecture.

Support service layer: provide a supporting environment for enterprise applications to run, including registration discovery, centralized configuration, fault tolerance and current limit, authentication authorization, log aggregation, monitoring alarm, message service, etc.

Business service layer: business service is the core of enterprise application, which is the specific implementation of enterprise application. Generally, it is further divided into basic service (basic function) and aggregation service (integrated scenario).

Platform service layer: provide software resources for enterprise applications to run, including application server, application release management, application image package management, service governance.

Infrastructure layer: provide hardware resources for enterprise applications to run, including computing resources, network resources, storage resources, basic security policy control and so on.

From this typical service architecture, we can clearly show the hierarchical structure and the job description covered by each layer. We do not consider the infrastructure layer and platform services for the time being, focus on gateway services, business services, support services, highlight some of the basic support function components, which is also the focus of this article. As shown in the following figure:

According to the red logo in the figure, we will find such a fact: under the micro-service architecture, no matter which implementation method is on the ground, it focuses on two levels: gateway service and support service. Whether it is Spring Cloud "suite", Dubbo "suite" or other open source components, they all provide a large number of options for supporting the implementation of services. Complete functions and many choices are popular in the industry, but it also virtually increases the pressure on developers, testing, and operation and maintenance personnel. We need to master more and more "use tools" to deal with business services more "conveniently" and "quickly". Sometimes, in order to achieve a single function, a bunch of components must be introduced. At this time, we want to have a complete platform to provide integrated support services for the application business, rather than the integration of a series of "package components" with the business.

So how to achieve the capabilities required by these enterprise applications based on a platform? After a certain stage of technical research, we think that Service Mesh can help us initially achieve this goal.

We all know that Service Mesh is designed to solve the problem of "service communication", focusing on the "network layer" of infrastructure, and as a technical basis to solve the problems faced by business communication scenarios. So how can it be applied to enterprise application architecture to replace "micro-service suite components"? Next, let's take a look at gateway services, business services, and support services, respectively, how to extract from the original micro-service "suite components" to achieve the change in the direction of Service Mesh.

Gateway service

As mentioned earlier: the service gateway is the middle layer between the client and the server. It is not difficult to understand the function, shielding the internal details and providing a unified service interface to the outside. From the perspective of scene focus, gateways carry different responsibilities according to different scenarios, including authentication, authorization, routing, traffic control, load and so on. We have also talked about the comparison and implementation of gateway components before. Interested students can click on the comparison of five open source API gateway implementation components for micro services.

Thus it can be seen that the service gateway is the comprehensive embodiment of some functions under the enterprise application architecture. So how do you handle gateway services in the case of Service Mesh? Before the deployment, we need to explain a premise: so far, Service Mesh still has some shortcomings compared with the real enterprise gateway, such as "protocol conversion", "security policy", "performance requirements" and so on. Here we are also discussing such a possibility. Taking Istio as an example, let's take a look at how to provide services at the gateway level.

Istio provides two types of gateway services at the gateway level: Ingress Gateway,Egress.

Ingress Gateway

Ingress Gateway is used to receive incoming HTTP/TCP connections, it configures exposed ports and the protocol provides external unified access, but it does not provide any routing configuration itself, but relies entirely on the control rules of Istio for traffic routing. Thus, it can be unified to the same control level as the internal service request.

Egress

Between enterprise applications and external applications, sometimes internal services invoke external services for business needs. At this time, third-party gateways are generally accessed from within the enterprise to obtain service data. You can also achieve your goal based on Egress in Isito. Isito provides two ways: one is based on ServiceEntry + VirtualService configuration to achieve access to third-party services, and the other is to expand the access address list of sidecar. (reference document: https://preliminary.istio.io/zh/docs/tasks/traffic-management/egress/).

Based on the above two scenarios, we can see that in the Service Mesh system, the gateway layer becomes a component that can be dynamically generated and destroyed, and can achieve unified rule management through the control plane, and take effect in real time.

The Service Mesh-based gateway service is shown in the following figure:

From the analysis of the implementation principle, the traditional gateway implements the filter mode based on Servlet, which realizes the layer-by-layer filtering and processing in the process of service request transfer. The difference is that synchronous or asynchronous processing mechanisms are used to solve the performance bottleneck of the gateway. The gateway of Service Mesh is entirely based on the request forwarding and control of the network agent, which essentially acts on the Iptables of the service, and achieves the same effect through the rule control of Iptables.

Business service

Business is the "top priority" of enterprise applications, no matter which kind of enterprise architecture is ultimately to provide better services for the business, so how do we reconstruct business services under the system of Service Mesh? We use two simplified service calls to illustrate the transformation process of the entire architecture.

If you want to implement the mutual invocation between Service An and Service B, the most original way is that Service An invokes Service B directly based on the protocol layer (high availability, multiple replicas and load balancing are ignored here), as shown in the figure:

As can be seen from the figure, Service A completes the request to Service B based on a certain protocol, which is relatively simple. But we know that although this can quickly complete the business association, but can not ensure the normal and stable operation of the business, so we need to introduce more services to ensure the stability, reliability and controllability of the business. At this point, the easiest thing we can think of is to introduce supporting components of micro-services to achieve the goal.

Taking the Spring Cloud scheme as an example, let's illustrate the implementation of the current micro-service architecture. In order to meet the management and control of enterprise applications on service An and service B, you need to introduce additional "registry", "gateway", "configuration center", "service monitoring", "event message", "link tracking", "log service" and many other "bypass guarantee services" that are not related to direct business. Simplify, as shown in the following figure:

As can be seen from the figure, each service introduces a large number of "guarantee services" that have nothing to do with the business, and the resources consumed by these "bypass guarantee services" have a "multiple relationship" with the resources consumed by the business itself. With the increase of the number of services, the resource ratio of the business service itself will become less and less. At this time, developers will spend a lot of energy on maintaining these "bypass guarantee services" while ignoring the business itself. For enterprise applications, it means putting the cart before the horse.

Let's take a look at how we solve the above problems under the Service Mesh system. Service Mesh focuses on four aspects to solve the "communication problems" of enterprise applications. Represented by Istio, it provides telemetry functions including traffic management, security configuration, policy control and peripheral components (for those who need it, please refer to the official document: https://preliminary.istio.io/zh/docs). Under the architecture of Service Mesh, the architecture of Service A calling Service B will be shown in the following figure:

Through the figure above, we can find that compared with the implementation of Spring Cloud, it seems to be much simpler. We no longer need to introduce many "bypass guarantee services" into the business service, but ensure the simplification of the business service itself. So how does Service Mesh handle it?

First, the Sidecar agent model is introduced as the entrance and exit of service flow control to ensure real-time monitoring and adjustment of the data at the network level.

Second, according to the specific business situation, the controller distributes the control status and control instructions. After Sidecar obtains the control information, it updates the cache information in time to ensure the effectiveness of the strategy.

Third, because Sidecar can intercept all requested traffic information, it regularly reports the collected data to the control layer, so as to complete the monitoring of service status and application link.

Fourth, all of this is done in the application deployment phase and does not require a lot of effort at the development level.

Based on the above four points, we can find that Service Mesh has achieved the same effect only through way transformation, but also greatly liberated developers.

Through the transformation of the way business services are invoked, we find that Service Mesh further shields the obstacles brought by a variety of development languages while ensuring that the business is simplified and effective. It is completely based on the network level and protocol level as a starting point, to achieve the "unchanged response to change" effect.

Support service

From the point of view of the value of enterprise business, supporting services are more of a "resource consumption" product, but even so, it is an indispensable part of enterprise application architecture. From the transformation mode of single business invocation-> micro-service architecture business invocation-> Service Mesh system business invocation, we can see that the supporting service is in a process of continuous decline. Depending on the positioning of ServiceMesh, some supporting services will eventually appear as the form of infrastructure, which is also the trend of future development. The transformation of support services in the enterprise architecture is shown in the figure:

Traditional architecture: under the traditional architecture, there is basically no clear boundary distinction between supporting services and business services, and the implementation methods are all mixed together through code.

Micro-service architecture: under the micro-service architecture, supporting services and business services can be initially separated, but the unity and dependence of the code framework need to be guaranteed, and cross-language restrictions are more serious.

Service Mesh architecture: under Service Mesh architecture, supporting services and business services can be completely separated without language restrictions. The only thing that needs to be considered is the support of different protocols.

Through the transformation of support services, we can see that the separation of support services and business services is an inevitable trend, and the ultimate limitation depends on the processing and analysis capabilities of diversified network protocols. Of course, we need to be clear about the fact that in terms of the current development trend and positioning of Service Mesh, it can not completely replace all the supporting services, such as event messages, configuration management and so on. We expect it to help solve the scenarios and problems that application services need to face at the network level. This is where it gives play to its value.

Through the transformation of gateway services, business services and support services under different architectures, we clearly realize that Service Mesh can help us focus on solving the tedious "bypass support" services under the micro-service system, and ensure the simplicity and effectiveness of business services. Through evolution analysis, the final Service Mesh-based enterprise application architecture is shown in the following figure:

From the figure, you can see that there are three key things to do under the Service Mesh architecture:

The access work of the gateway layer, whether external request access or internal service request forwarding, can be implemented based on different types of gateway provided by Service Mesh. At the same time, it can also ensure the unified control and management of policies. The separate gateway management console is omitted.

For business service, the proxy model of Sidecar is added to handle all inbound and outbound traffic, and cooperate with the control strategy of supporting service to realize the bypass control function of business service.

Unified network-oriented support services, based on the idea of separation of control and data, according to the operation of business, improve the dynamic control ability in the process of enterprise application operation.

We also realize that using Service Mesh's ability to handle service communications, we can replace the functions such as "registration discovery", "fault tolerance and current limitation", "authentication authorization", "log collection", "monitoring alarm" and "flow control" supported by different components. While reducing the component code overhead, the supporting services of enterprise applications are further moved down. Both developers and domain experts can focus on dealing with the application business without "wasting time" on maintaining different functional components of third parties. On the other hand, business operation and maintenance personnel can monitor the running status of enterprise services in real time through the control platform of Service Mesh, without having to spend as much effort on maintaining different tools and components as before.

Finally, let's discuss how Service Mesh does this. In essence, Service Mesh does not adopt any technological innovation, but more ideological change. We think that there are several changes that need to be proposed:

Hierarchical change: Service Mesh no longer defines itself as an enterprise application component in its design idea, but sinks itself to the infrastructure layer and becomes part of the infrastructure, so that the hierarchical change is clearly separated from the enterprise business itself.

Mode change: Service Mesh is highly abstract in implementation, focusing on the communication link itself, rather than focusing on component functions, starting from the network layer, grasping the essence of service communication interaction.

Control transformation: Service Mesh separates control and implementation, provides a unified and flexible control entry, and can quickly and easily customize processing for business scenarios.

Finally, we need to explain that Service Mesh is not perfect, and there are still many problems that need to be solved step by step in the actual enterprise application process. Let's wait and see.

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.