快速部署实践：用分布式系统方法提升开发者生产力

在微服务架构下，开发者本地环境往往需要启动大量服务，导致环境准备时间变长、调试成本上升，并直接影响开发者生产力。本文以某海外大型互联网公司的快速部署实践为例，介绍其如何通过代理、Cookie、共享集成环境和请求路由机制，让开发者只在本地部署自己修改的服务，从而提升迭代效率，并更好地支持持续集成和主干开发。

对于希望系统性提升研发效能的团队来说，快速部署只是研发流程优化中的一个环节。真正可持续的效率提升，还需要将团队目标、需求评审、开发协作、测试验证、发布上线和知识沉淀串联起来。PingCode 这类智能化研发管理工具，能够覆盖研发全生命周期管理，并打通研发过程中使用的多类工具，让研发数据在不同环节之间顺畅流转，从而帮助团队更好地衡量和提升研发效能。

某海外大型互联网平台的网站由多个服务组成，例如用户资料数据服务、公司数据服务和群组数据服务等。在生产环境中，每个服务都独立部署，并通过定义清晰的 API 与其他服务通信。

在开发过程中，该公司的工程师过去通常会把所有服务都部署到本地机器上。随着业务快速发展，服务数量不断增加，在开发者本地启动完整技术栈所需的时间也越来越长。

对开发者来说，理想的微服务本地开发模式是：只在本地部署自己实际修改的服务。一次内部黑客马拉松项目中，几位工程师合作验证了这种模式的可行性，并将该项目命名为“快速部署”。本文将介绍团队如何借助分布式系统思路实现快速部署，过程中遇到了哪些问题，以及这一方案推广到整个工程团队后带来了哪些收益。

快速部署的设计思路

大多数情况下，开发者只会修改少数几个服务。因此，我们的目标是：这些服务应当是开发者唯一需要在本地部署的服务。除此之外，其他所有服务都应部署在外部共享环境中。

主要难点在于如何正确路由请求。假设许多开发者都在使用同一个共享环境，而每个开发者又在本地部署了自己修改的一部分服务，那么系统该如何判断每个请求应该被发送到哪个服务？

我们的解决方案是使用代理和 Cookie。团队在早期集成环境的数据中心中设置了代理，该环境部署了平台的所有服务。这些服务会定期更新和重新部署，因此始终运行较新的代码。无论服务部署在早期集成环境，还是部署在开发者本地服务器上，所有请求都会先路由到这个代理。

使用快速部署时，开发者的工作流程如下：

设置路由配置。 路由配置用于指定哪些服务部署在本地。开发者可以通过一个简单的 Web 界面创建路由配置，并将其存储在浏览器 Cookie 中。

使用代理服务器。 为了进行测试，开发者会将浏览器指向早期集成环境中的代理服务器。

由代理完成请求路由。 代理会根据 Cookie 中的路由配置，将请求路由到早期集成环境，或转发回开发者本地服务器。代理还会确保这些路由信息被传递给所有下游服务，从而让服务之间的请求也能被正确路由。

微服务本地开发中的请求路由示例

假设你正在开发一个典型的三层架构应用：前端负责渲染用户界面，中间层负责处理业务逻辑，数据服务负责数据库读写。

现在，你想修改中间层，于是将中间层部署到本地，并将其添加到路由配置中。当你在用户界面上点击测试服务时，请求的路由过程如下：

首先，浏览器向代理服务器发出请求，访问前端服务。

前端服务不在你的路由配置中，因此代理会将请求发送到部署在早期集成环境中的前端服务。

前端服务需要从中间层获取信息，因此会向代理发送请求。

由于这个请求中也包含你的路由配置信息，代理知道应该将请求路由到部署在你本地开发服务器上的中间层。

你的本地中间层需要从数据服务获取数据，因此又向代理发送另一个请求。

数据服务不在你的本地路由配置中，因此代理会将请求路由到早期集成环境中的数据服务。

最后，数据服务响应中间层，中间层响应前端，前端再将 HTML 返回给浏览器。

