Shulou(Shulou.com)05/31 Report--

This article is to share with you about how to migrate the Web framework to Serverless, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Serverless, which is usually translated as "no service architecture", is a kind of software system design architecture idea and method, not a development framework or tool. His appearance is to make developers pay more attention to business development and hand over complicated operations and deployments to cloud vendors. Serverless consists of Faas and Baas. Faas provides a business computing environment for developers, and then interacts with the data and storage services provided by Baas to provide an experience consistent with traditional services. But because Faas is stateless and its operating environment is read-write limited, the most important thing is that it is event-based. Therefore, if traditional Web services want to migrate to Serverless, they need to carry out related modifications and special treatment, so the migration cost is essential. The following will specifically help you analyze how to Serverless traditional Web services.

Characteristics of traditional Web service

Web service definition:

Web service is a service-oriented architecture (SOA) technology, which provides services through the standard Web protocol to ensure that application services on different platforms can be interoperable.

In daily life, the service that has the most contact is based on the HTTP protocol. The client initiates the request, the server accepts the request, calculates and processes it, and then returns the response. The simple diagram is as follows:

Traditional Web service deployment process: you usually need to deploy the project code to the server, start the service process, listen to the relevant ports of the server, and then wait for the client request to return the processing result. And this service process is resident, even if there is no client request, it will consume the corresponding server resources.

Generally speaking, our service is composed of high-traffic and low-traffic scenarios alternately, but in order to consider high-traffic scenarios, we need to provide higher server configuration and multiple services for load balancing. This leads to a lot of extra idle resources when the service is in a low-traffic scenario, but the purchased resources need to be paid according to the high-traffic scenario, which is very uneconomical.

If our service can be automatically expanded in high-traffic scenarios and automatically reduced in low-traffic scenarios, and charged only when computing and processing responses, and free time does not take up any resources, then there is no need to charge?

The answer is Serverless.

Serverless applicable scenario

Two core features of Serverless have been mentioned above: on-demand use and charging and automatic capacity expansion. And in recent years, Serverless is more and more widely used, but it is not a silver bullet, any technology has its suitable and unsuitable scenarios. We should not pursue it blindly because of the popularity of a technology. Serverless has its limitations. Generally speaking, Serverless is suitable for the following scenarios:

Asynchronous concurrency, components can be deployed and extended independently

Response to sudden or unpredictable service usage

Stateless, computing time-consuming service

Request delay insensitive service

Businesses that need to develop iterations quickly

If your service does not meet the above conditions, I do not recommend migrating to Serverless.

How to migrate Web Framework to Serverless

If your service is any of the above mentioned scenarios, then you can try to migrate to Serverless.

Common Serverless HTTP service structure diagrams are as follows:

So how do we migrate Web services?

We know that Faas (cloud function) is triggered based on events, that is, when a cloud function is triggered, it receives a JSON structure, which is different from traditional Web requests, which is why additional modification work is needed. The work of the transformation is around how to transform the event JSON structure into a standard Web request.

So the core of Serverless-based Web services is the need to develop an adaptation layer to help us convert trigger events into standard Web requests.

The whole process flow chart is as follows:

Next, I'll show you how to develop an adaptation layer for the Express framework.

Development and implementation principle of Serverless Express adaptation layer

First, let's take a look at a standard cloud function structure:

Module.exports.handler = (event, context) = > {/ / do some culculation return res;}

Before we introduce how to develop an adaptation layer for Express, let's familiarize ourselves with the Express framework.

A simple Node.js Web service is as follows:

Const http = require ("http"); const server = http.createServer (function (req, res) {res.end ("helloword");}); server.listen (3000)

Express is a Web framework based on Node.js, and the core of Express is to generate a callback function through middleware and then provide it to the http.createServer () method.

The Express core architecture diagram is as follows:

From this, we can use the callback function generated by the Express framework as a parameter of http.createServer () to create a controllable HTTP Server, then convert the event object of the cloud function into a request object, initiate a HTTP request through the http.request () method, obtain the request response, and return it to the user, and we can achieve the desired result.

How to choose the monitoring mode of Node.js Server

For HTTP Server of Node.js, you can start the service by calling the server.listen () method, which supports a variety of parameter types. There are two main listening methods to start listening from a TCP port and from a UNIX Socket socket.

Server.listen (port [, hostname] [, backlog] [, callback]): start listening from a TCP port

Server.listen (path, [callback]): start listening from a UNIX Domain Socket

After the server is created, we can start the server as follows:

