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

This article will explain in detail how to understand the Serverless architecture model, the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

What is the Serverless architecture? According to CNCF's definition of Serverless computing, Serverless architecture should be a design that uses FaaS (function as a service) and BaaS (back-end service) services to solve problems. This definition makes our understanding of Serverless a little clearer, and may also cause some confusion and controversy.

With the development of demand and technology, some Serverless computing services other than FaaS have emerged in the industry, such as Google Cloud Run, application-oriented Serverless application engine service and Serverless K8s launched by Aliyun. These services also provide flexible scalability and pay-per-use charging model, with the form of Serverless services, which can be said to further expand the camp of Serverless computing.

In order to eliminate the impact of cold start, FaaS services such as Aliyun's function calculation and AWS's Lambda have introduced reservation features, which have become less "pay-per-use".

Some Serverful-based back-end services have also launched Serverless products, such as AWS Serverless Aurora and Aliyun Serverless HBase services.

From this point of view, the line of Serverless is a little blurred, and many cloud services are evolving towards Serverless. How does a vague thing guide us to solve business problems? Serverless has a fundamental concept that has not changed, that is, to maximize the focus of users on business logic, other features, such as not caring about the server, automatic flexibility, pay-as-you-use, all serve for the realization of this concept.

Ben Kehoe, a famous Serverless practitioner, describes Serverless's native mind as we can experience it when we think about what to do in business:

What is my business?

Will doing this make my business stand out?

If not, why should I do this instead of letting someone else solve the problem?

There is no need to solve technical problems before solving business problems.

In the practice of Serverless architecture, the most important mind is not to choose which popular services and technologies and which technical problems to overcome, but to keep in mind the business logic at all times, so that it is easier for us to choose the right technologies and services and make clear how to design the application architecture. People's energy is limited, the organization's resources are limited, the concept of Serverless can enable us to better use limited resources to solve the problems that really need to be solved, it is precisely because we do less things, and instead let others do these things, we can do more in business.

Next we introduce some common scenarios and explore how to use the Serverless architecture to support these scenarios. We will mainly use computing, storage and message communication technologies to design the architecture, and measure the advantages and disadvantages of the architecture from the perspectives of maintainability, security, reliability, scalability and cost. To make this discussion less abstract, we will use some specific services as a reference, but the ideas of these architectures are generic and can be implemented with other similar products.

Static Web site

If we want to do an information display website, the demand is very simple, just like the early Chinese Yellow pages, the information is rarely updated, there are probably the following main choices:

Buy a server and host it in the IDC computer room and run the site.

Go to the cloud manufacturer to buy a CVM to run the site, and buy load balancing services and multiple servers in order to solve the problem of high availability.

Use static site mode, directly supported by object storage services (such as OSS), and use CDN back-to-origin OSS.

These three ways go down from the cloud to the cloud, from the management server to the non-management server, namely Serverless. What changes have this series of changes brought to users? The first two schemes require budget, expansion, high availability, and self-monitoring, which are not what Mr. Ma wanted at that time. He just wants to show information and let the world understand China. This is his business logic. Serverless is such an idea that maximizes people's focus on business logic. The third way is to use the Serverless architecture to build a static site, which has advantages over other schemes, such as:

Maintainability: there is no need to manage servers, such as operating system security patch upgrades, failure upgrades, and high availability, all of which are helped by cloud services (OSS,CDN)

Scalability: there is no need to estimate resources and consider future expansion, because OSS itself is resilient, and the use of CDN makes the system less latency, lower cost, and higher availability

Cost: paid according to the resources actually used, including storage fees and request fees, no request fees are charged when there is no request

Security: such a system can not even see the server, does not need to log in through SSH, and DDoS attacks are handed over to cloud services to solve.

Monomer and micro-service applications

Static pages and sites are suitable for scenarios with less content and less frequent updates, whereas dynamic sites are needed. For example, the product page of Taobao, it is unrealistic to use static page to manage commodity information. How to return the results dynamically according to the user's request? Let's look at two common solutions:

Web single application: all the application logic is completed in one application. Combined with database, this hierarchical architecture can quickly implement some applications with low complexity.