通过这种方式，开发者只需要在本地运行自己正在修改的服务，其余服务都可以继续使用共享环境中的版本。

问题一：共享数据导致测试相互干扰

当团队开始向更多工程师推广快速部署时，遇到了一些技术问题。其中一个问题是：工程师们共享同一个数据库。

团队创建了一批测试账号，供所有工程师在测试代码时使用。但在准备网站某个多语言版本上线时，这种共享数据模式带来了麻烦。例如，当某位工程师将某个测试用户的语言设置为另一种语言时，其他正在使用同一个测试用户的开发者就会受到影响。

这个问题的解决方案相对简单：创建更多测试账号。这样，每位工程师都可以拥有自己的一组测试用户，从而减少相互干扰。

问题二：异步通信缺少路由上下文

还有一些服务采用异步通信方式，例如执行定时任务的服务，以及使用消息队列发送消息的服务。

这类通信之所以被称为“异步”，是因为它发生在用户触发的请求—响应周期之外。也就是说，这些异步请求中并不会天然包含带有路由配置信息的 Cookie。这可能导致不可预测的行为，因为本地部署的服务可能会与部署在共享集成环境中的服务发生冲突。

以消息队列为例，队列中的一条消息最多只能被一个消费者消费。如果同一个消费者同时部署在本地和共享集成环境中，就无法确定某条消息最终会被哪个消费者处理。

解决这个问题的方法是：将相关异步组件，以及受变更影响的一组服务，都部署到本地。例如，如果某次修改会影响一组特定的消息，那么开发者需要将这组消息相关的生产者、消费者，以及自己的消息队列实例都部署在本地。

这样一来，本地部署的服务只会从本地队列消费消息，共享集成环境中的服务也只会从共享集成环境的队列消费消息，两者之间就不会发生争用。

快速部署如何提升开发者生产力

随着问题不断被修复，团队开始将快速部署推广给越来越多工程师，并计划在年底前让所有工程人员都使用这一能力。这个最初只是内部黑客马拉松项目的功能，如今已经为整个公司带来了显著收益。

在这类跨团队推广过程中，技术方案之外的任务拆解、项目推进、文档沉淀、沟通同步和审批流程同样关键。Worktile 这类通用项目协作系统，可以承接任务、项目、文档、即时沟通、目标、日历、甘特图、工时和审批等协作场景，帮助团队降低复杂工程项目推广过程中的沟通成本。

迭代速度更快。 工程师只需要部署自己正在修改的服务，其他所有服务都由中央共享环境统一管理并保持更新。这为每个项目节省了大量时间。

更早使用大规模数据进行验证。 在快速部署之前，由于开发环境资源有限，本地数据库只能加载规模很小的测试数据集。只有当代码部署到预发布环境之后，团队才能使用完整规模的数据集进行验证。借助快速部署，共享集成环境中的服务可以部署在大量机器上，因此开发者能够更早使用更大的数据集，从一开始就发现性能和可扩展性问题。

更好地支持持续集成。 过去，功能通常会先在本地开发环境中开发和测试，直到发布前不久才与其他项目集成。随着工程流程逐步迁移到快速部署和主干开发模式，所有项目都可以在整个开发周期中持续进行集成测试。

总结：微服务快速部署的核心价值

快速部署的核心思路并不复杂：开发者只在本地运行自己需要修改的服务，其余服务则复用共享环境中的最新版本。真正的难点在于如何通过代理、路由配置和请求上下文，让分布式系统中的每个请求都能找到正确的目标服务。

在服务数量不断增长、微服务架构日益复杂的背景下，这种方式显著减少了开发者本地环境的启动和维护成本，也让团队能够更早发现集成、性能和扩展性问题。

对大型工程组织而言，开发者生产力并不只取决于单个工具的速度，而取决于整套研发流程能否减少无效等待、降低环境复杂度，并让工程师更专注于真正需要修改和验证的代码。快速部署正是这种思路的一次有效实践。