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

This article introduces the relevant knowledge of "Serverless platform Construction example Analysis". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Why did Why- Gaud do Serverless?

Why does Gaud want to do Serverless? The background reason is that Gao de FY21 launched a client-side cloud project in the fiscal year. The main purpose of the client-side cloud project is to improve the iterative efficiency of client-side development.

In the past, the client business logic is on the end, and the change of product requirements can only be released by the client version, while the client version needs to go through various testing processes and grayscale processes to solve the client crash and other problems. The current pace is one version a month.

After the client goes to the cloud, some changeable business logic is put on the cloud. New product requirements are developed in the cloud, without the need for monthly release, which speeds up the iterative efficiency of demand development, and is one step closer to the ideal goal of the same frequency of production and research. It is because Gaode has also made some efforts to optimize the direction of the same frequency of production and research, but we hope that the integrated development of cloud can be one of the most effective technical assistance).

1.1 goal: client development model-end cloud as a whole

Although the development model has changed from the previous end development to the current cloud + end development, the developers should still be the students who were originally responsible for the corresponding business, but as we all know, there are obvious differences between server-side development and client-side development. client-side development is oriented to stand-alone mode, while server-side development is usually a cluster mode, which requires consideration of various complex issues such as distributed system coordination, load balancing, failover degradation and so on. If you use the traditional server-side model to develop, this transition risk will be greater.

Faas solves this problem very well. We combine the existing xbus framework of Gaud client (a framework for local service registration and invocation on the client) to extend the xbus-cloud component, so that the development on the cloud is the same as the development on the end, the goal is to run a set of code and run in two places, and a set of business code can run not only on the client but also on the server.

Gaud client mainly has three terminals: IOS, android, car machine (Linux-like operating system). There are two main languages: C++ and Node.js. Traditional map functions: such as map display, navigation path display, navigation broadcast and so on, due to the need to span three ends, using the C++ language to develop. Some map application functions based on map navigation, such as pre-line / post-line cards, recommended destinations, etc., are mainly developed by Node.js.

Node.js Faas runtime was developed by the front-end team of Amoy Department in FY20 fiscal year. For the Gaud client-side cloud project, the Node.js part uses the existing Amoy Node.js runtime to access the group's Faas platform to complete some of the Node.js business on the cloud. During the National Day holiday in 2020, Gaode's National Day travel festival business was well supported.

C++ Faas does not have an existing solution, so we decided to add on top of the group's infrastructure and build a new C++ Faas basic platform to facilitate the cloud launch of Gaode clients.

1.1.1 Best practice key for all-in-one Cloud: interface abstraction between client and Faas

The logic of the original client is moved to the Faas server, or some of the new requirements are developed on the Faas server. The key point here is: the interface protocol definition between the client and Faas, that is, the API definition of Faas. A good API definition is not only good for the maintainability of the system, but also important for the iterative development of the subsequent supporting business. For a good definition of API, please refer to Gu Pu's document: "thinking about API design best practices."

Ideally: the client makes a browser that parses the result data returned by Faas. Once the browser protocol is defined, it will not change very often. As you can see, IE and Chrome are rarely updated. Of course, our browser will be more complicated, our browser is a map browser. How to verify the definition of the interface between the client and Faas can be seen in subsequent product requirements iterations. If some product requirements iterations only need to be completed on Faas without any modifications on the client, then the interface abstraction is successful.

1.2 improvement of BFF layer development

