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

How to carry out Serverless development and application, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

AWS Serverless service is a serverless computing method for application engineers. The basic concept is that the infrastructure needed to run the service is managed by AWS. Engineers using AWS Serverless services can focus on customer-oriented logical service layer development without having to distract too much energy from infrastructure construction, management, expansion, and other tasks. At the core of AWS Serverless development is a computing service called Lambda.

Today we will focus on Lambda, introduce the different assembly modes of Lambda and various AWS services under different application scenarios, and discuss the development and deployment based on AWS Serverless.

What?

First of all, let's introduce what Serverless development is.

Different from the classical mode of development, compilation and deployment, using the AWS Serverless computing service Lambda, you only need to upload the source file, select the execution environment and execute, and you can get the running results. In this process, server deployment, runtime installation, compilation, and all are managed by the AWS Serverless computing platform. For developers, you only need to maintain the source code and the relevant configuration of the AWS Serverless execution environment.

Why?

Why choose Serverless?

For developers, using AWS Serverless services can save a lot of effort in managing the infrastructure and better focus on the development of business logic. As far as services are concerned, the service nature of AWS makes it very good to support flexible scaling and high concurrency scenarios. In addition, AWS Serverless-based development often has the advantages of rapid update and rapid deployment, and its charge-on-demand (on-demand) charging method also has advantages in reducing expenses in application scenarios such as lightweight deployment test environment and rapid verification.

How?

So, let's take a look at how to quickly assemble a simple Web Service using AWS Serverless-related services.

AWS Serverless provides a rich catalog of services to cover the needs of various functions. In addition to the core computing service Lambda, building Web Service services often needs to be combined with request ingress routing (API Gateway), persistent storage (S3), CDN (CloudFront), firewall (WAF), domain name resolution (Route 53) and other services. If you need to support the https protocol, you can also use Certificate Management Service (ACM) to implement it.

After the above services are assembled, a complete response request process will look like this:

The user request arrives at CloudFront via domain name resolution. After frequency control, IP filtering, header verification and other security guarantees are carried out by WAF, the request is forwarded to the core Lambda computing service through API Gateway routing.

Lambda processes the request, reads or stores data from persistent storage S3 if necessary, and finally returns the processing result to the user through API Gateway.

The logs generated by Lambda during logical calculation are output to the log management service provided by CloudWatch for future query. In addition, additional optimizations can be made, such as configuring CloudFront to load static resources directly from S3 to reduce time and computing overhead.

The startup mode of Lambda

In the case of Web Service, the execution of Lambda is Invoke by the API Gateway service. In fact, Lambda execution can be evoked in many ways. First of all, AWS's own services are often used in conjunction with Lambda, such as message publishing (SNS), message queuing (SQS), load balancer (ALB), state machine (Step Function) and so on.

Of course, you can also start the execution of the Lambda function through the SDK, Command Line or API interface. There are two execution modes: synchronous and asynchronous:

Synchronous mode call: you need to wait for the Lambda function to finish executing before the result is returned

Asynchronous mode call: it will be returned immediately after calling the execution interface of Lambda, and the execution result of the Lambda function needs to be obtained through other ways.

These two call modes can be used flexibly in different scenarios.

Message-driven example

Let's take another look at an example of using AWS Serverless services in a message-driven alarm processing system.

For example, we have a running system that sets the alarm message to be sent to the SNS service when an exception alarm occurs. SNS service is a Pub/Sub service of messages, which performs a basic fan-out publishing operation on alarm messages. On the one hand, it notifies the person in charge by phone and mail, on the other hand, it can automatically handle the alarm by calling Lambda,Lambda at the same time. This is the simplest alarm processing system.

Note here, however, that the SNS service itself does not store messages. As soon as SNS receives the message, it publishes the message. If there is no recipient of the message at this time, the message will be discarded. In addition, the message delivery is successful, that is, after the interface that invokes Lambda is successful, the message is discarded regardless of the processing result. If Lambda fails because of internal logic errors or external dependency system failures, it is impossible to retry messages that have been lost. To improve the reliability of message processing, it can be achieved by adding message queuing service (SQS) between SNS and Lambda.

SQS standard queue provides a disordered and reliable queue service that supports high concurrency and can store messages for up to 14 days. SNS publishes the message to SQS, and the message is first stored in SQS. At this point, set SQS to the event source (event source) of Lambda, and the message will be sent to Lambda for further processing. SQS call Lambda can be configured as a synchronous process, that is, if Lambda fails execution and returns an error, SQS does not delete the message from the queue. Messages that fail to be processed are temporarily marked as invisible, and after a hidden period, SQS will repeatedly call Lambda to process the message. This method can greatly improve the reliability of message processing.

But at the same time, the above methods also introduce the problem that a large number of abnormal messages accumulate and reduce the execution efficiency of normal messages. To solve this new problem, we can configure a Dead-Letter Queue for message queuing. If a message fails after several times of processing, it can be deleted from the original queue and transferred to the Dead-Letter Queue. The Dead-Letter Queue of a standard queue is essentially a standard queue, and you can also continue to carry out other subsequent processing of the "deprecated" messages in it.

Standard queues can better support high concurrency scenarios. A standard queue can accept a large number of messages at the same time and evoke a large number of Lambda instances for processing. Accordingly, the standard queuing service cannot guarantee the order in which messages are delivered, and the same message may be delivered repeatedly. Therefore, when using SQS standard queues, we need to consider the deduplication of messages, the idempotence of processing logic and so on. In addition to the standard queue, SQS has another first-in, first-out (FIFO) queue. FIFO sacrifices concurrency performance to ensure the sequence and uniqueness of message delivery. In different application scenarios, you can flexibly choose different queue types according to specific requirements.

Summary

AWS Serverless services have natural advantages in decoupling, elastic expansion, and cross-region deployment, but they also have limitations:

The upper limit of execution of a single Lambda is 15 minutes, which is less supportive for long hours.

The availability of services built on the Serverless architecture is highly dependent on AWS availability.

The development based on Serverless will lead to the cost of learning AWS system, and the difficulty of debugging and fault handling will become higher.

In the actual production activities, it is necessary to comprehensively consider the demand and balance the cost and effectiveness. In some application scenarios suitable for micro-services, especially in the implementation of short-state, temporary tasks, AWS Serverless-based development can become a very convenient development means.

After reading the above, have you mastered the method of how to develop and apply Serverless? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.