Serverless 六年后：架构、测试与取舍

在 YOW! 2022 上，Erwin van der Koogh 回顾六年的 serverless 开发，包括他的初创公司和在 Cloudflare 开发者平台的工作。他邀请听众质疑自己的结论。

他对 serverless 的个人定义强调事件触发代码、按使用量计费，以及无需管理服务器的扩缩容。他承认其他人可能有不同界定，实际服务也有自己的限制和计费细节。

典型执行过程接收并验证事件，可能获取额外数据，作出决定，然后保存或发送结果。他认为价值通常在于这一步如何连接系统的其他部分。

他将函数称为一个业务步骤，而不是把它视为通用可复用函数。共享逻辑仍可以放在库中；事件、配置和目标位置决定已部署步骤如何参与工作流。

一位听众问到松耦合。Van der Koogh 澄清，函数不必直接调用每个消费者：向总线发布事件可以让其他服务独立订阅。

对于 serverless 优先的应用，他首先考虑现有托管服务，其次考虑 serverless 代码，并在必要时使用容器。HTTP 请求等事件自然会引向事件驱动设计。

他描述了分别处理狭窄事件的小模块，并估计自己的许多函数大约有 50 至 150 行。这是他对自己代码库的观察，不是普适设计规则。

他说自己被收购的初创公司在没有他每天关注的情况下继续运行。这是关于特定系统的个案，并不意味着 serverless 应用不需要监控或维护。

他偏好的添加功能方式通常是为现有事件增加处理器，而不是修改事件生产者。例如，注册事件可以触发新的邮件工作流。

一位听众质疑增加代码不会扰乱生态系统的假设。新订阅者仍可能带来共享资源、顺序、安全或下游影响；讲者关于缩小影响范围的说法取决于具体设计。

替换行为时，他倾向于先增加并验证替代方案，再切换过去。目标是逐步改变，减少一次性修改现有路径的风险。

谈到测试时，他说会为可复用逻辑编写单元测试，但通常通过事件和集成来测试 serverless 函数。他引人争议的“不写单元测试”说法描述的是个人实践，而非通用测试标准。

他还介绍使用版本和功能开关在生产环境测试，把未完成的改动限制在开发者或选定的内部测试账户。他将这种做法与把未经测试的改动开放给所有客户区分开。

这家初创公司没有预发布环境；他说团队试图通过隔离、监控和可观测性使生产测试安全。一位听众问如何避免污染生产数据，他解释了使用可丢弃内部账户的做法。

他澄清开发者会先在本地测试再进入生产。另一个问题指出真实的失效方式：功能开关中的错误可能让非目标客户看到改动。他说团队尽量保持路由规则简单，但这不能消除风险。

被问到同行评审时，他说这家小型初创公司没有要求每次修改都经过评审，并明确表示不建议所有人照搬。团队规模、后果和组织环境都很重要。

一位参与者质疑这些做法能否扩展。他区分自己的小型初创公司与 Cloudflare，并说后者的团队在更大系统中使用单元测试、生产测试和预发布环境。

听众问，推迟防护措施是否可能导致以后难以补建。他说团队应随着复杂度增长作出调整，并保持可逆性；他提到基础设施模板本可以帮助自己的初创公司增加预发布环境。

对于安全关键系统，他认为受控的生产发布可以发现预发布环境遗漏的问题。这不能取代特定安全关键场景所需的验证、隔离和独立防护。

托管平台把部分运维责任转移给供应商，但发生故障时，应用团队可能依赖供应商恢复。运维更简单也伴随着依赖方面的取舍。

他认为最大的财务收益可能是让人们专注产品差异化，而不是维护基础设施。云账单可能降低，但这不是他的主要观点。

按使用量计费可以让单次操作的成本更容易估算，从而支持定价决策。实际支出不一定与收入线性增长：流量、重试、存储、出站流量和价格都可能独立变化。

展望未来，他预测 serverless 与软件即服务平台会更紧密结合，通过 API 和 webhook 提供可配置的业务工作流。他以 Shopify 作为更高层业务平台的例子。