平台如何运作：从部署到故障恢复

在这场 2016 年的演讲中，Casey West 讨论如何让开发者在平台上运行源代码，而不必管理每个基础设施细节。他定义运营成熟的环境，并用 Cloud Foundry 演示这些理念。

他提出的第一项能力是动态 DNS、路由和负载均衡。部署或扩缩服务不应依赖一连串人工工单来修改网络和路由。

服务代理应能配置数据库、缓存和消息队列等后端服务，或提供对现有服务的访问。West 希望身份验证和连接信息由运行环境提供，而不是人工复制。

基础设施编排需要按需提供计算、存储和网络资源。他区分了仅仅可编程的基础设施与已经为应用团队部署好的自动化。

健康管理应检测机器或应用实例故障并执行恢复。自动恢复可以减少日常人工干预，但仍需要合理的容量规划和监控。

不可变制品仓库将构建应用与部署、运行分开。一个已知且可检查的制品可以反复快速启动，而无需每次扩容都重新构建应用。

集中式日志聚合让运维人员无需逐台搜索生产机器就能调查分布式应用。West 将这六项能力视为最低可行平台；不同组织还可能需要额外的安全和治理控制。

汽车需要多个子系统协同才能驾驶。同样，West 说仅有容器并不构成完整平台：基础设施、运维和可用接口必须协同工作。

2016 年的演示使用 Cloud Foundry 和 BOSH。West 将 BOSH 描述为分布式系统生命周期管理工具，将 Cloud Foundry 描述为带自动化服务的应用运行环境。这些是他对当时技术栈的描述。

示例 Ruby 服务使用 Sinatra 和 Puma，从环境读取端口与实例信息，并返回一段简单的 JSON。从环境读取配置有助于部署到不同实例。

West 使用 CF 命令行工具指定组织和空间并部署应用。命令行客户端与 API 通信，使同样的操作可以被自动化。

他演示路由和水平扩缩：多个实例运行在同一路由之后，平台在实例之间分配请求。日志被集中收集，运维人员无需连接每台机器即可查看应用行为。

修改后的应用增加一个由 Redis 支持、前端实例共享的访问计数器。由于缺少所需的 Redis 服务，应用最初失败，因此 West 一边创建依赖一边回滚。

他列出可用服务，创建 Redis 实例并将其绑定到应用。平台通过应用环境提供主机、端口和凭据；这个小型演示服务本身并不是高可用部署。

更改服务绑定后，正在运行的应用需要获得更新的环境信息。West 解释说，可以通过重启或滚动部署应用新的连接信息。

他尝试用插件进行蓝绿零停机部署：启动新的不可变版本，测试后将路由迁移过去。现场演示中，新版本无法连接 Redis，因此预期的平滑部署没有按计划成功。

检查应用配置后发现了服务绑定问题。重新绑定后，环境中出现了 Redis 连接信息。West 借此说明自动配置和凭据轮换，但实际安全性仍取决于平台配置。

为演示恢复，他部署了一个会使应用实例崩溃的端点。平台检测到故障、启动替代实例并调整路由；如果同时失败的实例过多，容量仍可能耗尽。

West 将云原生可运维性定义为在数月乃至数年中维护应用，而不只是部署一次。他看重微服务的独立扩缩和迭代，但警告说，如果没有自动交付，增加服务只会增加运维工作。

他将 DevOps 称为学习、度量、自动化和协作的文化。在他看来，微服务、持续交付和 DevOps 要有效，需要运营成熟的环境。

在问答中，他说最低能力集可能还需补充授权、加密和工作负载放置等要求。他还讨论平台部署选择，并区分应用与平台配置的服务。

West 认为稳健的分布式应用应预期故障，并视情况使用服务发现、负载均衡、缓存和熔断器等技术。合适的架构取决于具体环境，而不是某一个产品。