谎言 2：微服务提高开发速度

当你采用“关注点分离”公理并将其应用在开发人员头上时会发生什么？你会得到一些孤立的团队，他们之间各自独立。从表面上看这似乎是有益的。如果团队只需要操心自己的服务，那将减轻他们的认知负担，并提高他们的生产力。现在，工程师无需担心基础架构中其他部分的复杂性了。

问题在于，大多数新功能都需要一些跨多个服务的补丁。

许多功能需要在两个或多个服务上开发

开发多服务功能需要在具有不同优先级和能力的团队之间安排大量会议。考虑到他们从事的多个不同项目，这些团队可能需要异步协作。你现在还需要交付经理来分配工作和管理迭代。

从技术角度来看，实现多服务功能可能需要编辑多个存储库。至少，它需要一种方法来测试在多个服务上运行的代码。

对许多公司而言，这种多服务测试的需求是事后才会意识到的。架构师在设计技术栈时会假设大多数开发工作都将在单个服务上进行。多服务功能将很少见。你如何手动测试多服务功能？你需要在机器上启动多个容器，并仔细设置每个容器的状态。那单元测试呢？你将在哪里对多服务功能进行单元测试？是仓库A还是仓库B？文档写好了吗？部署往往会破坏未调整好的服务。很容易想象，数据流中的一个小错误会破坏多个下游服务。我们应该期望工程师理解所有可能依赖其代码的下游服务吗？

如果你的组织没有投入大量的工程资源来构建多服务测试流程，那么除了最常见的功能之外，开发新功能的速度会像蜗牛般缓慢。如果没有质量测试框架，看似简单的任务（例如“添加分页”）也可能会变成历时数月、跨多个团队的工作。