/ / receive connection server.listen from ports' 127.0.0.1 'and 3000 (3000,' 127.0.0.1 socket, () = > {}); / / listen for connection server.listen ('path/to/socket', () = > {}) from the path path where the UNIX socket resides

Whether it's TCP Socket or Unix Domain Socket, each Socket is unique. TCP Socket is described by IP and port, while Unix Domain Socket is described by file path.

TCP belongs to the protocol of the transport layer. When using TCP Socket to communicate, it needs to be parsed by the TCP/IP protocol of the transport layer.

Unix Domain Socket can be used for communication and transmission between different processes. When using Unix Domain Socket to communicate, it does not need to go through the transport layer, nor does it need to use TCP/IP protocol. Therefore, theoretically speaking, Unix Domain Socket has better transmission efficiency.

Therefore, when designing the startup service, the Unix Domain Socket mode is adopted in order to reduce the function execution time and save the cost.

About how Node.js implements IPC communication, I will not introduce it in detail here. Interested partners can study it in depth. Here is a simple example, nodejs-ipc.

Code implementation

The principle is generally clear, and our core implementation code requires the following three steps:

Listen to Unix Domain Socket through Node.js HTTP Server and start the service

Function createServer (requestListener, serverListenCallback) {const server = http.createServer (requestListener); server._socketPathSuffix = getRandomString (); server.on ("listening", () = > {server._isListening = true; if (serverListenCallback) serverListenCallback ();}); server.on ("close", () = > {server._isListening = false;}) .on ("error", (error) = > {/ /...}) Server.listen (`/ tmp/server-$ {server._socketPathSuffix} .sock`) return server;}

Convert a Serverless Event object to a Http request

Function forwardRequestToNodeServer (server, event, context, resolver) {try {const requestOptions = mapApiGatewayEventToHttpRequest (event, context, getSocketPath (server._socketPathSuffix),); / / make http request to node server const req = http.request (requestOptions, (response) = > forwardResponseToApiGateway (server, response, resolver)); if (event.body) {const body = getEventBody (event); req.write (body) } req .on ('error', (error) = > / /) .end ();} catch (error) {/ /. Return server;}}

Convert HTTP response to API gateway standard data structure

Function forwardResponseToApiGateway (server, response, resolver) {response .on ("data", (chunk) = > buf.push (chunk)) .on ("end", () = > {/ /. Resolver.succeed ({statusCode, body, headers, isBase64Encoded,});})

Finally, the handler of the function returns the asynchronous request.

Realized by tencent-serverless-http library

If you don't want to write the adaptation layer code by hand, you can use the tencent-serverless-http module directly.

It is easy to use, to create our Express application entry file sls.js:

Const express = require ("express"); const app = express (); / / Routesapp.get (`/`, (req, res) = > {res.send ({msg: `Hello Express`,}); module.exports = app

Then create the cloud function sl_handler.js file:

Const {createServer, proxy} = require ("tencent-serverless-http"); const app = require (". / app"); exports.handler = async (event, context) = > {const server = createServer (app); const result = await proxy (server, event, context, "PROMISE"). Promise;}

Next, package and deploy the business code and the dependency module to the cloud function (remember to specify the execution method as sl_handler.handler).

Other Node.js frameworks

In addition to the Express framework, other Node.js frameworks are basically similar, only need to exports a callback function of HTTP Server as required.

For example, Koa, after we get the initialized Koa application, we only need to use app.callback () as the parameter of the createServer () method, as shown below:

Const {createServer, proxy} = require ("tencent-serverless-http"); const app = require (". / app"); exports.handler = async (event, context) = > {/ / slightly different from Express here const server = createServer (app.callback ()); const result = await proxy (server, event, context, "PROMISE"). Promise;}; other language frameworks

For non-Node.js frameworks, such as Python's Flask framework, the principle is the same, and the core only needs to convert the Serverless Event object into a Http request. As the author is not familiar with other languages, I will not make an in-depth introduction here. Interested partners can go to the Github community to search, there are many corresponding solutions, or it is OK to try hand masturbation.

Rapid deployment of the Web framework using Serverless Components

At this point, I believe you already know how to migrate your Node.js framework to Serverless. But before that, we all handled it manually, and each time we had to create our own handler.js file, which was still not convenient enough.

For this reason, the open source community provides a set of excellent solution Serverless Component. Through components, we can easily deploy our framework code to the cloud after simple yaml file configuration.

For example, the Express framework mentioned above has corresponding components. We only need to create a serverless.yml configuration file in the project root directory:

Component: expressname: expressDemoinputs: src:. / region: ap-guangzhou runtime: Nodejs10.15 apigatewayConf: protocols:-https environment: release

Then, after the global installation of the serverless command npm install serverless-g, execute the deployment command:

$serverless deploy

Wait a few seconds before our Express application is successfully deployed to the cloud.

Note: the Serverless services in this article are all based on Tencent Cloud deployment.

Serverless Express components not only help us deploy Express applications quickly, but also provide real-time logging and cloud debugging capabilities.

Just execute the serverless dev command in the project directory, and the serverless command line tool will automatically listen for changes to the project business code and deploy it in real time, and we can debug the Express application by opening Chrome Devtools.

The above is how to migrate the Web framework to Serverless. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.