本书讲述了什么

后端开发领域广阔无垠。

你所处的环境对解决当前问题的最佳工具和实践有着巨大的影响。

例如，基于主干的开发方式非常适合编写在云环境中持续部署的软件。 同样的方法可能不太适合销售由客户托管和运行的软件的团队的业务模式和面临的挑战——他们更有可能从 Gitflow 方法中受益。 如果你是独自工作，可以直接推送到主干。 在软件开发领域，很少有绝对的事物，我认为在评估任何技术或方法的优缺点时，阐明你的观点是有益的。

“从零到生产”将重点关注由四到五名经验和熟练程度各异的工程师组成的团队编写云原生应用程序所面临的挑战。

云原生应用程序

定义 云原生应用 本身就足以写一本新书了[1]。与其规定云原生应用应该是什么样子，不如明确规定它们应该做什么。 借用 Cornelia Davis 的话来说，我们期望云原生应用：

• 在易发生故障的环境中运行时实现高可用性
• 在发布新版本的时候实现零停机
• 处理动态工作负载(workload)

这些要求对我们软件架构的可行解决方案空间有着深远的影响。

高可用性意味着，即使我们的一台或多台机器突然出现故障(云环境中的常见情况[2])，我们的应用程序也应该能够在不停机的情况下处理请求。

这迫使我们的应用程序必须分布式运行——应该在多台机器上运行多个实例。

如果我们想要处理动态工作负载，情况也是如此——我们应该能够衡量系统是否负载过重，并通过启动新的应用程序实例来投入更多计算资源来解决问题。这还要求我们的基础设施具有弹性，以避免过度配置及其相关成本。

运行复制应用程序会影响我们的数据持久化方法——我们将避免使用本地文件系统作为主存储解决方案，而是依靠数据库来满足我们的持久化需求。

因此, 《从零到生产》将广泛涵盖那些看似与纯后端应用程序开发无关的主题。但云原生软件的核心在于彩虹 (Rainbow [3]) 和 DevOps，我们将花费大量时间讨论传统上与操作系统技术相关的主题。

我们将介绍如何对 Rust 应用程序进行检测，以收集日志、跟踪和指标，以便能够观察我们的系统。

我们将介绍如何通过迁移设置和改进数据库架构。

我们将涵盖使用 Rust 解决云原生 API 第一天和第二天问题所需的所有材料。

• [1]: 就像 Cornelia Davis 的优秀云原生模式一样！
• [2]: 例如，许多公司在 AWS Spot 实例上运行软件，以降低基础设施成本。Spot 实例的价格是通过持续竞价确定的，可能比按需实例的全价便宜得多(最高可便宜 90%！)。但有一个问题：AWS 可以随时停用您的 Spot 实例。您的软件必须具备容错能力才能利用这一机会。
• [3]: 源书并没有这个注解, 关于什么是彩虹部署可以参考这个

和团队一起工作

这三个需求的影响超越了我们系统的技术特性：它影响着我们构建软件的方式。

为了能够快速向用户发布应用程序的新版本，我们需要确保我们的应用程序能够正常运行。

如果您正在独立开发一个项目，您可以依赖您对整个系统的透彻理解：您亲子编写了它，它可能很小，但是你随时可以回想起它的细节。[3] 如果您在团队中开发一个商业项目，您经常会遇到一些代码，这些代码既不是您编写的，也不是您审核的。原作者可能已经不在了。

如果您依赖于对代码功能的全面理解来防止代码崩溃，那么每次要引入更改时，您最终都会被恐惧所麻痹。(译者注: 俗称不敢动代码)

您需要写自动化测试。

在每次提交时自动运行。在每个分支上运行。保持 main 分支健康。

您需要利用类型系统使不良状态难以或无法表示。

您希望使用您掌握的所有工具，赋能团队中的每一位成员，让他们能够开发该软件。

即使他们可能不如您经验丰富，或者对代码库或您正在使用的技术不那么熟悉，他们也能全力投入开发过程。

因此，“从零到生产”项目从一开始就将重点放在测试驱动开发和持续集成上——我们甚至在启动和运行 Web 服务器之前就会设置 CI 流水线！

我们将介绍 API 的黑盒(black-box)测试和 HTTP mocking 等技术——这些技术在 Rust 社区中并不流行，文档也并不完善，但却非常强大。

我们还将借鉴领域驱动设计领域 (Domain Driven Design)的术语和技术，并将它们与类型驱动设计 (type-driven design)相结合，以确保系统的正确性。

我们的主要关注点是企业软件：写足以对领域进行建模的代码，并且支持长期演化。 (注: 就是说为未来考虑, 追求可维护性)

因此，我们会偏向于那些枯燥无味且正确的解决方案，即使它们会带来性能开销，而这些开销可以通过更谨慎、更精妙的方法进行优化。 先让它运行起来，然后再进行优化(如果需要)。