CI CD Exploration of Serverless Architecture

1、 Background

The front-end application life cycle is divided into four stages: development, deployment, operation and maintenance, and monitoring.

Tools at the development level include Webpack for construction, Proxy for proxy and mock tools. In terms of deployment, there are more open source tools, such as Github Action, travis CI and SQL CI. The operation and maintenance system generally needs to be built by itself. Monitoring tools include Alibaba Cloud's ARMS monitoring, Sentry and DataDog.

The front-end mainly focuses on application and interaction, and the exploration of resources is relatively small.

In a modern GitOps front-end application platform, CICD is the soul of architecture. There are many solutions at the CICD level, but whether it is open source or commercial version, the demands of front-end developers can be summarized as follows:

L Free of operation and maintenance: there is no need to pay attention to resource reservation or capacity planning, and there is no need to pay attention to the construction failure caused by insufficient base resources.

Front-end friendly: the overall architecture is developed based on Javascript language, light and simple.

L Integrated: Front-end teams often have their own internal development, operation and maintenance platform, and hope that the platform can be well encapsulated, so as to quickly develop the internal front-end PaaS platform.

2、 Practice of Serverless (FaaS) architecture CICD

The CICD business process is as follows: publish a commit code in Github Repo, and execute the install, build, test, and deploy steps after the push. The whole process has the following three characteristics:

L Event-driven: all triggering processes are event-driven.

L Long-term running: Because of network problems or different scripts for each task, the execution time can be up to several hours, and the running time is uncertain.

L Traffic peaks and valleys: generally, the traffic is low at night, the code will be submitted during work hours, and there are traffic peaks.

FC asynchronous functions have the following characteristics:

L Free of operation and maintenance: there is no need to do capacity planning and resource scheduling, and there is no need to maintain the scheduling cluster. It is charged according to the number of calls. If no calls are generated, there is no charge.

L Compare with K8s: it has complete observability, while k8s may need to install observability related plug-ins; In terms of elasticity, FC's asynchronous function has a scaling speed of milliseconds, while k8s has a scaling speed of minutes; FC can process tens of thousands of tasks per second, while k8s only has hundreds.

L High-order capability: including task de-duplication, task flow control (task failure is automatically retried) and task execution result callback (all execution results can be delivered for subsequent processing).

The figure above shows a simple system flow. The developer pushes a piece of code to Git Repo, and then the system configures Webhook to trigger the FaaS function. The FaaS function will receive a traffic request. Traffic may not be a webhook, but may also be other request types. The important feature of Trigger and Worker functions is that all business logic or logic related to task processing belong to the nodeJS ecosystem.

A general product must have relevant specifications, including Trigger specification and Trigger specification.

Trigger specifications are divided into three types:

First, event types: event types include many events, which are implemented in a plug-in way. All events need to go through two processes:

L Authentication. Not everyone can call the HTTP interface, so authentication logic is required.

l Filter。 Github may trigger thousands of webhook requests every day, so you need to filter the interested webhooks through the filter.

Second, manual triggering. For example, if you need to manually trigger after a failure, or want to integrate the overall capabilities into the self-built system, you need to call the RustAPI directly.

Third, timing trigger. For example, regular patrol inspection and regular end-to-end testing.

The biggest advantage of the Task specification is the customization of step, which provides shell, npm module and goggle/zx. Goggle/zx refers to the ability to write scripts in Javascript.

Secondly, template syntax is supported. For example, it is necessary to determine whether the current step is executed or suspended, and whether the current task affects the call of other tasks. All the above capabilities are based on npm packages.

After the event arrives, the Trigger function will call some capabilities in the npm package trigger. Then execute the worker function, call the task method above, and the log information will be generated at the same time. Log information is an interface interface that can be stored in OSS, NAS or SLS. Finally, the log information will be processed after Consul.

There is also persistent storage capacity, namely Ots, which is Serverless DB and is charged by the number of calls.

Function capability is the core of design.

The Trigger function is an API server, an exposed HTTP request, or a controller function, which controls the overall process operation. It is mainly responsible for the following tasks:

① Authentication: responsible for blocking permissions. For example, if the verification fails, it will prompt for failure. You can view the failed WebHook information in WebHook.

② Traffic filtering: For example, only receive Push traffic and filter out traffic such as issue.

③ Gateway capability: do routing distribution.

At the same time, Trigger is a single instance and multiple concurrent function. Thousands of requests will be triggered in one minute. If each request is used to align function instances, it will cause a huge waste of resources. However, multiple concurrent single instances means that multiple requests can be processed in one POD, which can greatly save resources. In addition, the Trigger function is only used for simple authentication and traffic filtering. There is no excessive calculation and no need to interact with the database, so it is very lightweight.

The feature of the Worker function is that it needs to run for a long time, so it needs to support high-level capabilities such as pause and cancel, and it can also filter traffic.

From the characteristics of the function, first of all, it is an event function, that is, it cannot be called externally through the HTTP interface; Second, it is an asynchronous function; Third, it is the Custom Runtime function, which can switch languages and versions with one click without unnecessary maintenance. In addition, the Worker function naturally has the ability of image acceleration to ensure the pulling speed.

There are three core Npm components:

① Trigger: responsible for the parse Trigger spec.

② Engine: responsible for the parse task spec.

③ Core: provides a series of methods, such as log methods, parsing yaml, environment variables, and secret.

3、 Summary and outlook

The pipeline capability will be implemented later. For example, multiple task choreography, in which the choreography capability includes serial execution and parallel execution. The characteristics of serial execution and parallel execution are that they cannot be suspended. The ability to suspend and resume tasks needs to be realized through third-party mechanisms, such as Redis message queue or MQ message queue. It also supports cache caching to reduce network overhead.

The ability to deploy and switch between multiple regions can switch the worker function to different regions according to flexible configuration rules, which solves the problem that network congestion often occurs when accessing GitHub in China, resulting in task failure.

The log supports several storage methods:

First, file storage NAS solution. The advantage is that it can display real-time logs, continuously append them in real time, and well support real-time scrolling, real-time refreshing and other scenarios. The disadvantage is that the file has no life cycle, and it needs to create a new auxiliary function to clean the log; In addition, when QPS concurrency is high, there will be a write performance bottleneck.

Second, SLS scheme based on log system. SLS is very closely combined with function calculation, so it is extremely convenient to use. It supports reading stream logs from stdout streams. The logs also have a complete life cycle. The disadvantage is that the price is expensive.

Third, based on OSS object storage scheme. The advantages are cheap and easy to use, because OSS is a rest interface with a complete life cycle; The disadvantage is that it cannot be appended like a file, so it cannot support real-time logs. The current complete log can only be obtained after the task is executed.

Q&A：

Q: Deploy front-end code to server through CICD. Do you need a back-end?

A: Yes. The server of the entire CICD system is deployed in FC, so the back-end is definitely required. It can be understood here that the front-end completes the back-end work. The business logic (application) is maintained in various warehouses, and the function can be triggered by defining yaml.

Q: There is a switch between versions in Demo, from v1 to v2 and then to v1. So where does the version reside?

A: There is no concept of version. All versions come from git and can be rolled back to any commit, only the concept of git commit

Q: New features have been developed and updated to the git repository. If there are bugs that need to be rolled back, does the git warehouse also need to be rolled back?

A: The Git warehouse does not need to be rolled back. Git records all historical behaviors, so you can get the commit through git fetch. In addition, if it is a production process, it is recommended to deploy through tag to avoid inconsistency between the deployment status and the git warehouse.