1.1.4　为什么要改变构建应用的方式

习惯于为当地市场服务的公司突然发现，他们可以接触到全球的客户群，不过，更大的全球客户群也带来了全球竞争。更多的竞争影响了开发人员构建应用程序的方式。

● 复杂性上升。客户期望一个组织的所有部门都知道他们是谁。与单个数据库通信并且不与其他应用程序集成的“孤立的”应用程序已不再是常态。如今，应用程序需要与多个服务和数据库进行通信，这些服务和数据不仅位于公司数据中心内，还位于外部互联网服务供应商内。

● 客户期待更快速的交付。客户不想再等软件包的下一个年度版本了。相反，他们期望一个软件产品中的各个功能是分开的，以便新功能在几周（甚至几天）内即可快速发布。

● 客户还要求可靠的性能和可伸缩性。全球性的应用程序使预测应用程序能处理多少事务以及何时会到达该事务量变得非常困难。应用程序需要跨多个服务器快速扩大，然后在事务量高峰过去之后无缝收缩。

● 客户期望他们的应用程序可用。因为客户与竞争对手之间只有点击一下鼠标的距离，所以企业的应用程序必须具有高度的弹性。应用程序中某个部分的故障或问题不应该导致整个应用程序崩溃。

为了满足这些期望，作为应用开发人员，我们不得不接受这样一个不可思议的的东西：要构建高度可伸缩的高度冗余的应用程序，我们需要将应用程序分解成可以互相独立构建和部署的小型服务。如果将应用程序“分解”为较小的服务，并将它们从单体制品中转移出来，那么就可以构建具有下面这些特性的系统。

● 灵活性——可以将解耦的服务进行组合和重新安排，以快速交付新的功能。一个正在使用的代码单元越小，更改越不复杂，测试部署代码所需的时间越短。

● 有弹性——解耦的服务意味着应用程序不再是单个“泥浆球”，其中一部分应用程序的降级会导致整个应用程序失败。故障可以限制在应用程序的一小部分中，并在整个应用程序遇到中断之前被控制。这也使应用程序在出现不可恢复的错误的情况下能够优雅地降级。

● 可伸缩性——解耦的服务可以轻松地跨多个服务器进行水平分布，从而可以适当地对功能 / 服务进行伸缩。单体应用程序中的所有逻辑是交织在一起的，即使只有一小部分应用程序是瓶颈，整个应用程序也需要扩展。小型服务的扩展是局部的，成本效益更高。

为此，当我们开始讨论微服务时，请记住：

小型的、简单的、解耦的服务 = 可伸缩的、弹性的、灵活的应用程序

系统和组织本身可以从微服务方法中获益——理解这一点是很重要的。为了在组织中获益，我们可以反向应用康威定律（Conway’s law）。这个定律指出了几点可以改善公司内部沟通和结构的措施。

康威定律（由Melvin R. Conway在1968年4月的文章“How do Committees Invent”中首次提到）指出“设计系统的组织其产生的设计等价于组织间的沟通结构”。基本上，它所表明的是，团队内部以及与其他团队之间的沟通方式直接反映在他们生产的代码中。

如果我们反向应用康威定律，也称为逆康威策略（inverse Conway maneuver），并基于微服务架构设计公司结构，那么通过创建松耦合的自治团队来实现微服务，就能改善应用程序的通信、稳定性和组织结构。