Micro-service applications: with the development of business, more functions, more visits and a larger team, it is generally necessary to split the logic in a single application into multiple execution units. for example, comment information, sale information, delivery information on the product page, etc., can correspond to a separate micro service. The advantage of this architecture is that each unit is highly autonomous and easy to develop (such as using different technologies), deploy, and extend. However, this architecture also introduces some problems of distributed systems, such as load balancing of inter-service communication, failure handling and so on.

Organizations of different stages and sizes can choose their own ways to solve the primary business problems they face. Taobao must not be accepted because of which technical architecture it uses. But no matter which architecture we choose, the Serverless native mind mentioned above will help us to focus on our business. For example:

Whether you need to purchase your own server to install the database, achieve high availability, manage backups, upgrade versions, etc., or can you leave these matters to managed services such as RDS; can use Serverless database services such as table storage and Serverless HBase to achieve flexible capacity expansion and payment according to use

Whether a single application needs to purchase its own server to run, or it can be handed over to managed services, such as function computing and Serverless application engine

Whether lightweight microservices can be implemented through functions, depending on the capabilities provided by function computing, such as load balancing, automatic scaling, pay-on-demand, log collection, system monitoring and so on.

Whether micro-service applications based on Spring Cloud, Dubbo, HSF and so on need to purchase their own servers to deploy applications, manage service discovery, load balancing, auto scaling, circuit breakers, system monitoring, etc., or they can hand over these tasks to services such as Serverless application engine.

The architecture on the right side of the above figure introduces API gateway, functional computing or Serverless application engine to implement the computing layer, leaving a lot of work to the cloud service to complete, allowing users to focus on the implementation of business logic to the maximum extent. The interaction of multiple micro-services within the system is shown in the following figure, which presents multiple internal micro-services to the outside by providing a commodity aggregation service. The microservices here can be implemented through SAE or functions.

Such an architecture can also continue to expand, such as how to support access from different clients, as shown on the right side of the figure above. In reality, this demand is common, different clients may need different information, mobile phones can make recommendations according to the location information. How can mobile clients and different browsers benefit from the Serverless architecture? This leads to another word-Backend for fronted (BFF), which is custom-made backend, which is respected by front-end development engineers. Serverless technology makes this architecture popular because front-end engineers can write BFF directly from a business point of view without having to manage server-related headaches for front-end engineers. For more practice, see the BFF architecture based on function computing.

Event trigger

The dynamic page generation mentioned earlier is completed by synchronous requests, and there is also a common scenario in which request processing usually takes a long time or more resources, such as picture and video content management in user comments. It involves how to upload and handle pictures (thumbnails, watermarks, reviews, etc.) and videos to meet the playback needs of different clients.

How to upload multimedia files in real time? The technical architecture of this scenario has generally undergone the following evolution:

Single server-based architecture: multimedia files are uploaded to the server and processed by the server, and multimedia display requests are also completed by the server.

Server-based micro-service architecture: multimedia files are uploaded to the server, and the server processes the transfer to OSS, then adds the file address to the message queue, another group of servers processes the file, saves the processing results to OSS, and the multimedia display request is completed by OSS and CDN

Serverless architecture: multimedia is directly uploaded to OSS, the function is triggered directly by the event trigger ability of OSS, the result of function processing is saved to OSS, and the display request for multimedia is completed by OSS and CDN.

A single server-based architecture faces the following problems:

How to deal with massive documents? Limited space for a single server, buy more servers

How to extend the Web application server? Is the Web application server suitable for CPU-intensive tasks?

How to solve the high availability of upload requests?

What if the high availability of the display request is resolved?

How to deal with the peaks and troughs of the request load?

The server-based micro-service architecture solves most of the above problems well, but still faces some problems:

Manage the high availability and resiliency of application servers

Manage the flexibility of the file processing server

Manage the resilience of message queues.

The third Serverless architecture solves all the above problems very well. The load balancing that the developer originally needed to do, the high availability and flexibility of the server, and the message queue are all transferred to the service. We can see that with the evolution of the architecture, developers do less and less, the system is more mature, the business is more focused, and the delivery speed is greatly improved.

