Swift 的服务器支持如何驱动 Things Cloud
您可能熟悉 Things，这是一款令人愉悦的个人任务管理器，曾荣获两项 Apple 设计大奖，可在包括 iPhone、iPad、Mac、Apple Watch 和 Apple Vision Pro 在内的 Apple 设备上使用。在 Cultured Code，即 Things 背后的团队，我们非常关注产品各个方面的出色用户体验。这延伸到我们的服务器后端，在经过重写后，我们的 Things Cloud 服务已完全过渡到 Swift。在过去一年的生产中，Swift 始终被证明是可靠、高性能且非常适合我们服务器端需求的。
Things Cloud 作为应用程序体验的支柱，在设备之间静默同步待办事项。这项工作的稳健性由严谨的理论基础保证，其灵感来自操作转换和 Git 的内部原理。经过十二年的生产，Things Cloud 赢得了用户对其可靠性的信任。但是，尽管架构本身具有持久的优势，但技术堆栈却落后了。
切换到 Swift
我们旧的 Things Cloud 服务构建于 Python 2 和 Google App Engine 之上。虽然它很稳定，但它也存在越来越多的局限性。特别是，响应时间慢影响了用户体验，高内存使用量推高了基础设施成本，而 Python 缺乏静态类型使每次更改都具有风险。为了使我们的推送通知系统快速，我们甚至不得不开发一个基于 C 的自定义服务。随着这些问题积累以及一些弃用迫在眉睫，我们意识到我们需要做出改变。
完全重写通常是最后的手段，但在我们的案例中，这是 Things Cloud 唯一可行的途径。我们探索了各种编程语言，包括 Java、Python 3、Go，甚至 C++。然而，Swift——它已经是我们客户端应用程序的核心组成部分——因其潜力和独特的优势而脱颖而出。Swift 承诺提供卓越的性能、通过 ARC 实现可预测的内存管理、用于可靠性和可维护性的富有表现力的类型系统以及与 C 和 C++ 的无缝互操作性。
虽然我们最初担心 Swift 的服务器支持不如其他生态系统那样成熟，但 Apple 和开源社区都对它的发展表现出了坚定的承诺。长期以来，Swift 在 Linux 上可靠地编译；自 2016 年以来，Swift 服务器工作组一直在协调服务器工作；SwiftNIO 库 让我们对基础功能充满信心，而 Vapor 提供了让我们快速启动和运行的所有工具。
确信这些优势以及使用相同语言进行客户端和服务器开发的机会，我们开始了为期三年的 Things Cloud 重写之旅。我们在过去两年中一直在内部使用它，现在已在生产环境中运行一年多。
新的基于 Swift 的服务架构
我们将概述我们新的服务架构的核心组件，重点介绍我们使用的 Swift 软件包。我们发现这些组件协同工作良好，可提供可靠性和稳定性，并且我们相信这可以为考虑类似 Swift 过渡的其他人提供有价值的参考。
代码
- 我们的 Swift 服务器代码库大约有 30,000 行代码。它生成一个 60 MB 的二进制文件，并在十分钟内构建完成。
- 它使用 Vapor 作为 HTTP Web 框架，Vapor 使用 SwiftNIO 作为其底层网络应用程序框架。
- 我们从 Swift 源代码编译一个“单体”二进制文件，但使用它来运行多个服务，每个服务都通过在运行时传递不同的参数进行配置。
- 我们使用 Xcode 及其强大的开发、调试和测试工具套件。它为我们提供了跨服务器和客户端环境的熟悉且一致的体验。
部署
- AWS 托管着我们的整个平台，并且完全由基础设施即代码工具 Terraform 管理。
- 我们使用持续集成管道来自动化测试并将我们的 Swift 代码构建到 Docker 镜像中。然后将其与其他组件一起部署在 Kubernetes 集群中。
- HAProxy 负载均衡器用于将客户端流量路由到集群中适当的 Swift 服务。
存储
- 持久数据存储在关系数据库 Amazon Aurora MySQL 中，我们使用 MySQLKit 连接到它。
- 为了保持数据库的小型化，我们将不太常用的数据卸载到 S3，我们通过 Soto 软件包访问 S3。
- 更短暂的数据（例如推送通知和缓存）存储在内存键值数据库 Redis 中，我们通过 RediStack 访问 Redis。
其他服务
- APNSwift 软件包用于与 Apple 推送通知服务通信。
- AWS Lambda 是一种无服务器计算服务，为我们的 Mail to Things 功能提供支持。此过程以 Python 3 编写，因为它具有用于处理传入电子邮件的成熟库。结果使用 Amazon Simple Queue Service 传递到 Swift。
监控
- 我们非常重视 Things Cloud 的弹性，并竭尽全力确保其弹性。
- 在 Swift 中，我们使用自己的记录器生成 JSON 日志。为了生成指标，我们使用 Swift Prometheus。
- 我们使用 Amazon CloudWatch 来存储和分析日志和指标。它触发事件，并通过 PagerDuty 将事件发送给负责的工程师。
- 为了测试我们的服务从瞬时错误中恢复的能力，我们采用了混沌测试。每天，我们自己编写的混沌代理都会执行随机的破坏性操作，例如终止 Swift 服务或重启数据库。然后，我们验证系统是否按预期恢复。
结果
我们希望在新 Swift 服务架构部署到生产环境之前，对其性能和稳定性进行全面测试。因此，在开发阶段，我们将新系统与现有旧系统并行部署。虽然旧系统继续作为所有请求的运营服务，但新系统也使用自己的逻辑和数据库独立处理这些请求。
这种方法使我们能够在真实世界的条件下开发和测试新系统，而不会对用户体验造成任何风险。由于我们通过使用生产工作负载评估新系统，从而对新系统的稳健性和可靠性建立了信心，因此我们能够从一开始就部署一个强化的系统。
现在，经过一年多的生产，我们很高兴地报告 Swift 实现了其对服务器端开发的承诺。它速度快且内存效率高。我们的 Kubernetes 集群包含四个实例，每个实例具有两个虚拟 CPU 和 8 GB 内存，并且已处理高达每秒 500 个请求的流量峰值。与旧系统相比，此设置使计算成本降低了三倍以上，同时响应时间也大大缩短。
还有一个额外的收获：Swift 出色的性能使我们能够用基于 Swift 的服务替换我们自定义的基于 C 的推送通知服务；这大大简化了我们的代码库和运营。
结论
事实证明，Swift 是服务器使用的绝佳选择。它实现了我们所期望的一切：我们现在正在使用一种现代且富有表现力的编程语言，代码运行良好且性能出色，并且 Swift 生态系统提供了我们所需的所有集成。经过一年的生产使用，我们没有遇到任何运营问题。
有关我们的旅程和经验的更多信息，您可能会喜欢我们在 ServerSide.Swift 会议上的 最近的演讲。
我们鼓励其他团队考虑将 Swift 用于面向服务器的项目。虽然我们选择进行完全重写，但逐步采用 Swift 也是一个有趣的选项，特别是考虑到最近宣布的旨在 增强 Java 互操作性 的计划。
对于我们而言，我们相信我们的服务器架构处于有史以来最佳状态，并且我们对能够在这个坚实的基础上构建的新功能感到兴奋。