A fully managed solution for microservice applications in the serverless era

Author: Chen Xin

Development and Challenges of Microservices in the Serverless Era

In the early days, the scale of the business was relatively simple, and most teams developed and adopted single applications, which could well meet the business needs of the team and could iterate rapidly. However, with the continuous growth of the business scale, the system becomes more and more complex, and the single application gradually cannot meet the problem of online production. For example, in the e-commerce business, if all functions such as transaction, payment, and commodity are developed in a single application, it is possible that the function of publishing simple commodities will affect the transaction, thereby affecting the entire e-commerce system and causing losses to the enterprise. .

At this time, many teams will change the monolithic application architecture to a microservice architecture to solve the problem of monolithic applications. However, as the business further develops, the system becomes more complex, and with the advent of new technologies, such as the standard K8s in the cloud-native era and the container image Docker, etc., the investment in R&D, operation and maintenance will increase, requiring dozens or even hundreds of guarantees. The normal operation and cooperation of each service brings great challenges to operation and maintenance:

1. Efficiency: With the expansion of the application scale, the new R&D team needs to face many complex problems in development and testing. In terms of team collaboration, how to better form a stable call link between different application teams, and how to quickly deploy and grayscale applications on the call link in large-scale scenarios with dozens, hundreds or even thousands of applications . In addition, the processing of the traffic of so many applications, the tracking of the call link and the service authentication also greatly affect the efficiency.

2. Stability: After microserviceization, there will be a problem with a core application on the calling link, resulting in an avalanche of the overall system, and sometimes there is a lack of a visual and observable system to help quickly locate and analyze problems, making it difficult to quickly locate the problem. The application of the problem causes long-term losses;

3. Cost: A single application generally only needs to deploy a few machines; in the era of microservices, with the sharp increase in the number of applications, it is necessary to maintain some redundancy for each application due to availability considerations. For example, in a big promotion, one The call link will involve more than a dozen applications. For the stability and security of the call link, the application capacity of the entire link will be expanded. In fact, many applications may have no traffic for a long time, and the server may be idle, resulting in huge cost waste.

Faced with these problems and requirements brought by microservices, what work has the serverless application engine done in this regard? What changes have it brought?

Introduction of SAE Microservice Application Fully Managed Solution

SAE is a Serverless PaaS platform for microservice applications. As a cloud platform, it can host the full life cycle of microservice applications. It can combine the dividends of Serverless and K8s itself, allowing microservice applications to go online quickly. It is quickly provided to users in a productized form, out-of-the-box, to solve common microservice problems for users, and to improve R&D efficiency.

SAE provides functions including but not limited to CI/CD pipeline, microservice framework, Spring Cloud, Dubbo, shared registry, K8s container and many operation and maintenance related functions, including call chain, log, alarm, performance monitoring, traffic management and Automatic elasticity, etc. It is a best-practice platform for deep integration of serverless frameworks and microservices.

SAE Microservices Capabilities and Practices

Underlying Capabilities: Enhanced Microservice Capabilities

In the serverless era, the trend of microservices is that the client is getting thinner and thinner, and the parts unrelated to service governance and business logic are deposited in components such as Java agent, injected into the business through bytecode, and the development of business It is non-intrusive and non-perceptive, and provides rich microservice governance capabilities in the process. For example, traffic management-related capabilities such as lossless online and offline, canary publishing, and visual data reporting.

For non-Java scenarios, Java agents can also communicate with different microservice frameworks. In addition, communication with Sidecar is also under construction.

Development practice: device-cloud joint debugging

Serverless Application Engine (SAE) based on Alibaba CloudToolkit plug-in + Springboard can achieve:

• Local service subscription and registration to the cloud SAE built-in registration center;
• Local services can call each other with cloud SAE services.

In the implementation, the user needs to have an ECS proxy server. The actual registration is the ECS proxy server to the SAE registration center. After IDEA installs the Cloudtoolkit plug-in, when starting the process, it will pull up a local channel service, this channel service will When connected to the ECS proxy server, all local requests will be transferred to the ECS proxy server, and cloud calls to services will also be transferred to the local through the ECS proxy server, so that the latest code can be debugged at the local breakpoint. This is cloud joint debugging realization.

