Abstract: Microservice transformation is the highlight of cloud-native evolution for government and enterprise customers, but how to achieve low cost, high security, stable performance, and convenient invocation is a science. This article describes the solution of HUAWEI CLOUD Stack.
This article is shared from the HUAWEI CLOUD community " [Huawei Cloud Stack] [Big Shelf Visit] Issue 17: A Safer and Lower Cost-Effective Microservice Architecture Transformation " by Yang Yihua, an expert in cloud technology planning.
In the previous article " Cloud Native Era, Difficulties and Countermeasures for IT Monitoring and Diagnosis in Government-Enterprise Hybrid Cloud Scenarios " , we introduced several microservice architecture models, as shown in the following figure :
Note: Image source https://twitter.com/bibryam/status/1026429379587567616
Today I mainly introduce how the first SOA/ESB architecture evolves towards the third cloud-native ServiceMesh architecture in the Java language scenario .
Introduction to SOA/ESB Architecture and Overview of Issues
First of all, let's take a look at the typical architecture pattern of SOA/ESB architecture on the current cloud architecture.
As shown in the figure below, taking HUAWEI CLOUD as an example, when deploying applications in this mode, the typical cloud services used are elastic load balancing (ELB) + elastic scaling (AS, including ECS). In this scenario :
• It is necessary to initiate a call to the client program, directly call to the ELB through the configured domain name or address, and call to the back-end ECS server through the ELB.
• Multiple IP addresses of backend servers need to be configured on the ELB. Of course, generally such operations can be simplified as adding some type of auto scaling group. In this way, when the ECS is elastically scaled, the administrator does not need to deal with the ELB configuration, and the ELB can automatically refresh the changes in the IP list of the ECS. (For configuration operations, see: https://support.huaweicloud.com/usermanual-as/as_01_0102.html )
It is worth noting that several variants of the above pattern are possible.
• For ELB, an API gateway may be used instead, or user-built KONG , APISIX , Envoy, etc., depending on the business scenarios of each enterprise. For example, some Internet companies tend to use the self-built KONG. The main reason is that in addition to basic service discovery and load balancing capabilities, the gateway also needs to handle some authentication situations for internal cross-domain calls.
• For elastic scaling, Kubernetes' Deployment + HorizontalPodAutoscaler may also be used directly instead. This of course depends on the adoption of the internal infrastructure of the enterprise, whether it is more inclined to use a virtual machine architecture or a container architecture.
Although the above architecture has certain advantages in terms of isolation and security, its shortcomings are also very obvious .
• Performance and resource overhead. This is easy to understand. Compared with the microservice architecture, an extra hop is added to the network on the SOA/ESB architecture, and the introduction of ELB will also increase the additional consumption of resources.
• Operation and maintenance costs. After all, an additional ELB component is introduced, so when calling between microservices, where is the bottleneck and whether the ELB needs to be expanded or contracted are all problems.
Some methods and problems of microservices and cloud native architecture transformation
There are also many methods in the industry on how to transform the SOA/ESB architecture and evolve towards a microservice architecture or a cloud-native architecture. There are mainly two categories :
• Transform the application into a microservice architecture by modifying the code. For example, directly introduce components such as Spring Cloud's service registration discovery and load balancing into the code. Of course, this kind of transformation is often not simple, mainly depends on the development framework adopted by the existing application. For example, the application itself does not use spring for development, so directly using Spring Cloud may bring massive transformation costs to the application.
• Using the istio solution, the architecture is upgraded to the ServiceMesh architecture through limited transformation and application. The reason why this solution is a limited transformation is that the istio solution is not completely unlimited for applications in terms of service invocation methods. At least it needs to transform the called http calling address into k8s native service address on the client side, so that the called service management can be effectively taken over by envoy. Of course, after the transformation is completed, there may be no shortage of users in terms of performance degradation for sidecars and more complex call operation and maintenance issues.
To sum up, both solutions have obvious shortcomings. Next, analyze how to make up for the shortcomings of the above two solutions by adopting the Sermant method for architectural transformation.
Sermant's thoughts on SOA/ESB architecture upgrade
Using Sermant ( https://sermant.io/zh/ ) to upgrade the SOA/ESB architecture, the essence of the final architecture is Service-Mesh. Because the methods adopted are slightly different, the solution has no shortcomings in terms of performance and operation and maintenance. Mainly the following two points:
• First of all, Sermant uses Java Agent to dynamically inject enhanced service logic management, so the application side theory can do without changing the code at all.
• Secondly, since the core logic of Sermant is AOP (Aspect-Oriented Programming), Java Agent and business belong to the same process, so there is no particularly large loss of sidecar form in terms of performance.
The architecture of the Sermant solution is shown in the figure below:
In terms of core technology, the functions of the Sermant transformation plan mainly include the following aspects:
• Built-in service registry discovery mechanism. (points 1 and 3 in the image above)
- The plug-in itself will have a service registration function, which will automatically go to the registration center for service registration when the Provider application starts.
- When the Consumer application makes a URL service call, the original service direct adjustment is replaced by the microservice service discovery + load balancing mechanism.
• Domain name to application name conversion. (the second point in the image above)
- During service discovery, since the original call uses URL direct call, it does not contain application information. This requires a mapping of call relations to application names. For this piece of content, we plan to make a dynamic configuration in the future and store it in the configuration center. In this way, when an application needs to initiate a call, Sermant directly converts the URL into an application name, and then obtains the corresponding application IP list in the registration center.
- After obtaining the name of the Provider application through the URL, during the transformation process, the application without the Provider does not carry the Sermant Java Agent in the same batch , so a whitelist mechanism is required to cooperate with the grayscale release.
• Enhanced client-side load balancing, retry, isolation, and degradation mechanisms. (the fourth point in the picture above)
- Combined with the previous step, a complete commercial solution, in addition to the basic load balancing function required by the Consumer calling the Provider, further retries, fault-tolerant isolation, and downstream current limiting and downgrading processing are required.
- In addition, some necessary governance capabilities for east-west traffic, such as 3A certification between services, also need to be further completed on the Sermant side.
The above are the main function points of the Sermant transformation plan. In addition, how to upgrade the existing environment in practice requires certain methods to avoid too much impact on the existing environment. Describe in detail below.
Using Sermant to upgrade the SOA/ESB architecture in practice
Application transformation cannot be accomplished overnight in specific situations, so the specific implementation must be a gradual process. Taking the Kubernetes container scenario as an example, this article introduces how to use Sermant to upgrade the cloud-native architecture of SOA/ESB based on grayscale, which is safe and controllable, in the case of hundreds of microservice applications and thousands of instances.
The following are the preparations:
• Preparatory step 1: Whether the application supports it. The updated Java framework for microservices currently supported by Sermant can be queried in this document. If it is not supported, you can consider submitting an Issue to the community to solve it.
- Reference link: https://sermant.io/zh/document/plugin/springboot-registry.html#%E8%AF%A6%E7%BB%86%E6%B2%BB%E7%90%86%E8% A7%84%E5%88%99
• Preparation step 2: Install Injector in Kubernetes to allow Java applications to automatically mount Sermant Java A gent in a non-intrusive manner.
- This step is optional. If skipped, you need to manually change the application deployment script to load the sermant java A gent.
- Reference link: https://sermant.io/zh/document/user-guide/injector.html
The detailed implementation process is described below. Assume the initial architecture is as follows. There are three Apps in total, among which App1 is connected to App2 and App3 through ELB. To simplify the description, the application in the figure is a single instance, and there may be multiple instances in actual production.
Next, publish the new version of App1 and App2 in Kubernetes (the V2 version in the figure), and carry the Sermant Javaagent when publishing, and activate the SpringBoot registration plug-in. However, you can not configure the Provider whitelist rule at this time, so after the release, the application traffic should still go through the ELB without any changes.
Then in the configuration center, add App2 to the whitelist. At this time, for the application that recognizes App2, the App1 instance (the V2 instance in the figure) with the Sermant Javaagent attached will directly initiate a call to the App2 instance in a load balancing manner. At the same time, the traffic of App1 accessing App3 remains unchanged.
After the verification is successful, delete the V1 versions of App1 and App2, and the traffic from App1 to App2 will be discovered through registration in the registration center, and the direct connection will be fully realized. At the same time, the traffic of App1 accessing App3 remains unchanged.
So far, the cloud native architecture upgrade of App1 and App2 using Sermant is completed. Subsequent other App applications can be grayscale upgraded according to a similar plan until all applications are mounted on Sermant to complete the direct connection transformation of microservices.
conclusion
Sermant , as a bytecode enhancement framework focusing on the field of service governance, is committed to providing a high-performance, scalable, easy-to-access, and feature-rich service governance experience, and will take good care of performance, functions, and experience in each version .
Currently Sermant has been integrated in ROMA Factory in Huawei Cloud Stack (HCS), and users can use related functions in Huawei Cloud Stack ROMA Factory. https://www.huaweicloud.com/zhishi/solution-ROMA-Factory-jiagou.html
Developers can also join the Sermant community to participate in the discussion and co-construction of related functions.
• Sermant official website: https://sermant.io
• GitHub warehouse address: https://github.com/huaweicloud/Sermant
Click to follow and learn about Huawei Cloud's fresh technologies for the first time~