takeaway

Spring Cloud and Dubbo, as the mainstream solutions, are playing an increasingly important role in enterprise application architecture. This paper discusses how enterprise application architecture evolves from microservice architecture to Service Mesh architecture, and forms a landing solution. Note: The architecture discussed in this article is currently suitable for common enterprise applications, and other industries (such as the Internet) need further expansion.

Before we begin, we need to clarify one fact: Enterprise applications must be about the business. No matter what architecture is adopted, it is to better serve the application business. Considering the characteristics of enterprise application, it mainly includes stability, security, expansibility and fault tolerance.

Around these characteristics of enterprise applications, let’s look at a typical microservices enterprise architecture model, as shown in the figure below:

  • Service access layer: the entry point through which the enterprise is exposed to external access, usually through firewalls, etc.

  • Gateway layer: The service gateway is the middle layer between the client and the server. All external requests pass through the service gateway to provide unified access control for enterprise applications. Service gateway is a comprehensive embodiment of service decomposition, aggregation, routing, authentication and flow control under the microservice architecture.

  • Support service layer: provides the support environment for enterprise applications, including registration and discovery, centralized configuration, fault tolerance and traffic limiting, authentication and authorization, log aggregation, alarm monitoring, and message service

  • Business service layer: Business service is the core of enterprise applications. It is the specific realization of enterprise applications and is generally further divided into basic services (basic functions) and aggregated services (comprehensive scenarios).

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

  • Infrastructure layer: Provides hardware resources for enterprise applications, including computing resources, network resources, storage resources, and basic security policy control.

From this typical service architecture architecture, the hierarchy and the responsibilities covered by each layer can be clearly demonstrated. We ignore the infrastructure layer and platform services layer for the time being and focus on gateway services, business services, and support services, highlighting some of the basic support functional components, which are also the focus of this article. As shown below:

According to the red mark in the figure, we can find such a fact: under the microservice architecture, no matter what kind of implementation method is implemented, it is concentrated on the two levels of gateway service and support service. Whether it’s Spring Cloud “suite components”, Dubbo “suite” or other open source components, there are a number of options for supporting service implementations. Complete features and more options are welcome in the industry, but it also increases the pressure on development, testing, and operations personnel. More and more “tools” are needed to “conveniently” and “quickly” respond to business services. Sometimes, it is necessary to introduce a bunch of components in order to achieve a single function. In this case, we want to have a complete platform to provide integrated support services for the application business, rather than a series of “suite components” integrated with the business.

So how do you implement the capabilities required by these enterprise applications on one platform? After a period of technical research, we believe that Service Mesh can help us preliminarily achieve this goal.

We all know that Service Mesh is designed to solve the problem of “Service communication”. It focuses on the “network layer” of infrastructure and uses it as the technical foundation to solve the problems faced by Service communication scenarios. So how can it be applied to enterprise application architectures to replace “microservice suite components”? Let’s take a look at gateway services, business services, and support services, respectively, and see how the Service Mesh can be transformed from the original “suite of components” of microservices.

Gateway service

As mentioned earlier, a service gateway is an intermediate layer between the client and the server. From the function is not difficult to understand, internal shielding internal details, external to provide a unified service interface. From the perspective of scenario focus, gateways carry different responsibilities according to different scenarios, including authentication, authorization, routing, flow control, and load. (We also talked about the comparison and specific implementation of gateway components before, those who are interested can click the comparison of five open source API gateway components of microservices).

Thus, the service gateway is the comprehensive embodiment of a series of functions under the enterprise application architecture. So how do you deal with gateway services in the case of Service Mesh? Before deploying the Service Mesh, it should be noted that there are still some shortcomings in Service Mesh compared with real enterprise gateways, such as “protocol transformation”, “security policy”, “performance requirements”, etc. We are also exploring such possibilities here. Using 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 and Egress.

  • Ingress Gateway

The Ingress Gateway is used to receive incoming HTTP/TCP connections. It provides exposed ports and protocols for unified external access. However, it does not provide any routing configuration and relies entirely on Istio control rules for traffic routing. To unify with internal service requests on the same level of control.

  • Egress

