Sync: add infrastructure as code notes

2026-04-24 19:58:02 +08:00
parent cc23df1883
commit e4f6f463cb
29 changed files with 2344 additions and 155 deletions
--- a/wiki/concepts/Canary-Deployment.md
+++ b/wiki/concepts/Canary-Deployment.md
@@ -0,0 +1,56 @@
+---
+title: "Canary Deployment"
+type: concept
+tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
+sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
+last_updated: 2026-05-05
+---
+
+# Canary Deployment
+
+## Definition
+金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
+
+## Core Mechanism
+1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
+2. **逐步提升**：从低比例开始，逐步增加新版本流量
+3. **快速回滚**：发现问题时，立即将流量切回旧版本
+
+## Implementation in AWS
+
+### ECS (Elastic Container Service)
+ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
+- 创建新旧两个 Task Definition
+- 通过 ALB/NLB 的 Target Group 逐步调整权重
+- 结合 CloudWatch 监控自动决策扩缩比例
+
+### EKS (Elastic Kubernetes Service)
+Kubernetes 原生支持金丝雀部署，通过以下机制：
+- `ReplicaSet` 控制新旧版本副本数
+- `Service` 选择器配合金丝雀标签
+- Argo Rollouts 等高级工具提供声明式金丝雀策略
+
+### AWS Tools
+- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
+- **ALB Target Groups**：权重路由实现流量分割
+- **CloudWatch**：金丝雀指标监控
+
+## Comparison with Other Deployment Strategies
+
+| 策略 | 风险 | 成本 | 适用场景 |
+|------|------|------|----------|
+| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
+| **Canary** | 低 | 中 | 生产验证 |
+| **Rolling** | 中 | 低 | 资源受限环境 |
+| **A/B Testing** | 低 | 中 | 功能验证 |
+
+## Key Metrics to Monitor
+- 错误率（5xx）
+- 延迟（P50/P95/P99）
+- 业务指标（转化率/点击率）
+- 资源利用率
+
+## Related Concepts
+- [[Blue-Green-Deployment]]：双环境切换策略
+- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
+- [[Infrastructure-as-Code]]：部署自动化基础
--- a/wiki/concepts/Cross-account-Terraform-Modules.md
+++ b/wiki/concepts/Cross-account-Terraform-Modules.md
@@ -0,0 +1,61 @@
+---
+title: "Cross-account Terraform Modules"
+type: concept
+tags: [Terraform, Cross-Account, Modules, IaC, AWS]
+sources: [ctp-topic-16-cross-account-terraform-modules]
+last_updated: 2026-04-14
+---
+
+## Overview
+
+Cross-account Terraform Modules 指的是在单个 Terraform 模块中通过配置多个 AWS Provider，实现跨多个 AWS 账号同时创建或管理资源的能力。
+
+## Problem Statement
+
+在复杂的云架构中（如 AWS Landing Zone），经常需要在一个模块内跨多个账号创建资源。例如：
+- 在 **InfoBlocks 账号** 配置 DNS 记录
+- 在 **Workload 账号** 部署应用服务
+
+原有的 Gruntwork 流水线主要针对单账号设计，直接赋予账号间互访权限存在巨大安全风险——某一账号被攻破可能波及全局。
+
+## Solution Architecture
+
+基于 **Shared Account（共享账号）** 的中心化部署方案：
+
+1. **Jenkins 托管于 Shared Account**，当检测到模块目录中存在 `cross-account.json` 标记文件时，触发 ECS Deploy Runner
+2. **ECS Deploy Runner**（运行在 ECS 上的 Docker 容器）被授予特殊权限，通过 Assume Role 访问目标账号：
+   - `TF state bucket accessor`：读取目标账号 S3 桶中的 Terraform 状态文件
+   - `cross-account ECS deploy runner role`：在目标账号内执行资源部署
+3. 通过根目录 `terragrunt.hcl` 配置角色切换逻辑
+
+## Three Design Goals
+
+| Goal | Mechanism | Benefit |
+|------|-----------|---------|
+| **安全性** | 无 Workload 账号间直接信任，权限集中于 Shared Account | 控制 Blast Radius |
+| **自动化** | Jenkins 自动识别模块类型并选择正确部署路径 | 无人工干预 |
+| **可复用性** | 模块代码不硬编码特定账号的角色 | 灵活适配多环境 |
+
+## Key Files
+
+- `cross-account.json`：约定俗成的标记文件，放置于模块目录中，告知 Jenkins 调用跨账号部署逻辑
+- `terragrunt.hcl`（Root）：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
+
+## Relationships
+
+- [[ECS Deploy Runner]] — 执行单元，运行 Docker 容器执行 plan/apply
+- [[Shared Account]] — 信任源，托管 Jenkins 和公共服务
+- [[Terraform]] — 底层 IaC 工具
+- [[Gruntwork]] — 参考架构来源
+- [[AWS-Landing-Zone]] — 多账号架构框架
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — 上层方法论
+- [[GitOps]] — 部署编排模式
+- [[Assume Role]] — 跨账号身份切换机制（AWS IAM）
+
+## Notes
+
+- 本方案与单账号 Gruntwork 流水线为**演进关系**而非冲突
+- 本方案与 Atlantis 跨账号 IAM Role 机制**类似**，但执行载体不同（ECS 容器 vs EC2）
--- a/wiki/concepts/DRY-Principle.md
+++ b/wiki/concepts/DRY-Principle.md
@@ -0,0 +1,68 @@
+---
+title: "DRY Principle"
+type: concept
+tags:
+  - software-engineering
+  - iac
+  - best-practices
+sources: [ctp-topic-48-terraform-vs-terragrunt]
+last_updated: 2026-04-26
+---
+
+# DRY Principle
+
+## Definition
+
+DRY（Don't Repeat Yourself，勿重复自己）是一项软件工程原则，主张：**系统中的每一条知识必须有一个单一的、明确的、权威的表示**。DRY 的核心目标是减少重复代码和配置，提高系统的可维护性、可扩展性和可测试性。
+
+## Core Idea
+
+> "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
+
+DRY 不是简单的"不复制粘贴"，而是更深层的原则：**避免重复的知识**。这包括：
+- 代码逻辑
+- 配置文件
+- 文档注释
+- 数据结构
+
+## DRY in IaC
+
+在基础设施即代码（IaC）领域，DRY 尤为重要，因为基础设施配置往往需要在多个环境（dev/staging/prod）中复用：
+
+| 实践 | 说明 |
+|------|------|
+| **Terragrunt** | 封装 Terraform，通过 `remote_state` 和 `include` 块统一管理跨环境的 provider 和状态配置 |
+| **Terraform Modules** | 将可复用的基础设施组件抽象为模块，避免在每个环境中重复定义 |
+| **Service Catalog** | 企业级模块目录，支持三级复用（单账户→产品团队→跨团队） |
+| **Hierarchical Configuration** | 层级配置继承，父级定义通用配置，子级覆盖特定值 |
+
+**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+
+## DRY vs WET
+
+| 原则 | 全称 | 结果 |
+|------|------|------|
+| **DRY** | Don't Repeat Yourself | 一次定义，多次引用 |
+| **WET** | Write Everything Twice | 多次重复，维护成本高 |
+
+WET 的典型反模式：
+- 复制粘贴配置到每个环境
+- 硬编码值而非使用变量
+- 注释与代码不同步
+
+## When NOT to Apply DRY
+
+DRY 不是绝对的，在以下情况下适度重复是可接受的：
+- **性能优化**：内联代码可能比函数调用更快
+- **可读性**：过度抽象可能导致代码难以理解
+- **解耦**：强制的 DRY 可能增加组件间的耦合
+
+## Related Concepts
+
+- [[Infrastructure-as-Code]] — DRY 原则的重要应用领域
+- [[Terraform]] — Terragrunt 的底层引擎
+- [[Terragrunt]] — DRY 原则在 Terraform 生态中的具体实现
+
+## Related Sources
+
+- [[ctp-topic-48-terraform-vs-terragrunt]]
--- a/wiki/concepts/Event-Driven-Architecture.md
+++ b/wiki/concepts/Event-Driven-Architecture.md
@@ -0,0 +1,108 @@
+---
+title: "Event-Driven Architecture"
+type: concept
+tags:
+  - Architecture
+  - Event-Driven
+  - Serverless
+  - AWS
+sources:
+  - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+  - public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091
+  - public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091
+last_updated: 2026-05-05
+---
+
+## Definition
+
+Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。
+
+## Core Principles
+
+| 原则 | 描述 |
+|------|------|
+| 异步通信 | 生产者和消费者解耦，无需同步等待响应 |
+| 事件声明 | 事件代表"发生了什么"，而非"该做什么" |
+| 松耦合 | 生产者和消费者之间无直接依赖 |
+| 可扩展 | 新增消费者无需修改生产者代码 |
+
+## Event Anatomy
+
+典型事件包含：
+
+```json
+{
+  "event_id": "uuid",
+  "event_type": "ORDER_CREATED",
+  "source": "order-service",
+  "timestamp": "2026-04-14T10:00:00Z",
+  "data": { /* 业务相关数据 */ }
+}
+```
+
+## AWS Event-Driven Stack
+
+| 组件 | 角色 | 说明 |
+|------|------|------|
+| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 |
+| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 |
+| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 |
+| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 |
+| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda |
+| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda |
+
+## Serverless 中的事件驱动
+
+[[AWS-Lambda]] 是事件驱动架构的核心执行单元：
+
+- **事件即触发器**：Lambda 函数不主动运行，由事件触发
+- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件
+- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件
+
+## Event Patterns
+## EDA 三组件与事件代理类型
+
+| 组件 | 角色 | 说明 |
+|------|------|------|
+| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 |
+| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 |
+| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 |
+
+**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者：
+- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发
+- [[Amazon-SNS]]：一对多广播（Fan-out）
+
+**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤：
+- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once）
+- [[Kinesis-Data-Streams]]：有序事件流，支持重放
+
+## 编排模式：Choreography vs Orchestration
+
+| 模式 | 特点 | 适用场景 |
+|------|------|---------|
+| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 |
+| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 |
+
+## 生产级最佳实践
+
+1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。
+
+2. **事件排序**：
+   - **有序**：SQS FIFO 或 Kinesis Data Streams
+   - **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序）
+
+3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。
+
+## Event Patterns
+1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型
+2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放
+3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者
+4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS）
+5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失
+6. **Saga Pattern**：通过事件序列协调分布式事务
+7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源
+
+## Connections
+- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]]
+- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]]
+- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]]
--- a/wiki/concepts/Infrastructure-as-Code.md
+++ b/wiki/concepts/Infrastructure-as-Code.md
@@ -1,37 +1,49 @@
 ---
 title: "Infrastructure as Code"
 type: concept
