Basic Service Architecture
This article focuses on the principles underlying the Serverless architecture and its event specification.
First, let’s take a look at what our typical Web scenario looks like in the HTTP/Web scenario:
Here, it is easy to see that a typical Web scenario is actually composed of three large pieces of content: client, server, and database. The client in the server side through type Apache, Nginx and other proxy server to request data, proxy server through the database to write or pull data. This is simple, and it’s our most common Web scenario.
Routing rules, authentication logic and other complex business codes may be involved in the server. At the same time, the development team has to pay a lot of energy on the operation and maintenance of the server, including whether the server needs to be expanded when the number of customers suddenly increases. Are scripts, business code, etc. on the server still healthy? Are there hackers constantly attacking the server?
Serverless Service architecture
So let’s look at how the Serverless service requests data:
In the Serverless scenario, the client needs to access the FaaS service through THE API gateway Baas, and then realizes the database write and pull through the database link through the function calculation.
When the client and the database under the premise of not change, the change is big, need to develop team maintain routing module before and authentication module will be access services provided by the API gateway system and authentication system, the development team do not need to maintain the business code, the two parts again you just need to continue to maintain the related rules. Business code is also broken down into function granularity, with different functions representing different functions.
From the above example, it is not difficult to see that a complete Serverless request actually has two large chunks, namely our Faas service and our BaaS service. Then, Serverless is composed of two parts, namely Faas+Baas.
Serverless Architecture core
After understanding the whole Serverless situation, let’s look at the infrastructure of traditional Faas. In fact, the most critical core concept of traditional Faas is our call. We can use Event Sources to call another Function Function to realize the extension of a single Function. The overall schematic diagram is as follows:
- Event Sources: Events fired or streamed to one or more function instances;
- Function Instance: individual functions/microservices can be extended as needed;
- FaaS Controller (FaaS Controller) : Deploy, control, and monitor function instances and their sources
- Platform services: Generic cluster or cloud services (sometimes called back-end as a service, or BaaS, etc.) used by FaaS solutions
Events in the Serverless schema
So we have another concept, which is events, what is an event? How is an event defined?
We can lead to CloudEvents, which is a specification for describing event data in a common format to provide interoperability across services, platforms, and systems. The event format specifies how to serialize CloudEvent using certain encoding formats. CloudEvents compatible implementations that support these encodings must follow the encoding rules specified in the corresponding event format. All implementations must support JSON format.
Events are everywhere, but each Event source produces different events. In the absence of a unified description of events, there is a constant relearning of how to consume different types of events for event developers. For example, the events generated by CMQ and API gateway triggers from the same vendor may be different, and the events generated by API gateway triggers from different vendors may also be different.
REQUIRED Attributes
• ID – Identifies events
• Source – Identifies the context in which the event occurred
• Specversion – Events use this version of the cloudEvents specification
• Type – The value of the Type in which the related event occurs
• data-data Data content format
• Subject – The event context topic of the event developer
• Tiem – Events occur events
Calls in the Serverless architecture
After our event, let’s talk about another core call. In the Serverless architecture, there are four simple calls:
Functions can be called from different event sources for different use cases, for example:
- Synchronous requests (Req/Rep), such as HTTP requests, gRPC calls
- The customer issues a request and waits for an immediate response.
- Asynchronous message queue requests (publish/subscribe) such as RabbitMQ, AWS SNS, MQTT, email, object (S3) changes, scheduled events (such as CRON jobs)
- Messages are published to the switch and distributed to subscribers;
- There is no strict ordering of messages and a single-processing granularity.
- Message/record Streams: for example Kafka, AWS Kinesis, AWS DynamoDB Streams, database CDC
- An ordered set of messages/records that must be processed in sequence;
- Typically, each shard uses a single worker (shard consumer) to shard the stream into multiple partitions/shards;
- Streams can be generated from messages, database updates (logs), or files (e.g. CSV, Json, Parquet);
- Events can be pushed to or pulled by the function runtime.
- Batch jobs, such as ETL jobs, distributed machine learning, HPC simulation
- Jobs are scheduled or submitted to queues and processed at run time using parallel multiple function instances, each of which processes one or more parts of the working set (tasks)
Different types of event sources include:
- Event and messaging services, such as RabbitMQ, MQTT, SNS
- Storage services, such as COS, CDB, PGSQL, Cognito, Google Cloud Storage,
- Endpoint services, e.g. : Internet of Things, HTTP Gateways, mobile devices, Alexa,
- Configure repositories, such as Git, CodeCommit
- User applications using language-specific SDKS
- Schedule events to enable function calls periodically.
While the data provided by each event may differ from event source to event source, the event structure should be generic and encapsulate specific information about the event source.
conclusion
The above is a bit of thinking about Serverless architecture and event specification, hoping to give you some help.
Portal:
- GitHub: github.com/serverless
- Website: serverless.com
Welcome to Serverless Chinese, you can experience more about Serverless application development in the best practices!
Recommended reading: Serverless Architecture: From Principle, Design to Project Practice