Sometimes, an internal service invokes an external service to obtain service data between an enterprise application and an external application. In this case, the enterprise accesses a third-party gateway to obtain service data. In Isito you can also do this with Egress. Isito provides two modes: One is configured based on ServiceEntry + VirtualService to access third-party services; the other is to expand the sidecar address list. (reference: preliminary. Istio. IO/useful/docs/tas…

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

The gateway services based on Service Mesh are shown as follows:

From the analysis of the implementation principle, the traditional gateway realizes the filter mode based on Servlet, and realizes the layer upon layer filtering and processing in the process of service request transfer. The difference lies in the use of synchronous or asynchronous processing mechanism to solve the performance bottleneck of the gateway. The gateway of the Service Mesh is completely based on the network proxy request forwarding and control. Essentially, it functions on the Iptables of the Service and achieves the same effect through the rule control of the Iptables.

Business services

Business is the “top priority” of enterprise applications. No matter what kind of enterprise architecture, it ultimately aims to provide better services for business. Then, how can we reconstruct business services based on Service Mesh? We illustrate the architectural transformation process with two simplified service invocations.

If the mutual invocation of service A and service B is to be realized, the most primitive way is that service A directly invokes service B based on the protocol layer (the high availability, multi-copy and load balancing mode is temporarily 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. However, we know that although it can quickly complete business association, it cannot ensure normal and stable operation of business. Therefore, we need to introduce more services to ensure stable, reliable and controllable business. The easiest thing to think of at this point is to introduce supporting components for microservices to achieve this goal.

Using the Spring Cloud solution as an example, we illustrate how the current microservices architecture is implemented. In order to satisfy the business enterprise application service. A, B, management control, need additional introduction “registry”, “gateway”, “configuration center”, “service monitoring”, “event messages” tracking “link”, “logging services” and so on has nothing to do with the direct business “bypass security service”, simplify, as shown in the figure below:

As shown in the figure, each service introduces a large number of safeguard services unrelated to services. The resources consumed by these bypass safeguard services are multiple of those consumed by the service itself. As the number of services increases, the business services themselves consume less and less resources, and developers spend a lot of energy maintaining these “bypass assurance services” instead of the business itself. This is putting the cart before the horse for enterprise applications.

Let’s take a look at how we solved this problem with Service Mesh. Service Mesh addresses the “communication problem” of enterprise applications by focusing on four aspects. Represented by Istio, Service Mesh provides traffic management, security configuration, policy control, and telemetry supported by peripheral components. Preliminary. Istio. IO/useful/docs), in the S… In the framework of Mesh, the architecture of service A calling service B will look like the following:

From the figure above, we can see that compared to the implementation of Spring Cloud, it seems to be much simpler. We no longer need to introduce many “bypass assurance services” into the business services, but to ensure the simplicity of the business services themselves. So how does the Service Mesh work?

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

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

Third, Sidecar intercepts all requested traffic information and periodically reports the collected data to the control layer, thus completing the monitoring of service status and application links.

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

Based on the above four points, we can see that Service Mesh achieves the same effect just by changing the mode, and greatly liberates the developers.

Through the implementation transformation of business Service invocation, we discovered the fact that the Service Mesh further shields the barriers of multiple development languages while keeping the business simple and efficient. It is based entirely on the network level and protocol level as the starting point, to achieve the effect of “constant to change”.

Support services

From an enterprise business value perspective, support services are more of a “resource hog”, but they are nonetheless an integral part of the enterprise application architecture. From the transformation mode of single business invocation –> Microservice system business invocation –>Service Mesh system business invocation, it can be seen that the supporting services are in a process of continuous hierarchy decline. Depending on the positioning of ServiceMesh, eventually some supporting services will be presented as infrastructure, which is also the trend of future development. The transformation of supporting services in enterprise architecture is shown in the figure below:

  • Traditional architecture: Under the traditional architecture, there is no clear boundary between support services and business services, and the implementation methods are all mixed together through code.

  • Microservice architecture: Under microservice architecture, support services and business services can be separated initially, but the unity and dependence of code framework need to be guaranteed, so cross-language constraints are serious.

  • Service Mesh architecture: Under the Service Mesh architecture, services can be completely separated without language restrictions. The only consideration is the support of different protocols.

It can be seen from the transformation form of support services that the separation of support services and business services is an inevitable trend, and the ultimate limitation depends on the processing and analysis ability of diversified network protocols. Of course, we need to be aware of the fact that the current trend and positioning of Service Mesh does not completely replace all supporting services such as event messaging, configuration management, etc. We expect it to help solve the scenarios and problems that application services face at the network level. That’s where it comes in.

Through the transformation of gateway Service, business Service and support Service in different architectures, we clearly realize that Service Mesh can help us focus on solving the complicated “bypass support” services in micro-service system, and ensure the simplicity and effectiveness of business services. Through evolutionary analysis, the final enterprise application architecture based on Service Mesh is shown as follows:

As you can see from the diagram, the Service Mesh architecture focuses on three things:

  1. Access at the gateway layer, whether external request access or internal Service request forwarding, can be implemented based on different types of gateways provided by the Service Mesh, and unified control and management of policies can be ensured. A separate gateway management console is omitted.

  2. For business services, the agent model of Sidecar is added to handle all inbound and outbound traffic, and with the control strategy of supporting services, the bypass control function of business services is realized.

  3. Unified network oriented support services, based on the idea of separation of control and data, improve the dynamic control ability of enterprise applications in the process of operation according to the running status of services.

We also realized that the Service Mesh can be used to process Service communication and replace functions such as “registration discovery”, “fault tolerance and traffic limiting”, “authentication and authorization”, “log collection”, “Alarm monitoring” and “traffic control” that need to be supported by different components. Move the supporting services of enterprise applications further down the chain while reducing component code overhead. Developers, as well as domain experts, can focus on the business of the application and not “waste time” maintaining different functional components of a third party. Business operations, through the Service Mesh control platform, can monitor the health of enterprise services in real time without the need to maintain different tools and components.

Finally, let’s discuss how Service Mesh does this. Service Mesh is not a technical innovation per se, but more of a thinking change. We think there are several shifts that need to be addressed:

  • Hierarchical transformation: Service Mesh is no longer positioned as an enterprise application component, but rather sinks into the infrastructure layer and becomes part of the infrastructure. In this way, the hierarchical transformation is clearly separated from the enterprise business itself.

  • Mode change: Service Mesh is highly abstract in terms of implementation, focusing on the communication link itself rather than on component functions. Starting from the network layer, it captures the essence of Service communication interaction.

  • Control transformation: Service Mesh separates control and implementation, provides unified and flexible control entry, and enables rapid and convenient customization for business scenarios.

Finally, the Service Mesh is still incomplete, and there are many problems that need to be solved gradually in the actual enterprise application process. Let’s wait and see.

This article was originally published by Boyun Research Institute.