The main values of the Serverless architecture here are:

Event triggering ability: the native integration of function computing service and event source (OSS) allows users to automatically expand the queue without managing queue resources, and to process uploaded multimedia files in real time.

High flexibility and pay-on-demand: pictures and videos (videos of different sizes) require different specifications of computing resources, and the demand for resources in the peaks and valleys of traffic is different. Now this flexibility is provided by services to expand and reduce capacity according to the real use of users, so that users can make full use of resources without paying for idle resources.

Event triggering capability is an important feature of FaaS services, and this Pub-Sub event-driven model is not a new concept, but before Serverless became popular, the producers, consumers, and intermediate connection hubs of events were all responsible for users, just like the second architecture in the previous architecture evolution.

Serverless lets producers send events and maintain connection hubs are omitted from the user's responsibilities, and only need to focus on the logic of the consumer, which is the value of Serverless.

Functional computing services also integrate other cloud service event sources, making it easier for you to use some common patterns in your business, such as Pub/Sub, event flow pattern, and Event Sourcing pattern. For more information about function combination patterns, see: n ways of function combination.

Service arrangement

Although the previous merchandise page is complex, all operations are read operations, and the aggregation service API is stateless and synchronous. Let's take a look at one of the core scenarios in e-commerce-the order process.

This scenario involves multiple distributed writes, which is one of the most troublesome problems caused by the introduction of micro-service architecture. To some extent, a single application can handle this process more easily, because a database is used and data consistency can be maintained through database transactions. However, in reality, you may have to deal with some external services, and you need a certain mechanism to ensure that the progress and fallback of the process can be completed smoothly. A classic model to solve this problem is the Saga pattern, which can be implemented in two different architectures:

One approach is to adopt an event-driven model to drive the completion of the process. In this architecture, there is a message bus, interested services such as inventory services listen for events, and listeners can use servers or functions. With the integration of functional computing and message topics, this architecture can also be completely server-free.

This architecture module is loosely coupled and has clear responsibilities. The downside is that as the process becomes longer and more complex, the system becomes difficult to maintain. For example, it is difficult to intuitively understand the business logic, the state of execution is not suitable for tracking, and the operation and maintenance is relatively poor.

Another architecture is the workflow-based Saga pattern. In this architecture, each service is independent and does not transmit information through events, but there is a centralized coordinator service to schedule a single business service, and the business logic and state are maintained by the centralized coordinator. Coordinators who implement this centralization often face the following problems:

Write a lot of code to implement functions such as orchestration logic, state maintenance and error retry, but these implementations are difficult to be reused by other applications

Maintain the infrastructure for running orchestration applications to ensure high availability and scalability of orchestration applications

Consider state persistence to support multiple steps to run the process for a long time and to ensure that the process is transactional.

Relying on cloud services, such as Aliyun's Serverless workflow service, these things can be left to the platform, and users have returned to the state that they only need to focus on business logic.

On the right side of the following figure is the process definition, which we can see achieves the effect of the previous event-based Saga pattern, and the process is greatly simplified and observable.

Data pipeline

With the further development of the business, the data becomes more and more, at this time we can mine the value of the data. For example, analyze the user's behavior to the site and make recommendations accordingly. A data pipeline includes many links such as data acquisition, processing, analysis and so on. It is feasible to build such a service from scratch, but it is also complex. The business we are talking about here is e-commerce, not to provide a data pipeline service. With such a goal, it becomes simple and clear when we make choices.

Log service (SLS) provides data acquisition, analysis and delivery functions.

Function computing (FC) can process the data of log service in real time and write the results to other services, such as log service and OSS.

Serverless workflow service can process data in batches at regular intervals, define flexible data processing logic through functions, and build ETL jobs.

Data Lake Analysis (DLA) provides an interactive query service based on Serverless, which uses standard SQL to analyze data from multiple data sources, such as object storage (OSS), database (PostgreSQL / MySQL, etc.), NoSQL (TableStore, etc.). On how to understand the Serverless architecture pattern to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.