-tags: [DevOps, 自动化, 配置管理]
-sources: [ctp-topic-70-eks-deployment-using-iac, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, ctp-topic-16-cross-account-terraform-modules, ctp-topic-12-using-ses-smtp-service-terraform-module, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]
-last_updated: 2026-04-24
+tags: [DevOps, AWS, Terraform, Automation]
+sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
+last_updated: 2026-05-05
 ---

 # Infrastructure as Code

-## Overview
-Infrastructure as Code (IaC) 是一种通过代码定义和管理基础设施的方法，实现基础设施的标准化、可审计和可重复部署。
+## Definition
+基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。

 ## Core Principles
- **声明式配置**：定义期望的状态，而非执行的具体步骤
- **版本控制**：所有基础设施配置纳入 Git 版本控制
- **自动化部署**：通过 CI/CD 流水线自动化执行部署
- **幂等性**：重复执行相同配置不产生副作用
+- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
+- **版本控制**：所有基础设施定义文件存储在 Git 中
+- **幂等性**：多次执行产生相同结果
+- **可重复性**：同一模板可在不同环境快速部署
+- **自动化**：与 CI/CD 流水线集成

 ## Key Tools
- **Terraform**：HashiCorp 的基础设施编排工具，支持多云
- **AWS CloudFormation**：AWS 原生的 IaC 服务
- **AWS Service Catalog**：AWS 的服务目录，封装标准化产品组合
- **Pulumi**：使用编程语言（Python, TypeScript 等）定义基础设施
+- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
+- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
+- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
+- **Pulumi**：编程语言驱动的 IaC 平台
+- **Ansible**：配置管理和应用部署工具

