Yubl：从单体架构到无服务器架构的转型之路

# Yubl：从单体架构到无服务器架构的转型之路 ## 1. 旧架构的痛点 在之前的架构中，系统面临着诸多问题。测试方面，与外部服务的交互被大量模拟，测试往往只是确认模拟是否正常工作，即便 MongoDB 查询包含语法错误，测试也可能通过，导致大量误报，让我们对测试结果缺乏信心。 部署方面，每次部署都需要将整个系统停机 30 分钟以上，在此期间用户没有任何反馈，应用看起来就像崩溃了一样。新功能上线需要数月时间，即使是简单的更改也常常需要数周才能完成，这让所有参与其中的人都感到沮丧。 ## 2. 选择无服务器架构的原因 基于系统的需求和当前实现所面临的问题，无服务器架构是一个绝佳的选择，原因如下： |优势|详情| |----|----| |自动伸缩|AWS Lambda 可根据负载自动调整并发执行的数量，能瞬间应对不可预测的流量高峰。| |冗余性|默认将函数部署到三个可用区，提供显著的冗余性，且无需额外成本。与 EC2 不同，使用 Lambda 时，我们只需为函数运行付费。| |基础设施管理|AWS 负责底层物理基础设施和操作系统的管理，定期进行补丁和安全更新，能更好地保障操作系统的安全。| |简化部署|借助 Serverless 框架等工具，应用的部署流程大幅简化。典型的部署过程不到一分钟，且无需停机，因为 AWS Lambda 会自动将请求路由到新代码。| |专注业务逻辑|使用 API Gateway、Lambda 和 DynamoDB 等无服务器技术时，我们无需担心底层基础设施，可专注于解决核心业务需求，开发团队能更快速地推进项目。| |提高部署频率|在团队规模不变的情况下，每月的生产部署次数从 4 - 6 次增加到平均每月超过 80 次，每个开发者的工作效率得到提升。| |性能提升|随着系统向无服务器架构迁移，可扩展性、成本和可靠性都得到了改善，生产环境中的问题大幅减少，成本也显著降低。| ## 3. 新的无服务器 Yubl 架构 到 2016 年 11 月，在开始向无服务器架构转型不到 8 个月的时间里，几乎整个后端系统都完成了迁移，采用了 API Gateway、Lambda、DynamoDB、Kinesis 等多种服务的组合。这期间，我们不仅增强了现有功能，还实现了无数新功能，同时解决了之前系统存在的许多安全问题。 新架构的主要亮点如下： - **微服务拆分**：将单体应用拆分为多个微服务。 - **独立开发与部署**：每个微服务都有自己的 GitHub 仓库和 CI/CD 管道，使用 Serverless 框架将构成微服务的所有组件（API Gateway、Lambda 函数、DynamoDB 表等）作为一个 CloudFormation 堆栈一起部署。 - **独立子域名**：大多数微服务都有一个在自己子域名下运行的 API Gateway REST API，如 search.yubl.com。 - **独立数据库**：每个微服务都有自己的数据所需的数据库，多数使用 DynamoDB，但并非所有微服务都如此，因为不同微服务有不同的数据需求。 - **事件驱动**：系统中的每个状态变化都被捕获为事件并发布到 Kinesis 数据流中，例如用户创建新内容、用户发布新内容等。 - **数据同步**：大多数情况下，我们更倾向于通过事件而不是运行时的同步 API 调用来同步微服务之间的数据，这有助于防止一个微服务在生产环境中出现故障时引发级联故障。微服务会订阅相关的 Kinesis 数据流，并从相应的事件中复制所需的数据。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(单体应用):::process --> B(微服务 1):::process A --> C(微服务 2):::process A --> D(微服务 3):::process B --> E(API Gateway):::process C --> F(API Gateway):::process D --> G(API Gateway):::process E --> H(Lambda 函数):::process F --> I(Lambda 函数):::process G --> J(Lambda 函数):::process H --> K(DynamoDB 表):::process I --> L(DynamoDB 表):::process J --> M(DynamoDB 表):::process B --> N(Kinesis 数据流):::process C --> N D --> N ``` ## 4. 重新架构与重写 为了实现目标，我们需要对系统的大部分进行重新架构和重写，但并非为了迁移而将所有功能都迁移到无服务器架构。我们采取了务实的方法，根据具体情况决定是