Release state practice: lossless offline

In the process of version replacement, how does SAE ensure that the traffic of the old version of the microservice can be offline without damage?

The above figure shows the entire process of microservice registration and issuance. There are service consumers and service providers in the figure. The service providers have two instances of B1 and B2 respectively, and the service consumers have two instances of A1 and A2 respectively.

B1 and B2 register themselves in the registry, the consumer refreshes the service list from the registry, and finds service providers B1 and B2. Under normal circumstances, the consumer starts to call B1 or B2, and service provider B needs to release a new version. One of the nodes to operate, such as B1, first stops the Java process. The service stop process is divided into active destruction and passive destruction. Active destruction is quasi-real-time, and the time of passive destruction is determined by different registration centers. The worst case may require One minute. If the application is stopped normally, the ShutdownHook of Spring Cloud and Dubbo framework can be executed normally, and the time-consuming of this step is basically negligible.

If the application is stopped abnormally, such as a direct Kill-9 stop, or when the Docker image is built, the Java process is not the No. 1 process, and the Kill signal is not passed to the application, then the service provider will not take the initiative to log out Node, it will wait for the registration center to discover and passively perceive the process of service offline.

When the microservice registry perceives that the service is offline, it will notify the service consumers that one of the service nodes has been offline. There are two methods: push by the registry and polling by consumers. The registry refreshes the service list and perceives that the provider has gone offline for a node. This step does not exist for the Dubbo framework, but for Spring Cloud, its worst refresh time is 30 seconds. After the consumer's service list is updated, the offline node B will no longer be called. In the process from step 2 to step 6, if the registry is Eureka, it takes two minutes in the worst case; if it is Nacos, it takes 50 seconds in the worst case.

There may be problems with requests during this time, so various errors will appear when publishing.

After the above analysis, in the traditional publishing process, the client has an error reporting period when the server calls Caused by microservices that notify consumers to update the list of services provided.

Can the registry be bypassed and the service provider notify the service consumer directly? The answer is yes. SAE does two things. First, before the application is released, the service provider will actively log out the application from the service registry, and mark the application as offline, changing the logout of the original stop process stage to the logout of the preStop stage process.

When receiving a request from a service consumer, it will first process the request normally, and notify the service consumer that the node has been offline. After that, the consumer will immediately refresh its service list after receiving the notification. After that The service consumer will no longer send requests to the instance of service provider B1.

Through the above solution, the offline perception time is greatly shortened, and it can be quasi-real-time from the original minute level, ensuring that your application can achieve business loss when it is offline.

Running State Practice: Observables

For a running instance, this or that problem will occur during the running of the service. How to troubleshoot and solve it?

The premise of troubleshooting and solving is to have strong application monitoring and diagnosis capabilities. SAE integrates the cloud product ARMS, which allows the Java microservices running on it to see the application's call relationship topology, and can locate your MySQL slow service. The call stack of the method, and then locate the problem at the code level.

For example, if a request has a slow response and there is a problem with the business, it can locate which request, which service, and which line of code of the service has a problem, which can bring a lot of convenience to solving the problem. In general, we must first have the ability to monitor and alarm, in order to help us better diagnose problems in the process of service operation.

Customer case

Summarize

This article introduces the development of microservices in the serverless era and the relatively complex requirements encountered in the process. Faced with these, Alibaba Cloud's serverless application engine SAE has carried forward the concept of "Serverless" to the extreme, from the lowest level IaaS to the upper level The K8s, application PaaS, CICD, microservice suite integration, observable enhancement, etc. have all been hosted in "Serverless" mode, realizing SAE's complete solution for microservice scenarios.

In the future, SAE will continue to enhance its capabilities in the microservice scenario, make end-to-end solutions, and lower the threshold for developers to face microservice technologies, such as fault injection, full-link stress testing, and multi-language microservices. Services are, etc.; in the serverless scenario, the complexity is actually handed over to the platform by the user, so how to operate and maintain so many applications is also our core capability, and we will continue to invest and improve.