First, background
A little background.
Serverless cloud function: it is an abstraction of computing resources in the development of cloud computing. Based on the cloud computing platform, it provides the running environment of business programs for developers. Developers do not need to pay attention to the underlying resource allocation and expansion deployment, and all the necessary services for code execution are provided by the platform. SSR server rendering: In the early days, PHP JSP technology was commonly used to generate HTML on the server side. In recent years, under the evolution of JS homoformation, schemes for rendering by running front-end JS codes on the server side gradually emerged, such as isomer rendering of mainstream frameworks such as React and Vue.
If Serverless technology can be applied to SSR business scenarios, it will have the following advantages
- Theoretically, cloud service resources can be expanded infinitely, so there is no need to consider the impact of service volume on SSR machine performance
- Front-end students do not need to pay attention to the operation and maintenance, application and expansion of SSR machines
At present, NOW Live IVWEB team is gradually migrating SSR business to Tencent Cloud function platform, simplify deployment operation and maintenance costs, in response to the company’s call to research on the cloud.
Evolution of Serverless
J o is a front-end development, product told him one day page interface white during loading time is too long, poor experience, for the good of the front-end development boy he was not too difficult, he has 99 kinds of way to let the page load faster, so at once he will use the project team straight out of architecture along while access straight out, the next will be straight out of the service is deployed to the network, Then he was puzzled:
- How many machines and cores are required to deploy the direct outbound service?
- How is the volume of business? Is there any sudden request? Is there any expansion mechanism for the machine?
- How does nginx configuration change? If straight out fails, how to access the static page at the bottom of the pocket?
In a trance, he saw the PPT about the evolution of Serverless architecture from colleagues in Tencent Cloud….
From IaaS to FaaS
Before introducing SCF cloud functions, let’s take a look at the traditional IaaS and CLOUD FaaS business architectures:
The cloud function architecture looks like this:
J o both, are obtained under the business architecture based on the cloud function, developers need not concern business related configuration of base layer, can concentrate on the development of the business logic, base layer by platform is responsible for maintaining the iteration, as long as we can on the straight out of the service deployment of cloud solution deployment straight out of the business operations of the pain points.
App in Serverless architecture
The emergence of FaaS makes it easier to provide services to the cloud, but FaaS does not solve the problem of “public infrastructure services”, which are basic services such as object storage, KV storage, and message push. This problem finally falls to cloud service providers. Therefore, all cloud services on the market provide common basic services, which is called BaaS (Backend as a Service).
Serverless literally means Serverless, which does not mean that a server is not needed, but that developers do not need to pay attention to the server, which is provided by the platform maintenance, and developers only need to focus on the development of business logic.
Users do not need to pay attention to the underlying resources that support the operation of application services. They carry business logic in the form of “functions” and support public services in the form of “BaaS services”.
Considering the characteristics of direct outputting service, J believed that direct outputting service was very suitable for Serverless, so he immediately started the pre-research on the front-end cloud and did Serveless SSR service, which could avoid the trouble of operation and maintenance deployment and reduce the direct outputting cost!
SCF cloud function development
Ah J carefully studied Serverless Cloud Function (SCF) of Tencent Cloud and found that Cloud Function can split our business into finer granularity “functions”. The platform is responsible for the execution environment of functions, which developers do not need to pay attention to. The following is ah J’s understanding of Cloud Function execution.
Cloud function execution process
In the process of executing these “cloud functions”, the cloud platform is actually providing services externally. Usually, the Serverless function is used to “respond to HTTP requests”, that is, to trigger the execution of cloud functions through HTTP access events, as shown in the following figure:
The function is executed with input arguments, context, return values, and side effects, as shown in the figure below:
- Input parameter: The input parameter of the cloud function is the request header and request body in the HTTP request
- Context: Contains the ID of the function request, the environment variables of the function execution, and so on
- Side effects: Cloud function execution may invoke external services, such as databases, object storage, and data monitoring
- Retcode: 0, MSG: “success”}
Ah J also learned that after deploying the cloud function according to a certain configuration, the cloud platform will give you a ** “Invoke URL” **. By accessing this URL, you can trigger the corresponding cloud function to execute and get the result.
Iv. NGW Serverless isomorphic direct output scheme
When J started to develop Serverless direct output, he suddenly found that the Serverless environment was different from the original direct output environment. The original direct output environment was as follows:
- “Service mode is different” : the original plan is to direct the way TSW executes Koa App, which means that the original plan needs to listen on the port instead of running as a function, how to handle this?
- “CI Engineering” : How can cloud functions be engineered, packaged and released, and integrated into the team’s existing CI process?
- “Debugging scheme” : The original scheme can do local debugging, but how to do local debugging in the cloud function direct?
- “Link access” : after the cloud function is released, a URL will be obtained. Then how will this URL be connected to our business domain name?
- “Old business Migration” : Can the old business be seamlessly migrated to the cloud? Can we make the new straight out scheme compatible with the old straight out scheme?
Engineering packaging
In addition to front-end Webpack packaging, for Serverless cloud function platform, we need to do some more operations based on the original packaging product, the core of which is “package as ZIP upload to cloud function”, as shown in the following picture:
A CLI tool needs to be introduced here to package zip and upload cloud functions, because if a CI process needs to be accessed, it needs to be provided with imperative deployment for CI processes.
Homogeneous environment under Serverless
J considered that TSW (github.com/tencent/tsw) was used for the direct outputting scheme of the original business, but under Serverless, we could not move TSW into the cloud function for execution, but extracted the components we needed. Such as TSW AJAX HTTP, monitoring report, TSW Logger and other common components, because:
- It facilitates the seamless migration of old services to cloud functions and solves the operation and maintenance pain points of direct services
- TSW is very large, nearly 20 MB after compression, decompressed out much larger, not conducive to the performance of cloud functions
In addition, you need to implement TSW globally injected objects like Window. REQUEST Plug yourself, because older schemes rely on these as well.
“Flow” and “block”
The original solution required Koa to listen on the local port to provide services, while the cloud function input parameters are block, Koa input parameters are streaming, so we need to deal with the cloud function input parameters. J’s approach is to construct the HTTP IncomingMessage and ServerResponse dynamically according to the input parameters of the cloud function and then pass them to Koa App for direct rendering. Finally, the render result is obtained from the ServerResponse and constructed as the return value of the cloud function.
NGW acts as gateway forwarding
J decides to access NGW (Node Gateway) considering the availability of services and the pain of link access before:
NGW allows you to:
- Implementation of the bottom of the cloud logic: the function may crash, at this time go to the static page access machine
- Grayscale logic: In the process of directly connecting to the live network, some grayscale tests can be carried out through NGW configuration
- Link log collection: For a long time, it was difficult for the front-end to check specific link information. Now with NGW, everything is possible
Local debugging of cloud functions
Cloud function of stateless model makes it very easy for local debugging, we only need to in local constructor into the house and context can be directly straight out of debugging, J in the actual implementation is a Koa by local service listening on port, use the port request to construct into the house and the context, finally passed in the execution result, Return to the front-end display.
Isomorphism straight out process
In the end, AH J completed the Serverless direct outputting scheme, and the direct outputting process is shown in the figure below:
There are three core steps:
- Init: initializes the cloud function environment, accepts and processes the input parameters of the cloud function
- Koa: React Isomorphic service logic is represented in Koa App
- Clear: Clears the cloud function environment, processes Koa Response and returns a result
Performance bottlenecks and optimizations for cloud functions
Ah J conducted a pressure test immediately after completing the new direct output scheme, and found that with the increase of pressure, the packet receiving rate would drop off a cliff. Moreover, he also found that the execution of some functions took a long time. His colleagues who contacted the cloud function looked at the problem and found it was “cold start problem”. As can be seen from the architecture of cloud function, cloud function is not executed immediately after it is triggered. It requires a process of environment initialization, which is called cold startup. In other cases, the requested function is immediately followed by the next request, and the cloud function environment is not reinitialized, but directly started, which is called hot start.
The problem of cold start is not obvious in the case of low pressure, but in the case of high concurrency, it will have additional impact on packet back. Here, SCF colleagues have optimized: increase the minimum number of instances, reduce the cold start, the more the minimum instances, the more transient concurrency can be withstand. In addition, we also found the problem of memory. Here, we contacted SCF colleagues to optimize the Node memory model. After optimization, the problem of 4XX basically did not exist.
At this stage, AH J finally preliminarily completed the design and development of Serverless direct solution, and gradually applied it in the business.
Status quo and next steps
At present, NGW + Serverless SSR has been applied to many projects such as NOW live broadcast, mobile Q nearby, browser live broadcast and mobile Q group gift, etc. In the actual business development, the deployment, operation and maintenance workload of Node business has been reduced by more than 80%.
J’s next steps:
- Complete cloud function versioning
- Work with Webpack to further optimize the local direct debugging experience
- Cooperate with Tencent cloud colleagues to further optimize cloud function performance
- Improve the React Chunked streaming rendering scheme to further improve the loading speed of the first screen;
- Improve Node service cloud function, plan to do front-end BFF scheme
- Improve direct outgoing and link log collection to enhance service monitoring capabilities
Pay attention to [IVWEB community] public number to get the latest weekly articles, leading to the top of life!