Uber臭名昭著地运行着成千上万的微服务。他们之所以拥有如此之多的服务，是因为数百名工程师希望按照自己的计划进行部署，清晰地拥有自己的代码，而不是在一个巨大的合并队列中等待。几十年来，一个由5或10人组成的小团队同时编写代码时甚至不需要考虑这样做。在一个忙碌的日子里，一个小团队可能会生成50个提交/20次推送/10个拉取请求。今天的一个小团队，如果同时运行20-100个代理，可能会生成500个提交/200次推送/100个拉取请求。因此，Uber在模块化方面的做法在当时可能显得极端，但它可能会成为新的常态。一个开发者以“单线程”方式编码，一次编辑一个文件：一个开发者以“多线程”方式编码，使用并行的编码代理：你的代码模块化程度越高，你可以运行的代理就越多。如果你有一个大型单体服务，每次更改都必须仔细协调，那么两项重大工作的内容很可能会互相干扰，迫使你解决合并冲突和重构。如果你像Uber一样拥有成千上万的微服务，你就有了一种“极其并行”的工作方式。为每个编码代理启动一个，告诉它“提高性能”，很有可能在所有服务中实现显著改进。100多个并行运行的编码代理必须独立良好地工作。如果它们一直花时间解决合并冲突、修复构建错误和应对部署噩梦，最终会导致整体生产力下降。模块化变得便宜了。拆分事物过去是非常昂贵的，因为每个服务意味着更多的样板、管道和持续集成配置。现在代理会写所有这些，因此开销变得不那么重要。代理也极其受限于上下文。一个足够小，能够适配上下文窗口的模块（无论是服务还是库）会显著提高编码代理的性能。你的代码库的模块化程度决定了你可以有效地并行运行多少编码代理，因此，从一开始就值得为此进行设计。