-## Key Concepts
- **HCL (HashiCorp Configuration Language)**：Terraform 的配置语言
- **State Management**：Terraform 使用 state 文件追踪资源
- **Modules**：可重用的基础设施组件
- **Remote State**：远程状态存储，支持团队协作
+## Terraform Ecosystem
+- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
+- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
+- **Terratest**：Terraform 代码的 Go 测试框架
+- **tfsec**：Terraform 静态安全分析工具
+- **TFLint**：Terraform 代码规范检查
+
+## IaC in CTP Context
+CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
+- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
+- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
+- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践

 ## Related Concepts
- [[Terraform]]：最流行的 IaC 工具之一
- [[AWS Service Catalog]]：AWS IaC 产品目录
- [[GitOps]]：基于 Git 的运维方法论
- [[CI/CD Pipeline]]：自动化部署流水线
- [[DevOps Culture]]：IaC 是 DevOps 实践的核心组成
+- [[GitOps]]：Git 作为 IaC 的单一真相来源
+- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
+- [[Policy-as-Code]]：IaC 扩展至安全合规策略
+- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
+- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
--- a/wiki/concepts/Serverless-Computing.md
+++ b/wiki/concepts/Serverless-Computing.md
@@ -1,76 +1,70 @@
 ---
 title: "Serverless Computing"
 type: concept
-tags: [Cloud, Serverless, Cloud Native, Edge Computing]
-date: 2026-04-26
+tags:
+  - Cloud
+  - Serverless
+  - AWS
+  - DevOps
+sources:
+  - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
+last_updated: 2026-04-14
 ---

-# Serverless Computing (无服务器计算)
-
 ## Definition
-**Serverless Computing** is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Developers can build and deploy applications without worrying about infrastructure management.

