介绍关于 Serverless 的架构模式。

    传统的基础设施设计，以一个简单的 web 服务为例，客户端通过 http 与 web 服务进行通信：
    image.png

    • 一开始是非常简单的单体结构，将 web 应用部署在单个服务器（EC2 实例）上，可能 backend 还有数据库来持久化数据。
    • 当用户和流量增加时，增加单个服务器的性能配置，最终超出服务器的负载能力。
    • 将应用部署在多台 EC2 实例上，前面放一个负载均衡器来进行水平伸缩，这会有个成本管理问题：当流量高峰过去之后，会有大量的服务器闲置。
    • 此时，将应用部署在云环境中，添加一个自动伸缩组，就可以很简单的根据流量来自动改变实例的规模。
    • 也可以在云环境中，轻松实现高可用，将应用部署在不同的可用区。
    • 到目前位置，这是一个非常常见的架构，但是需要考虑很多问题，如何管理基础设施，如何提供实例，如何确保服务器是健康的，用什么指标来确定什么时候伸缩到什么规模。

    相同的简单 web 服务在 Serverless 架构设计：
    image.png

    • 将 http 请求视为对我们服务有一定意义的 Event，中间处理请求的逻辑代码视为 Handler，backend 可能一些与 handler 交互的后端服务。
    • Handler 就是 Lambda function，用于实现你的业务逻辑，它支持 JavaScript，Python，Java，C# 或者 Go 。
    • 那如何构建和部署 Lambda function 呢？
      • 与传统应用开发唯一不同的是，你需要写一个 handler method 作为你的代码入口。
      • 然后将这些代码打包成 zip 文件，将 zip 文件上传到 AWS Lambda Service。
      • 然后为你的 lambda function 配置 event sources，代码将在这些事件发生时自动运行以响应它们。
      • Lambda Service 会负责提供底层计算和运行时环境。

    image.png
    当你在设计你的架构时，不要关注这个问题:我存储的数据是什么，我需要对它执行什么操作?”相反，问问自己:在我的系统中应该触发某个动作的事件是什么。

    使用 Serverless 架构的关键是，弄清楚如何为应用程序的各个部分利用正确的托管服务，例如：

    • 使用 Amazon API 网关来管理 restful API，这可以简化对身份验证、授权、限流及其他 API 复杂的事情的管理。
    • 将数据持久化到 DynamoDB 这样的 no sql 数据库，而不是管理自己的数据库。
    • 然后司机用单独 Lambda function 将所有这些链接在一起，以构建更大，更复杂的程序。