不使用 EC2 或 Kubernetes：看 PostNL 如何构建纯 Serverless 架构

PostNL 分享了其从外包 IT 项目交付向内部产品交付能力转变过程中的一些见解和指导建议。通过采用以无服务器服务为主的云原生技术，该公司在生产效率和市场响应能力方面得到了显著提升，与此同时，在运营方面的成本也有所降低。

PostNL 是比荷卢经济联盟（比利时、荷兰、卢森堡）最大的物流公司，自 1799 年起开始运营。2012 年，该公司承诺实施 100% 云战略。随后，为了构建具有竞争力的物流软件，该公司决定将所有软件交付工作交由公司内部团队完成，而不再依赖现成的产品。

为了帮助构建所需的内部软件交付能力，公司领导层决定在标准化和最佳实践应用方面制定明确的指导原则和保障措施。同时，公司希望让工程团队参与进来，在标准和指导原则的制定方面发挥作用。并且，在不影响整体软件交付和云战略的情况下，工程团队在诸多领域都可以自由选择。

Luc van Donkersgoed 是 PostNL 的首席工程师，也是亚马逊云科技的 Serverless Hero。他介绍了他们在公司采用的企业框架内选择技术和工具解决方案的模式：

[……] 在 PostNL，技术、产品和服务按照 “固定、灵活、自由 ”的模式进行分类。在这种模式下，“固定”类包含在整个组织内已经标准化的主题。“灵活”类包含各种可供选择的产品、服务和标准。团队可以自由采用这个范围内的任何解决方案。“自由“类包含所有其他的主题。在这一类中，团队可以根据自己的预算、架构和经验自由决定使用什么解决方案。

在战略层面，PostNL 决定选择亚马逊云科技作为其公有云提供商，并且只使用云原生技术，特别是无服务器服务。为了执行这一决策，公司创建了亚马逊云科技平台团队，并命名为卓越云中心（CCoE），协助工程团队利用亚马逊云科技的云服务，同时也防止使用 EC2 等不受欢迎的服务。

该公司决定采用无服务器技术，这主要是考虑到公司应用程序工作负载的多变性，包括日模式和周模式，以及从 11 月黑色星期五开始到次年情人节结束的高使用率假期。PostNL 之所以选择在 AWS 上采用无服务器技术栈来满足业务需求，主要是为了利用亚马逊云科技的弹性定价、轻松扩展能力和云平台来解决最棘手的问题。

DynamoDB 的自动扩展能力（来自：PostNL 工程博客）

考虑到应用程序流量的多变性，PostNL 将 DynamoDB 作为其主要的数据库解决方案，并配置了自动扩展功能，以便可以根据负载情况扩展预配置的容量，同时又留有足够的余量来应对任何意外的流量激增。AWS Lambda 的轻松扩展能力也使得该公司大为受益，其调用次数每天都有波动，并且每月都有所不同。工程团队在 Lambda 中使用了多种语言技术栈，包括 TypeScript、C#、Rust 和 Python，尽管该公司也允许使用 Java 运行时。

Lambda 函数调用（来自：PostNL 工程博客）

PostNL 的无服务器架构还利用了亚马逊云科技的许多其他无服务器服务，包括 Step Functions、API Gateway 和 SQS。在特定情况下，当首选的无服务器选项无法满足需求时，团队也可以使用其他服务，如 RDS、Neptune、Timestream 或 Fargate。

从依赖外部合作伙伴转向内部开发团队并采用无服务器技术栈，PostNL 减少了管理费用，提高了生产效率，降低了运营成本。然而，这一转变也面临一些挑战，例如需要提高工程人员的技能并为初级开发人员提供支持。此外，考虑到构建无服务器解决方案的学习曲线，该公司选择了一种灵活的方法，允许团队使用 RDS 或 Fargate 等托管服务创建解决方案，而不是一成不变地纯粹使用无服务器选项。

在博文的最后，Luc van Donkersgoed 与希望采用无服务器技术的企业分享了自己的见解。作者建议，如果无服务器能够满足业务目标，就可以考虑采用无服务器，并且要从制定指导原则入手。他强调了基础设施配置、CI/CD、可观察性和安全性方面的自动化需求。此外，企业应该拥抱云平台，而不是仅仅局限于通过 lift-and-shit 方法来采用云，并且应该彻底分析其云架构的总拥有成本。最后，van Donkersgoed 强调了不断学习的重要性，尤其是考虑到云提供商提供新特性的速度。

查看原文链接：

https://www.infoq.com/news/2024/10/postnl-serverless-enterprise/