-## Key Characteristics
- **No server management**: Cloud provider handles infrastructure
- **Automatic scaling**: Resources scale based on demand
- **Pay-per-use**: Pay only for execution time
- **Event-driven**: Functions respond to events/triggers
+Serverless Computing（无服务器计算）是一种云原生执行模型，在该模式下，云厂商承担底层基础设施的全部运维责任（负载均衡、自动扩展、安全补丁、容量管理），开发者只需专注编写业务逻辑代码。Serverless 并非"无服务器"，而是将服务器管理抽象给云厂商。

-## Key Platforms
+## Core Characteristics

-| Provider | Service |
-|----------|---------|
-| AWS | Lambda |
-| Azure | Azure Functions |
-| GCP | Cloud Functions |
+| 特性 | 描述 |
+|------|------|
+| 无运维 | 云厂商管理服务器操作系统、运行时和安全补丁 |
+| 事件驱动 | 函数由事件触发，事件即资源状态的任何变化 |
+| 按需付费 | 仅在函数执行时计费（按调用次数和执行时长） |
+| 自动扩展 | 云厂商根据请求量自动水平扩展，无需人工干预 |
+| 内置安全 | 云厂商提供基础安全能力（网络隔离、IAM 权限控制） |

-## Benefits
+## Business Value

-### 1. Cost Efficiency
- Eliminates unnecessary resource consumption
- No idle capacity costs
- Pay only for actual execution time
+企业采用 Serverless 的核心驱动因素：
+- **更快上市时间**（Faster Time to Market）：开发团队专注业务逻辑，无需管理基础设施
+- **业务聚焦**（Business Focus）：将非核心运维任务外包给云厂商
+- **更低 TCO**（Total Cost of Ownership）：按需付费，空闲时零成本
+- **弹性扩展**（Elastic Scalability）：从零到百万并发自动应对
+- **内置安全**（Built-in Security）：云厂商持续更新安全补丁

-### 2. Scalability
- Automatic scaling from zero to thousands of instances
- Handles traffic spikes without provisioning
- Global distribution ready
+## AWS Serverless Ecosystem

-### 3. Developer Productivity
- Focus on business logic, not infrastructure
- Faster deployment cycles
- Reduced operational overhead
+AWS 提供完整的 Serverless 服务矩阵：

-## Use Cases
+| 服务 | 作用 | 关系 |
+|------|------|------|
+| [[AWS-Lambda]] | 无服务器计算核心 | 函数执行层 |
+| [[Amazon-API-Gateway]] | API 创建、发布、安全 | API 暴露层 |
+| [[AWS-Step-Functions]] | 工作流编排 | 流程编排层 |
+| [[Amazon-EventBridge]] | 事件总线 | 事件路由层 |
+| [[AWS-Fargate]] | 无服务器容器 | 容器层的 Serverless |
+| [[Amazon-DynamoDB]] | 无服务器数据库 | 数据持久层 |
+| [[SAM-Serverless-Application-Model]] | 本地开发和部署工具 | 开发工具层 |

-### Event-Driven Automation
- Real-time file processing
- Automated backups
- Scheduled tasks and cron jobs
+## Shared Responsibility Model

-### API Backends
- Microservices architecture
- Real-time data processing
- IoT data ingestion
+在 Serverless 环境中，AWS 与客户共担运维责任：

-### AI/ML Inference
- On-demand model inference
- Image and video processing
- Natural language processing
+- **AWS 负责**：基础设施、服务器硬件、网络、运行时环境、安全补丁、负载均衡、自动扩展
+- **客户负责**：业务代码、依赖管理、权限配置（IAM）、应用程序级别的安全

-## Relationship to Green Computing
- Serverless computing contributes to [[Green Computing]] by:
-  - Eliminating idle resource consumption
-  - Optimizing energy efficiency through shared infrastructure
-  - Reducing data center carbon footprint
+## Event-Driven Architecture Connection
+
+Serverless 天然契合 [[Event-Driven-Architecture]] 模式：
+
+1. **事件源**（Event Source）：S3、API Gateway、EventBridge、DynamoDB Stream 等
+2. **事件路由器**（Event Router）：EventBridge、SNS 等筛选和路由事件
+3. **Lambda 函数**（Function）：消费事件，执行业务逻辑
+4. **下游服务**（Downstream）：DynamoDB、SQS、SNS 等处理结果

 ## Related Concepts
- [[Cloud-Native]]
- [[Green Computing]]
- [[Event-Driven-Architecture]]
- [[Edge-Computing]]
-
-## Related Entities
- [[AWS Lambda]]
- [[Azure Functions]]
- [[Google Cloud Functions]]
+- [[Event-Driven-Architecture]] — Serverless 的天然执行模型
+- [[Lambda-Permissions-Model]] — Serverless 函数的安全权限模型
+- [[Cloud-Transformation-Programme]] — Serverless 是云转型的关键技术路径之一