dacadoo 是一家总部位于瑞士的全球性技术公司，致力于开发数字健康参与和健康风险量化解决方案。其产品包括基于软件即服务（SaaS）的数字健康参与平台，该平台利用行为科学、AI 和游戏化来帮助最终用户改善健康结果。
该公司开启了一段现代化之旅，将用于量化健康与生活方式数据的 API（应用程序编程接口） 以及基于多年科学研究数据计算死亡率和发病率概率的风险引擎进行现代化改造。
为了将基于虚拟机的 API 服务转变为全球冗余、可扩展的健康评分和风险计算解决方案，dacadoo 选择了 Amazon Web Services（AWS）技术。该服务处理来自全球客户群的高度敏感健康数据，并且必须遵守各地区的法规。
最终实现了 78% 的成本降低，以及每年不到一小时的基础设施维护工作量，这得益于高度自动化和敏捷思维，使 dacadoo 能够在不扩充站点可靠性工程（SRE）团队的情况下交付和运营更多 AWS 基础设施。
在本文中，我们将逐步介绍 dacadoo 拥抱托管服务的历程，并在此过程中重点说明他们的架构决策。
背景
该解决方案架构经历了三个阶段：
孵化阶段——本地单台虚拟机，并在瑞士设有灾难恢复（DR）
全球化和可扩展——多个全球 Kubernetes 集群
卓越运营——在 AWS 上完全无服务器且地理冗余
阶段 1：使用虚拟机进行孵化
经过多年的科学研究和开发，该服务正式上线，运行在一台本地虚拟机上，该虚拟机使用 hypervisor 技术提供灾难恢复（DR）。然而，它不具备高可用性（HA）能力，并且需要手动恢复。
处理 API 请求的应用程序和 NoSQL 数据库都运行在同一台主机上。软件部署和操作系统维护通过 Secure Shell (SSH) 手动执行——这是一种典型的低自动化配置，还伴随着停机时间。
以下架构图展示了一台包含单体应用程序及其数据库的虚拟机。
挑战
单台虚拟机搭建快捷且运营成本低廉，但存在相当大的缺陷。健康 API 仅在瑞士可用，基础设施维护手动执行，软件部署也手动处理。此外，数据库备份通过虚拟机快照完成，仅有正常运行时间监控，测试在开发者工作站上进行。
阶段 2：基于 Kubernetes 的全球化与可扩展架构
当时，dacadoo 做出了一项战略决策，大力投资 Kubernetes 以在全球范围内管理容器化工作负载。作为该技术推广的一部分，健康评分和风险服务被迁移至 Kubernetes。
由于客户群地理分布广泛且对低延迟有要求，部署了三个 Kubernetes 集群，每个大洲一个。NoSQL 数据库托管在工作负载附近，以降低服务延迟并保持较低的迁移工作量。
为减少运维维护，NoSQL 数据库以 SaaS 形式集成，监控通过 Datadog 集中管理。
所有云基础设施均通过 Terraform 独家配置，涵盖 Kubernetes 集群、NoSQL 数据库以及与 GitLab 和 Datadog 的集成。
dacadoo 将 API 服务容器化，并使用 Gitlab 持续集成和持续部署 (CI/CD) 流水线在全球超大规模云服务商上部署多个环境和集群。
回顾来看，这是一个典型的从虚拟机到 Kubernetes 的重新平台化现代化项目，具有高度自动化和 SaaS 优先的方法。
下图是使用托管 NoSQL 数据库的容器解决方案架构。
挑战
该服务面临多项挑战，包括在三个环境中部署三个区域 Kubernetes 集群导致的成本增加，产生了 27 个集群节点，以及为每个集群管理 NoSQL 数据库 SaaS 实例带来的额外费用。多环境多集群部署的 CI/CD 流水线复杂性也增加了难度。需要投入大量运维工作来保持基础设施和 Kubernetes 组件的最新状态。
阶段 3：使用无服务器实现卓越运营
基于 Kubernetes 的架构满足了需求，但 dacadoo API 服务待办事项中的一些功能需要更好地适应当时的应用架构。
这正是从整体视角审视基础设施和软件架构，并根据最新的 AWS 技术和最佳实践重构解决方案的恰当时机，也是 dacadoo 工程团队的下一个前沿方向。
解决方案需求
解决方案重构的需求如下：
保持 API 功能不变
将数据处理限制在选定的区域内，以符合当地数据保护法律
通过仅使用托管无服务器服务来避免每周补丁周期
通过选择按需付费计费模式的服务来降低成本
将身份验证委托给专用服务
使用具有丰富生态系统的成熟 Web 框架
重构应用
API 服务有两个组件：开发者门户和健康评分与风险计算 API。数据库仅用于 API 密钥、算法参数、配额和使用统计数据。健康数据由计算层在区域内处理但不持久化，这为分布式数据库打开了大门：Amazon DynamoDB 全局表是该解决方案的完美选择。写入操作分发到所有连接的区域，而读取操作在本地进行，为遵守 dacadoo 服务等级协议（SLA）提供了低延迟。
开发者门户是一个包含 API 文档和 API 密钥管理功能的 Web UI。AWS Lambda 非常合适，因为它可以自动扩展并具有按请求计费的计费模式。
健康和风险 API 使用 C 编程语言实现的算法进行短时突发、计算密集型模拟。这些调用由使用 Python FastAPI 框架的 REST API 封装。这些特性使 AWS Lambda 成为理想选择。
无服务器架构
HTTP 请求通过 Amazon API Gateway 路由到 Lambda 函数，并使用 AWS WAF 防护恶意请求和攻击。静态资源通过 API Gateway 从 Amazon Simple Storage Service（Amazon S3）存储桶提供。不需要 Amazon CloudFront 的额外功能，Amazon S3 降低了复杂性。
Amazon Route 53 提供了一项强大的功能，称为基于延迟的路由，它允许将 DNS 查询定向到为请求者提供最低延迟的终端节点。
此功能为没有数据处理位置要求的 API 用户提供区域高可用性。或者，用户可以调用特定的区域终端节点，以确保请求在所需的区域中处理。
API 授权基于 HTTP 标头，并在应用程序中执行，数据存储在 Amazon DynamoDB 中。
下图是地理冗余全无服务器解决方案的架构。
由于 dacadoo 的 SRE 团队精通 Python，他们选择了 Pulumi，因为它具有编程语言流控制结构、强大的配置能力和多云支持等高级功能。
对于持续集成，GitLab CI 编译算法库、测试 FastAPI 应用程序并打包所有内容。应用程序部署只是更新 AWS Lambda，这是一个简单可靠的工作流。
总结
该解决方案从托管基础设施设置（客户承担大部分责任）演变为 AWS 托管服务架构。
基础设施配置从手动、容易出错的过程演变为 Pulumi 中强大的代码驱动工作流。SRE 需要增强其软件工程技能以采用 Pulumi，从基于配置的方法过渡到使用面向对象的 Python 设计和维护基础设施代码库。这是 dacadoo 对 SRE 团队投资和更广泛现代化努力的一部分。无服务器架构促成了专注于生产力的 GitOps 工程文化。
该转型最大化了可扩展性和可用性，同时降低了成本和运营工作量：
可扩展性：低
可用性：尽力而为
基础设施成本：低
维护工作量：高
可扩展性：高
可用性：99.95%
基础设施成本：高
维护工作量：中
可扩展性：非常高
可用性：99.999%（可故障转移至另一个 AWS Region）
基础设施成本：低
维护工作量：非常低
全局冗余将可用性提升至令人印象深刻的 99.999%，同时保持低成本。
结论
从虚拟机迁移到 Kubernetes（容器编排平台），并最终迁移到 AWS Lambda，展示了云工程在提升效率和可扩展性方面的发展历程。
这一旅程中的每一步都降低了资源管理的复杂性，同时提高了灵活性和自动化程度。将 dacadoo 的 API（应用程序编程接口）服务迁移到完全无服务器、地理冗余的架构，不仅提升了平台能力，还提升了工程师的技能，维持了精简的 SRE 团队，并保持了较低的基础设施成本。开始使用您自己的 AWS 无服务器解决方案吧。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文作者：AWS Architecture Blog；如有侵权，请联系管理员删除。
