AutoNavi Serverless implementation

Why choose Serverless?

In the early days, Golder put all resources and logic on the end side, so it is a heavy-end app. It depends on the manufacturer on the end, and the release will be involved in the update. The business changes quickly, but the iteration is slow and the iteration life cycle is long, which leads to the loss of user experience. And when the code accumulation is large, the test cost is very high. Therefore, a small change will cause many big changes. Therefore, client slimming is imminent.

In addition, low power and cloud integration are also the general trend. Finally, in order to accelerate the iteration, strengthen the user experience, and make travel better, we decided to adjust the architecture.

The first feature of Serverless is the unified environment. The early containerization was hard isolation, and the problem caused by hard isolation was that the unification of the environment needed to be realized through templates, which took a long time to build, so it could not be changed in a short time. In addition, multiple sets of templates need to be maintained, and the operation and maintenance costs are very high.

In addition, in the case of unified environment, how to maintain the underlying version of the dependent system also needs to be solved. The implementation of the container is relatively simple, but the process is relatively complex. It depends on security level isolation, CG group, and NameSpace. It still needs to build its own environment.

Docker realizes soft isolation. With Docker, you can move the online environment to the local area through orchestration, and bring the online environment to the local area through IDE and Docker mounting, so as to achieve environmental unification. The benefits of the unified environment are that the operation and maintenance are safer and more convenient, and the container can be directly pulled up through the image. At the same time, mirroring can also bring elastic scalability.

In addition, Serverless can realize pay-as-you-go according to the tidal flow characteristics of the business, saving costs.

The diversity of Serverless architecture is also consistent with our business needs. It provides BaaS, FaaS (functions with smaller granularity, only representing the points in the request), Sff (serverless for front), and Bff (backend for front). SFF and Bff mainly solve the problem of front-end traffic backend.

👉 Function calculation FC: https://www.aliyun.com/product/fc?

We distinguish the end from the cloud, and put the end computing and functions on the cloud to become cloud integration. In the early development stage, the gateway layer is basically API, Gateway and other aggregation modes. The interface is aggregated together through routing and then the content is returned. With more and more services, a small change may cause great problems to the link, and the test cost is also high.

Now, we have replaced this layer with Serverless, running the FaaS function from the end request to the cloud, disassembling the single point and running it, which can automatically expand and shrink according to the actual traffic, without worrying about offline or changing the service status.

In the future, we will put a lot of computing on the cloud, making the client smaller and faster, not only realizing the integration of end and cloud, but also realizing the same frequency of production and research, and accelerating the product iteration speed.

After solving the architecture problem, we still need to face the problem of high operation and maintenance costs. The operation and maintenance of the Serverless architecture is only for containers and functions. The operation and maintenance of each scenario and process still need to be built through a systematic mode, and a perfect CICD is needed.

CICD solves observability and isolation. Observability is mainly used to quickly find problems, including log collection, eagle eye, monitoring, etc. With the upgrading of the architecture, its granularity becomes smaller and smaller, the cost of service governance and environmental governance becomes higher and higher, and the importance of observability becomes increasingly prominent.

In terms of code management, the underlying mechanism ensures that tag and code management can go through different processes. Publish to the environment through code management, verify from the perspective of environment isolation, and then control the security through permission means after verification, and realize the security mode through environment isolation.

The perfect CICD ensures the efficient iteration of the product and reduces the cost of trial and error.

With a complete CICD, you can design the platform architecture of the general FaaS. Different teams call FaaS to each other. SFF solves the API aggregation problem by calling FaaS on the front end to make requests. The business scenario goes down to the gateway and the end FaaS (write logic), and then down to the business layer. The business layer calls and fills with each other, and finally to the business FaaS.

The cycle of FaaS is constrained by the Runtime. This set of Runtime design can realize hourly FaaS development and deployment.

The architecture is divided into four layers. The top layer is User Faas, and its logic can be superimposed through Runtime; The second layer is the FaaS SDK. There should be a unified standard for uplink traffic and downlink traffic, otherwise it will lead to user instability; The third layer is Runtime, which implements and encapsulates many protocols. For example, the long link protocol is used as an external proxy for middleware. When using it, you only need to introduce Runtime; The bottom layer is the FC function engine. The biggest disadvantage of FaaS is that it needs to load status, instance, etc. during cold start, which will take a lot of time, and some states can be masked. Based on this, FC has optimized it, and can reserve instances to achieve second start.

The above process can be understood as having a web server entry to implement functions, and then through platform scheduling and CICD process release, finally achieving efficient iteration.

The stability guarantee is responsible for ensuring the function maintenance under daily conditions. The online three axes are grayscale, monitor and rollback. Serverless has a light architecture and can control its online process through version. For example, the versions before and after optimization are version1 and version2, which can be shunted through different traffic mechanisms. The versions can be added at any time, and the old versions can still run normally when adding versions.

In terms of observability, problems can be discovered through complete log links, and intelligent means are also provided to help find business problems.

Reserved instances solve the cold start problem and avoid the impact of cold start on the request duration. A complete process-based link troubleshooting mechanism means that you can label the log, quickly mine problems, locate problems, and promote security in the process through the log.

The landing scenarios of Serverless in Gaode include, but are not limited to, the above four, which can ensure that it can bounce up and develop quickly, and the card can be quickly online and offline through configuration.

The ultimate benefit of FaaS is to reduce costs and improve efficiency, mainly reflected in the following three aspects:

• Development efficiency improvement: Bff&runtime accelerates development and quickly reads iterative business.

• Operation and maintenance efficiency: complete life cycle, complete flexibility.

• Cost reduction: tidal flow, on demand.

Q&A：

Q: When using Serverless to develop related functions, the granularity of functions is particularly fine. For example, if a user requests to come in, there may be more than a dozen serverless calls on the back end, and the call delay between serverless is relatively large. How to optimize?

A: Use asynchronous request mode, then summarize the tuples, and then parse the tuples. It depends on the maximum short board. On the tool, we implement timeout, quickly intercept unnecessary long time requests in asynchronous and timeout ways, summarize them and finally return them to the end. For business reasons, we did not directly fuse the long time request.

Q: The function itself executes faster, but the call between functions takes longer. How to solve this problem?

A: It needs to be solved by the platform. At present, we regard it as a normal request and have not optimized the problem. Previously, we have optimized another mode, relying on the routing of functions provided by the platform, and made great optimization in resource reuse and scheduling. In addition, when calling the platform, the protocol communication between the platform and the function is also particularly important, such as how to communicate when the connection is slow, and how to communicate when the sliding window is full. GRPC can ensure that it will not be too slow at a certain time, but the initial stage of startup still takes a long time.