1 Overview
Serverless translated as "no service" in Chinese is a newly emerging architecture model. The company's ESB products introduce the process of Rest microservice service mechanism. The author has consulted a lot of information and has some preliminary understanding, so I share my study notes with everyone, hoping to help relevant learners. This article mainly starts from its own questions to explain what serverless architecture is, what are the advantages and disadvantages of serverless architecture, and what application cases are there.
2 Explanation of terms
What is Serverless? It is an Internet-based technical architecture concept. Serverless doesn't really need servers, it just doesn't pay too much attention to servers. It refers to a significant or sufficient reliance on a third-party application or service to manage server-side logic and state, allows you to manage your application deployment at the service deployment level rather than the server deployment level, or even allows you to manage a specific function or The deployment of ports allows developers to iterate quickly and develop software more quickly.
Serverless architectures are divided into two types, "Backend as a Service" and "Functions as a Service".
"Backend as a Service", or BaaS, is a new type of cloud service that provides back-end cloud services for mobile and web applications to manage logic and state, including cloud data/file storage, message push (such as Jiguang) push, individual push), application data analysis, etc. It can be said that BaaS is a development architecture that was born in the mobile Internet to accelerate the development of mobile applications and reduce costs.
"Functions as a Service" is FaaS, which refers to such applications, part of the service logic is implemented by the application, but different from the traditional architecture, they run in a stateless container, which can be triggered by events, and is short-lived and completely managed by a third party , Functionally, FaaS means that you don't need to care about background servers or application services, you only need to care about your own code. Among them, AWS Lambda is one of the best FaaS implementations out there.
Lambda is a computing service that executes code written in JavaScript (node.js), Python, or Java on AWS infrastructure. Source code is deployed to isolated containers with individually allocated memory, disk space, and processors. This combination of code, configuration, and dependencies is often referred to as a Lambda function.
3 Architecture Features
3.1 Cost saving
The configuration of the cloud server we purchased on Alibaba Cloud or Tencent Cloud is fixed, such as 2G memory and dual-core CPU. The disadvantage of this is that if the system needs to support a high amount of concurrency on a specific day, such as: Double Eleven That day, but the memory of the server is not enough, do you need to buy more memory for that day? Under the serverless architecture, users can expand or shrink the capacity at any time through network, hard disk, CPU and other computing resources without the need for additional server infrastructure, and there is no limit to the storage of the database. It is billed according to the number of calls. If there is no traffic at ordinary times, it will not be billed, so there will be no waste, which effectively saves costs.
3.2 Simplify O&M
Traditional servers need to maintain programs and hardware facilities; in the serverless architecture, developers will be faced with third-party developed or customized APIs and URLs, the underlying hardware is transparent to developers, and the technical team no longer needs to focus on operation and maintenance. , can focus more on application system development. At the same time, the composition logic of the application uses a large number of third-party functional services. At present, third-party services such as login authentication services and cloud database services have been greatly optimized in terms of security, usability, and performance. The development team can directly integrate third-party services, which can effectively reduce development costs and enable applications The operation and maintenance process becomes clearer, which effectively improves the maintainability of the application.
4 Application Modes
4.1 UI-Driven Applications
Let's explore a 3-tier client-oriented system in terms of server-side logic. Common e-commerce applications are a good example (here I take an online pet store as an example)
Traditionally, the architecture would look like this, and assuming it's implemented in Java on the server side, using HTML/Javascript components for the client side:
Client (browser) ---> Pet Shop Server ----> Database
With this architecture, the client can be relatively unintelligent, and much of the logic in the system - authentication, page navigation, search, transactions - is implemented by the server application.
With a serverless architecture, it might be more like this:
Authentication Service--->Product Database--->Client (Browser)--->API Gateway--->Purchase Function--->Purchase Database
Authentication Service--->Product Database--->Client (Browser)--->API Gateway--->Search Function--->Product Database
Here is the difference between the two:
1. Delete the authentication logic system originally applied and replace it with a third-party BaaS service.
2. Allow the client to directly access the database, such as the product list, the database is on a third-party host such as AWS Dynamo, so that our security policy for accessing the database is different from accessing server resources.
3. The first two points mean the very important third point. The logic that was originally in the pet store is now migrated to the client, such as tracking user sessions, understanding the UX user experience structure of the application, such as paging, reading and transferring from the database. For available views, etc., the client has actually become a single-page application at this time.
4. Some UX related functions may remain on the server side, such as computationally sensitive or need to access a large amount of data, such as search functions, for this function we do not always let it run on the server side, but implement a FaaS function to respond. http request, the client accesses this FaaS function through the API gateway.
5. Use the FaaS function to replace the purchase function. For security reasons, it is still placed on the server, and there is no need to implement it again on the client side. This is also achieved through API gateway calls.
4.2 Message-Driven Applications
A different example is a backend data computing service. Say you're writing a user-centric application that needs to respond quickly to UI requests, but you need to capture all the different types of activities that happen. Let's think about the online advertising system. When a user clicks on an advertisement, you need to quickly lead to the advertisement, but at the same time, you need to count the click and charge the advertiser.
The architecture of such a system in a traditional way might look something like this: the "ad server" would respond to the user in a synchronous way (since it's just an example, we don't need to care about the specific interaction), and at the same time need to publish a message to the channel and be responsible for The "click handler" application that updates the database processes it asynchronously, for example by deducting part of an advertiser's budget.
In a serverless world, the system would look like this:
Compared to the previous example, the differences between the two architectures in this example are minimal. We replaced the long-running consumer application with a FaaS function that ran in a vendor-provided event-driven context. Note that the vendor provides both a Message Broker and a FaaS environment, and the two systems are very tightly integrated with each other.
By instantiating multiple copies of function code, a FaaS environment can process multiple hits in parallel, depending on how the original process was written, and is a new concept to consider.
5 Architectural flaws
5.1 Vendor Platform Binding
The platform will provide a serverless architecture for big players, such as AWS Lambda. To run it, you need to use AWS-specified services, such as API Gateway, DynamoDB, S3, etc. Once you develop a complex system on these services, you will stick to AWS, and later They have to allow them to increase prices or remove them from the shelves. It is difficult to meet individual needs, and it is impossible to perform random migration or the cost of migration is relatively large, and some losses are inevitable at the same time. A typical event in the Baas industry, on January 19, 2016, Facebook closed Parse, which had been acquired with huge sums of money, causing users to have to migrate data generated on this platform for more than a year, which undoubtedly requires a lot of manpower and time. cost.
5.2 No industry standard
The current situation is only suitable for simple application development and lacks the promotion of large-scale successful cases. Serverless lacks a unified cognition and corresponding standards, and cannot adapt to all cloud platforms. It is still immature. Each manufacturer speaks for itself. It is more in a process of exploration and wait-and-see. Raising standards, and many of them are still in the stage of vague concepts.
6 Summary of experience
Serverless serverless architecture is the latest concept that developers and enterprise organizations need to consider, research and adopt. It is a technical architecture that relies on third-party applications or services to manage server-side logic and state, but it cannot actually replace servers. Serverless is a manifestation of the latest popular microservices, a practice of a new generation of cloud services and development architecture, and one of the key directions of cloud computing development.
随着开发人员积极采用AWS Lambda等计算服务，这种架构可能会迅速发展起来。但是，这一架构目前来看还不是特别成熟，有待考证。笔者认为我们可以熟悉下业内Serverless架构的经典产品，并进行学习，进而开发属于自己的Serverless产品，数通畅联的拳头产品ESB企业服务总线中就提供Rest微服务服务组件、以及微服务服务管理、监控、统计功能，能满足微服务架构下的常见典型应用场景，如有需求敬请关注。