《企业级容器云架构开发指南》—2.2　微服务概要介绍

2.2　微服务概要介绍

2.2.1　微服务架构原理

在了解了为什么要做微服务之后，我们来简单了解一下微服务的起源和发展。早在 1994 年Mike Gancarz就提出了9条著名的原则，其中前4条和微服务架构理念特别接近，微服务就像把UNIX哲学应用到了分布式系统。

small is beautiful（小即是美）：小的服务代码少、bug少、易测试、易维护，也更容易不断迭代完善，精致进而美妙。

make each program do one thing well（一个程序只做好一件事）：一个服务只需要做好一件事，专注才能做好。

build a prototype as soon as possible（尽可能早地创建原型）：尽可能早地提供服务 API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢地做。

choose portability over efficiency （可移植性比效率更重要）：服务间的轻量级交互协议在效率和可移植性两者间，首要依然考虑兼容性和移植性。

2011年5月在***召开的软件架构研讨会（QCon）上，“微服务”这一术语被讨论用来描述参与者一直在探索的一种常见的架构风格。2012年5月，在QCon旧金山会议上，该研讨会决定使用“微服务”作为最合适的名字。可见微服务其实不是凭空产生的，它自有其历史渊源。

国际著名的OO专家、敏捷开发方法的创始人之一马丁·福勒先生对微服务架构做出了自己的定义，他认为微服务架构是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式管理，服务可用不同的语言开发，使用不同的数据存储技术。

其实微服务架构是一种思想、一种方法论，不会完全依赖于哪些技术、哪些平台，马丁·福勒提出将单一的应用程序开发，转变成一组小型服务的方法，这其实就是“拆”的过程，然后再阐述“合”的过程。

那么微服务有哪些特征？

首先，每个微服务都在自己的进程中；其次，服务和服务之间除了轻量级的通信机制，也就是API的调用之外，不能有其他的调用方式，不能直接访问别人服务的数据，不能直接有一个类似库表之间的调用，只能是轻量级的通信机制；最后，这些服务围绕业务能力构建，并且全部可以独立部署，可以自动化实现一个个小的构件，然后这些服务共用一个最小型的集中式管理，服务可以用适合的语言和数据库。这就是一个微服务。

如图2-5所示，微服务的诞生绝非偶然，是多重因素推动下的必然产物，它的出现具备天时、地利、人和，而互联网就是驱动微服务出现的源动力。

图2-5　微服务的产生

无论是微服务还是容器化，都是为了解决伴随互联网蓬勃发展所出现的问题，只有拆分成一个个小的服务，才能更好地管理，让每个团队更灵动，从而促进团队之间的竞争。同时，所有的竞争都要靠人来完成，而人的管理如果没有先进的手段保证，将无法进行。纵观国际也是一样，亚马逊的云公司之所以做得这么好，是由于一种天然因素的驱动。亚马逊要做全球的生意，如果不谈管理难以实现，亚马逊才会想办法做各种架构、自动化，同时又将其成果开源。而国内情况也类似，阿里巴巴的云技术在国内领先，也是因为其业务的量变引发了质变，催化了阿里的云技术发展。

目前的状况是自媒体公司一半以上的资金量要买机房做压缩、传输，做IDC，IDC占互联网公司成本的一半，另外一半资金用来建设团队、做运营、做市场推广。基本上任何一家互联网公司的模式都是这样的。因为量变引发了质变，才会有今天的敏捷、持续交付、微服务，Docker提供了很好的封装、打包，让所有技术有了更好的支点，所以微服务、容器化、DevOps如同一个铁三角，密不可分。

简单来说，微服务就是一些协同工作的小而自治的服务，如图2-6所示，微服务与单体架构有不同的风格。

图2-6　微服务与单体架构的风格

（1）小而专注

在单体系统中，随着新功能的不断增加，代码库会越变越大，以至于修改和系统集成的难度随之上升。而为了避免这些问题，微服务高内聚低耦合的特性应运而生。把因相同原因而变化的东西聚合在一起，把因不同原因而变化的东西分开来。微服务将内聚性应用在独立的服务上，根据业务的边界来确定服务的边界，可避免代码库过大衍生的问题。但独立性带来的好处越多，管理就越复杂。

（2）自治

一个微服务是一个独立的实体，它可以独立部署、独立修改，服务之间通过暴露API来进行通信，API的实现技术应避免与具体技术相关，以保证技术的选择不受限制。自治性其实就是要求服务与其他的服务之间很好地解耦。判断是否解耦有一个黄金法则，即你是否能够修改一个服务并对其进行部署，而不影响其他任何服务，如果是，那么就可以实现很好的解耦。

具体来讲，每个微服务都包括自治、隔离、弹性、适应性、响应、去中心化、可组合、自动化等特性，单体的微服务能够实现更好的部署、更好的测试，但“合”的时间可能会更长，会有很多问题，诸如数据的不一致性、后面通信的复杂度、彼此之间的依赖等。通过表2-7，我们可以简单地看出单体架构与微服务架构的优缺点。

表2-1　微服务架构与单体架构的优缺点

那么，微服务和SOA是什么关系？

SOA是一种设计方法，它通过提供服务向外提供一系列功能，服务之间通过网络调用，而非采用进程内调用的方式进行通信。SOA可以应用于庞大的单块应用程序，从而提高软件的复用性，如多个终端共享一个服务。大多数SOA的学说更倾向于理论和概念的层面，关于服务的“粒度”定在哪个层级，服务如何落地，如何保证可用性等问题始终没有取得广泛的共识，对于软件所依赖的环境，SOA也很少涉及，但软件的运行是离不开外部环境的。所以SOA的学说虽然热门，但真正做到了、做好了的例子非常有限。

在这种局面下，微服务应运而生了。承接SOA的概念，微服务将系统按照业务责任划分为彼此独立的多个服务，既保证了概念的清晰和自洽，又保证了系统的灵活性、伸缩性。面对杂乱不可靠的现实，又从实现上注重每个服务的自治性，也就是能独立部署，具备自动化、可观察、故障隔离、自动恢复等特性，由此提供高可用保障。

如图2-7所示，微服务在原来SOA的基础上更进了一步，原来系统之间用SOA理念集成起来，但却没有定义每个系统具体什么样。微服务的特性决定了要对系统重新进行定义，系统要自治，要独立部署，要有隔离性，只能和别人用轻量级的通信方式，可以有自己专属的技术和数据。在系统内部要切成一个个微服务，每个微服务要具备的特性都要定义清楚，会比原来的SOA有更好的操作性。

图2-7　微服务与SOA的关系

在SOA尚且没有完整落地的时候，对它有继承、有更新、有颠覆的微服务极大地增加了开发人员的挑战。

首先，服务要拆得足够小，又不至于太小，这样才能保证伸缩性并隔离故障；其次，不能因为服务“小”就降低保障级别，维护一堆“小服务”的保障级别是极其麻烦的事情；再次，要做到上面这一切，无论是从理论还是从可依赖的软硬件系统上，都没有现成的低成本解决方案；最后，因为维护的是动态的“服务”，传统静态的“代码所有权”和“机器所有权”的划分不再有效，它们已经融合为统一的“服务所有权”，它属于开发人员、运维人员以及所有相关人员的共同体，这又会给团队配合与分工带来挑战。