1.3.2　开发速度

在微服务架构中，工作可以比较容易地拆分到多个团队。举例而言，团队A可以创建一个独立的微服务，专注于业务功能的开发。与此同时，团队B在业务领域的另一个部分开展工作。这两个团队能互不干扰地独立工作，并可由此进行快速的迭代开发。

采用微服务架构，团队之间不需要在代码库层面进行协作。各团队可以按照自己的需求选择技术栈，快速演进开发。加入团队的新成员也不需要掌握整个业务领域的内容，只需要了解其团队负责的部分领域，这样可以更容易地理解系统，快速开展工作。

由于每个团队都能独立地部署自己的代码库，部署流程会更健壮。所有这一切的结果是部署的频度会越来越高，风险也越来越小。即使团队偶然引入了某些缺陷，对部署的影响也比较小。因为变更的内容少，调试定位潜在问题也更快。调试过程中可能遇到困难，譬如多个细粒度的微服务集成时报错。在这种情况下，我们需要进行请求跟踪，收集多个微服务之间的请求调用关系。

与此相反，在单体系统中，多个团队的成员经常要共享同一个代码库。如果某应用的代码存放在某个代码库中，由于应用比较复杂，多个团队同时在这个代码库上开展工作。这种情况下，你很可能遇到代码冲突的情况。一旦出现这种情况，大量的开发时间都会消耗在解决这些冲突上。当然，如果产品代码能够以模块化的方式组织，在一定程度上可以降低冲突的概率。然而，随着越来越多开发者的加入，产品主分支上的变更会越来越频繁，你也不得不隔三岔五地做代码同步。对比单体系统和微服务架构，我们很容易发现固定业务领域的代码通常少得多。因此，采用微服务架构时出现代码冲突的概率小得多。

单体应用的部署一般不太频繁，主要原因是每次部署都需要向主分支合并大量的功能代码（因为有更多的人在其上开展工作）。功能越多，完成相关测试所需的时间越长。同一个版本包含的功能越多，引入缺陷的概率越大。值得一提的是，通过创建稳定的持续集成（或者持续部署）流水线，这些痛点在一定程度上可以得到缓解。我们可以通过更频繁地运行这些流水线，更快速地构建新应用，从而让每个新版本包含更少的新功能。如果新版本代码引入了缺陷，这样也将更易于分析和调试。版本中包含的新功能越少，定位潜在问题的速度越快。如果我们做一个对比，即在同样的时间内，在一个发布周期中将频繁构建新应用与不频繁构建新应用的方式做比较，会发现前一种情况下发布最终部署到生产的特性数比后一种情况要多得多。一个版本包含的功能越多，潜在的问题越多，也越难调试。