When it comes to Gaud, the first thing that comes to mind is its tool attribute: Gaud is a navigation tool (this statement is no longer accurate, because Gaud has been making a tool-to-platform transition in recent years, and we want to be omnipotent. Gaud's trading business is on the rise, and Gaud's taxi-hailing, ticket, hotel and other businesses are developing rapidly.

For Gaud Navigation, compared with other businesses of the group (such as e-commerce), a large number of read-only scenarios is a major technical feature of Gaud business. In these read-only scenarios, a large number of requirements are BFF (Backend For Frontend) type read-only scenarios. Why would you say that? Because the core functions of navigation, such as routing, traffic, eta and so on, are relatively stable, the main work of this part is to continuously optimize the algorithm to make Gaud's traffic more accurate and the calculated path better. These core functions are relatively stable in interface and function, while the front-end requirements are changeable, such as adding width limit pier tips on a path.

Faas is especially suitable for BFF layer development, calling various Baas services with relatively stable back end on Faas, and Faas services to do data and invocation logic encapsulation, rapid development and release. In the industry, the most frequently used scenario in Faas is the BFF scenario (another name is SFF scenario, service for frontend).

1.3 Serverless is the high-level language of the cloud era

FY21, Gaode is the first BU in the group to be fully launched to the cloud. Although Gaode has been fully launched to the cloud, this is not the end of the cloud era. At present, it is mainly a comprehensive pouch and cloud, and the container has been standardized. It can fully enjoy the cloud dividend in terms of scale and resource utilization, but the business development model is basically the same as before, still a large-scale distributed system. For the R & D model, we have not yet enjoyed the dividend of the cloud, which can be compared to that we are now using assembly language to write services running on the cloud. And Serverless, cloud native can be understood as the high-level language of the cloud era, really achieve Cloud as a computer, only need to focus on business development, do not need to consider the complexity of large-scale distributed systems.

1.4 Go-Faas complements Go language ecology

As mentioned earlier, because of the client-side cloud project, we have developed C++ Faas Runtime by adding on the Aliyun FC (function Computing) team. Not only that, we also developed Go-Faas, why do we do Go-Faas? Here is also a brief introduction to the background. The peak qps of the Go part of Gaode server has exceeded one million. Gaud has made up the Go client of Ali middleware and co-built it with the group middleware department. The observability and automated testing system is also basically perfect. At present, the ecology of Go has been basically improved. After completing the Go-Faas, we can write Baas services in Go and Faas services in Go. Different service implementations are used in different business scenarios. Go-Faas is mainly used in the BFF scenarios mentioned above.

2. Introduction of How- technical solution: add 2.1 overall technical architecture on top of the existing infrastructure of the group

The above talked about why we want to do this thing, and then we will talk about how we do it, how to achieve it, and what the specific technical solution is.

In line with the idea of addition based on the existing infrastructure and middleware of the group, we worked with CSE and Aliyun FC function computing team to develop C++ Faas Runtime and Go Faas Runtime. The technical architecture of the whole and the group is shown in the following figure, which is mainly divided into three parts: the R & D state, the operation state and the operation state.

2.1.1 running state

First of all, in the running state, business traffic comes in from our gateway, is called to FC API Server, and forwarded to C++/Go Faas Runtime,runtime to complete the function in the user function. The architecture of runtime is described in detail in the next section of this article.

Together with runtime container, various side car,side car such as monitoring, log and Dapr are deployed to complete various log collection and reporting functions, and dapr side car to complete the function of calling group middleware.

In addition, dapr is still in the pilot stage, calling middleware is mainly completed through Broker and various middleware proxy, and middleware calls such as HSF, Tair, metaq, diamond and other middleware proxy.

Finally, the Autoscaling module manages the expansion and expansion of function instances to achieve the purpose of automatic expansion and expansion of the function. There are various strategies for scheduling here, including scheduling according to request concurrency and CPU utilization of function instances. You can also set the number of reserved instances in advance to avoid the cold start problem after scaling down to 0.

The underlying call is the capability of the group ASI, and ASI can be simply understood as the group's K8S + sigma (group scheduling system). The final deployment is that FC calls ASI to complete the deployment of function instances. The smallest unit of deployment is the pod in the figure above, and a pod contains runtime container and sidecar set container.

2.1.2 R & D state

Let's take a look at the R & D state, the running state determines how the function runs, and the R & D state focuses on the development experience of the function, and how to easily let developers develop, debug, deploy and test a function.

C++ Faas has a difficult cross-platform problem. There are some dependency libraries in C++ Faas runtime, which are not as easy to manage as Java dependency libraries. This dependent library installation is more troublesome, Faas scaffolding is to solve this problem, call scaffolding, one-click generation of C++ Faas sample project, install a variety of dependent packages. In order to facilitate local debug, a C++ Faas Runtime Boot module is developed. The function runtime startup entry is in the boot module, and the boot module integrates runtime and user Faas functions. Runtime can be used to do debug single-step debugging.

In cooperation with the group Aone team, the release of the function is integrated into the Aone environment, and you can easily release Go or C++ Faas,Aone on Aone. It also integrates the function of one-click generation of example code base.

The compilation of C++ and Go Faas depends on the corresponding compilation environment. Aone provides a custom compilation image. We upload the compilation image to the group's public image library. When the function is compiled, specify the corresponding compilation image in the function code base, and install Faas's dependent library, SDK, and so on.

2.1.3 Operation and maintenance state

Finally, let's take a look at the operation and maintenance monitoring of the function. Hawkeye and sunfire log collection features are integrated in runtime, and these logs are written in runtime. After these logs are collected to Hawkeye or sunfire monitoring platform through agent in sidecar (FC is collected through SLS), you can use the group's existing monitoring platform to monitor Faas, and you can also access the group's GOC alarm platform.

2.2 C++/Go Faas Runtime architecture

The above is an overall architecture integrated with Aone, FC/CSE and ASI. Runtime is part of this overall architecture. The following details describe the architecture of Runtime and how Runtime is designed and implemented.

The top part of the user Faas code only needs to rely on Faas SDK, and users only need to implement the Function interface in Faas SDK to write their own Faas. Then if you need to call the external system, you can call it through the Http Client in SDK. If you want to call the external middleware, you can call the middleware through the Diamond/Tair/HSF/metaq Client in SDK. These interfaces in SDK shield the complexity of the underlying implementation, users do not need to care about how these calls are finally implemented, do not need to care about the specific implementation of runtime.

The SDK layer is the Function definition mentioned above and the interface definition of various middleware calls. The SDK code is developed for Faas users. SDK is relatively light and thin, mainly interface definition, does not include the specific implementation. There are two ways to implement calling middleware in Runtime.

Down there is the overall architecture of Runtime. Starter is the startup module of runtime. After startup, runtime itself is a Server. When starting, it starts the request and management listening mode according to the configuration of the Function Config module to start runtime,runtime after startup.

Next is the Service layer, which implements the interface for calling middleware defined in SDK, including RSocket and dapr. RSocket calls middleware through RSocket broker mode, dapr (distributed application runtime) is integrated in runtime, and calling middleware can also be called through dapr. In the early dapr pilot phase, if the middleware call through dapr fails, it will be degraded to rsocket to call the middleware.

Then there is the protocol layer of rsocket, which encapsulates the various metadata protocols that call rsocket. The dapr call is called through the grpc way.

The bottom layer is the integration of rsocket and dapr.

Rsocket call also involves the selection of broker, upstream module to manage broker cluster, broker registration anti-registration, keepalive check, etc., LoadBalance module to achieve broker load balance selection and event management, connection management, reconnection and so on.

Finally, the metrics module in runtime is responsible for the access of Hawkeye trace, intercepts the time-consuming of Faas link through filter mode, and outputs Hawkeye log. Print sunfire log for sidecar to collect. The following figure shows an actual business sunfire monitoring interface:

2.2.1 Dapr

The dapr architecture is shown in the following figure. For more information, please refer to the official documentation.

Previously, calling middleware in runtime is called through rsocket, here rsocket broker will have a centralization problem. In order to solve the problem of decentralization of outgoing traffic, dapr architecture is introduced in cooperation with the group middleware team. It's just that dapr is integrated at the runtime level, which is unaware of the user Faas, and there is no need to care whether the calling middleware is called through rsocket or dapr. After the runtime calls the middleware to switch to dapr, the user Faas does not need to make any changes.

3. How to access How- service to Serverless

As mentioned earlier, the access is unified on the Aone. Provides access documents for C++ Faas/Go Faas. The example code base for functions is provided, and the code base has examples of various scenarios, including code examples for calling various middleware of the group. The access of C++ Faas/Go Faas is developed by the whole group. At present, there are some BU other than Gaode, which have landed C++ / Go Faas in their own business. Node.js Faas uses the runtime and template provided by Taobao to access, and Java Faas uses the runtime and template provided by Aliyun FC to access.

3.1 access specification-stability three axes: monitoring, grayscale, rollback

In view of the stability problems that people may be worried about in the new landing technology, our magic weapon is the stability of Ali Group: it can be monitored, grayscale and rollable. Establish a Faas link guarantee group, connect all relevant business parties and basic platforms upstream and downstream, and work together to respond to online alarm and rapid investigation within 1 minute according to the group's 1-5-10 requirements; deal with it within 5 minutes; recover within 10 minutes.

In order to standardize the access process and avoid online failures caused by mistakes, we have developed Faas access specifications and checkList to help business parties use Faas quickly.

Can be monitored, grayscale, rollback is a mandatory requirement, in addition, the business side can be downgraded even better. Our cloud business on C++ client is ready to be degraded at the beginning of the pilot phase. If the call to Faas fails, this call will be automatically degraded to local call. Basically lossless to the client function, but will increase some response delay, in addition, the version of this function on the client may be a little older than the server, but the function is forward compatible and basically does not affect the use of the client.

4. Now- our current situation 4.1 basic platform construction

Go/C++ Faas Runtime development is completed, docking with FC-Ginkgo/CSE and Aone is completed, and a stable version 1.0 has been released.

A lot of stability construction, elegant offline, performance optimization, C compiler optimization have been done, and the compilation method provided by the compiler optimization team of Aliyun basic Software Department has been used to optimize the compilation of C++ Faas.

C++/Go Faas is connected to Hawkeye, sunfire monitoring is completed, and the function is observable.

The pooling function is completed with the ability of second-level flexibility. Pooled runtime images are connected to CSE, and the time for expanding a new instance is changed from minutes to seconds.

4.2 the landing of Gaud's Serverless business

C++ Faas and Go Faas as well as Node.js Faas have a large number of applications in Gaud. To give a few examples:

The first two pictures above are services developed by C++ Faas: long-distance weather and searching along the way. The last two screenshots are business developed by Go-Faas: navigation tips and footprint map.

Gaud is the largest Serverless application landing BU in Ali Group, and the Serverless application has been landed, with a daily peak of more than 100, 000 qps.

4.3 Major benefits

What are the benefits after Gaud landed the largest Serverless application in the group?

First of all, the first and most important benefit is: development efficiency. Our end-cloud all-in-one component based on Serverless helps the client to go to the cloud, relieves the dependence on real-time client distribution, and improves the iterative efficiency of client development. The BFF layer developed based on Serverless improves the iterative efficiency of BFF scenario development.

The second benefit is to improve the efficiency of operation and maintenance. Using Serverless's automatic flexible expansion and scaling technology, Gaode is more comfortable with various travel peaks. For example, during the annual travel peak of the National Day holiday, May Day, Qingming Festival and Spring Festival, it is no longer necessary for operation and maintenance or business development students to expand capacity in advance before the festival and reduce capacity after the festival. The characteristics of Gaode's business peak are also different from the second-kill scenarios of e-commerce. The traffic at the peak of travel does not suddenly rise within 1 second. We currently use pooling technology to achieve second-level flexibility, which can fully meet the needs of this business scenario of Gaode.

The third benefit is to reduce costs. Gaode has the characteristics of large flow during the day and low flow at night, and there is a great difference between peak and trough values, and there is an obvious distinction between time periods. By using the automatic capacity reduction technology of Serverless when the traffic is low and peak at night, the cost of server resources is greatly reduced.

5. Next- follow-up plan

FC in-projectile function calculation uses optimization to work with the FC team to continuously optimize the performance, stability and experience of in-missile function calculation. Use the rich high-traffic business scenarios within the group to constantly polish the C++/Go Faas Runtime and eventually export it to the public cloud, more enterprises in the wave of digital transformation of Pratt & Whitney.

Dapr landed, solved the problem of decentralization of outcoming traffic, gradually launched some C++/Go Faas, and used Dapr to call group middleware.

Faas chaos engineering, fault drill, escape ability building. Faas will also participate in our BU fault drill in the new fiscal year to solve the problems found during the exercise one by one.

Access edge computing. In a scenario where end-to-end cloud is integrated, Faas + edge computing can provide lower latency and better user experience.

This is the end of the content of "Serverless platform Construction example Analysis". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.