部署与基础设施

在真实系统中，只有源代码还不足以运行应用程序。它必须先被处理成系统可以执行的形式，例如编译后的二进制文件或打包后的服务。这个过程发生在构建阶段。

构建完成后，应用程序会被部署到服务器或云基础设施上。这一步包括设置运行时环境、配置以及系统正常运行所需的依赖项。

跳过这些步骤会导致行为不一致，也就是代码在一个环境中可以运行，但在另一个环境中却失败。这是生产问题最常见的原因之一。

为防止这种情况，现代系统会使用自动化流水线，持续地将代码推进构建和部署阶段。这样可以确保每次发布都遵循相同的流程，从而提高可靠性并减少人为错误。

在传统工作流中，部署软件是一个手动且容易出错的过程。开发者会编写代码，在本地测试，然后手动发布，这常常会导致生产环境中的不一致和故障。

CI/CD 流水线通过自动化整个流程来解决这个问题。在持续集成（CI）中，开发者会频繁将代码合并到共享仓库中。每次变更都会触发自动化系统，构建应用并运行测试，以便尽早发现 bug。

一旦代码通过所有检查，持续部署或交付（CD）就会接管。系统会根据配置自动将已验证的代码部署到预发布或生产环境。

这个流水线确保每次代码变更都经过相同且严格的流程。它在保持质量的同时提升发布速度，使团队能够自信且频繁地交付更新，而不会破坏系统。

部署应用程序时，最大的挑战之一是环境不一致。能在开发者机器上运行的代码，可能会因为操作系统、库或配置的差异而在生产环境中失败。

容器通过将应用程序与其运行所需的一切一起打包来解决这个问题，包括依赖项和运行时设置。这个包称为 Docker 镜像，它可以部署到任何存在容器运行时的地方。

当镜像被执行时，它就会变成一个容器——一个隔离的环境，无论运行在哪里，其行为都保持一致。这彻底消除了“在我机器上可以运行”的问题。

由于容器轻量且标准化，它们可以很容易地在许多服务器之间复制和分发。这使得应用扩展变得容易得多，并支持现代分布式系统架构。

运行单个容器很简单，但真实的生产系统会在许多服务器上运行数百甚至数千个容器。手动管理这件事并不现实。

Kubernetes 通过充当容器的控制系统来解决这个问题。你定义应用的期望状态，例如应该运行多少个实例，而 Kubernetes 会持续努力维持这个状态。

如果某个容器崩溃，Kubernetes 会自动替换它。如果流量增加，它可以启动更多容器。如果某台机器发生故障，它会把容器重新调度到健康的节点上。

这种抽象让工程师可以专注于定义系统行为，而不是手动管理基础设施，从而使大规模分布式系统更容易实际运行。

反向代理位于外部客户端和内部后端系统之间，作为应用基础设施的受控入口点。

应用服务器不会直接暴露给互联网，所有流量都会先经过反向代理。然后它会决定将每个请求路由到哪里，例如把 API 调用导向一个服务，把静态内容请求导向另一个服务。

它的一个关键作用是处理 TLS/HTTPS 终止。代理负责加密和解密，使后端服务器无需承担安全连接处理的开销。

反向代理还可以缓存经常请求的内容并压缩响应，从而减轻后端系统负载并提升用户的响应速度。

在实际应用中，Nginx 和 Envoy 等工具通常用于在现代后端架构中实现反向代理。

传统上，设置服务器、网络和数据库需要手动配置。这个过程速度慢、容易出错，而且很难在不同环境中保持一致地复现。

基础设施即代码（IaC）用代码来替代手动设置，这些代码定义了所需的基础设施。这包括服务器、网络规则、存储系统等。定义完成后，自动化工具可以以一致的方式完成所有资源的部署和配置。

由于基础设施是以代码形式编写的，因此可以存储在版本控制系统中，进行审查，并安全地更新。这使团队能够跟踪变更、回滚错误，并在开发、预发布和生产环境之间保持一致性。

像 Terraform 这样的工具通常用于实现 IaC，使工程师能够以声明式方式定义基础设施，并在大规模场景下自动应用这些配置。

生产部署架构不是单一工具，而是多个系统协同工作的组合。代码变更首先会经过 CI/CD 流水线，在其中完成构建、测试，并打包为容器镜像。

随后，这些镜像会部署到 Kubernetes 集群中，由它来管理容器如何在多台机器上运行。Kubernetes 通过处理扩缩容、故障和调度，确保系统保持稳定。

在集群前方，负载均衡器会将进入的流量分发到可用实例上，确保不会有单台服务器过载，并且即使某些组件发生故障，系统仍然可以访问。

这种分层架构使后端系统能够在大规模场景下可靠运行。每个组件都承担特定职责，组合起来就形成了一个能够处理真实流量、故障和持续更新而不受影响的系统。