近几年，大家都在谈论微服务，微服务是一个非常火爆的关键词，在百度中搜索微服务，随便就有几千万条结果。那么，什么是微服务呢，微服务的概念是怎么产生的呢？

1 微服务概念的由来

据说，早在 2011 年 5 月，在威尼斯附近的一个软件架构师研讨会上，就有人提出了微服务架构设计的概念，用它来描述与会者所看得见的一种通用的架构设计风格。时隔一年之后，在同一个研讨会上，大家决定将这种架构设计风格用微服务架构来表示。

起初，对微服务的概念，也没有一个明确的定义，大家只能从各自的角度说出了对微服务的理解和看法。

有人把微服务理解为一种细粒度的 SOA（Service-Oriented Architecture，面向服务架构），一种轻量的组件化的小型 SOA。

有人把微服务看作一种使用 HTTP 通信的自包含的轻量进程。

……

在这些看法中，比较统一的一点就是，大家都认为微服务是一种小型的应用程序，并且使用轻量级的设计方法和轻量级的 HTTP 通信。

在 2014 年 3 月，詹姆斯•刘易斯和马丁•福勒所发表的一篇博客中，总结了微服务架构设计的一些共同特点，这应该是一个对微服务比较全面的描述。

这篇文章中认为：“简而言之，微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己的进程中运行，并与轻量级机制（通常是 HTTP 资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机器独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理。”

从这个描述中可以看出，微服务可以是一个小型的服务组件，它使用轻量的 HTTP 协议进行通信。微服务也可以是一个独立的应用程序，它可以具有独立的数据库、独立部署和独立运行。理想的想法是，微服务可以使用不同的语言来编写，并且完全独立自治。

2 微服务的定义

从上面对微服务概念形成过程的介绍之中，我们已经对微服务有一个大概的了解，但要说明什么是微服务，很有可能一时也不能说得很清楚。这里，有一点容易混淆的就是微服务架构和微服务，这应该是两个不同的概念，而我们平时一说到微服务，可能已经包含了这两个概念，所以要把它们说清楚难免就会有一种很纠结的感觉。微服务架构是一种设计方法，而微服务应该是指使用这种设计方法而设计的一个应用。所以我们很有必要对微服务的概念做出一个比较明确的定义。

微服务架构是将复杂系统使用组件化的方式进行拆分，并使用轻量通信方式进行整合的一种设计方法。微服务就是通过这种架构设计方法拆分出来的一个独立的组件化小应用。

组件，通常是以代码库的形式，提供函数式调用；而微服务的组件，却以应用的方式， 通过使用 HTTP 通信提供接口服务。

微服务架构定义的精髓，可以用一句话来描述，那就是“分而治之，合而用之”。将复杂系统进行拆分的方法，就是“分而治之”的方法。分而治之，可以让复杂的事情变得简单，这很符合我们平时处理问题的方法。使用轻量通信等方式进行整合的设计，就是“合而用之”的方法。合而用之，可以让微小的力量变得强大。硬件设计中多线程和多任务的技术，可以成倍地提高其并发能力和执行性能。如果软件设计还在使用单线程的方法，那是相当落后的。所以微服务设计中的整合，不但是多服务的整合，也是一种多实例、多副本的整合。通过这种整合，可以充分利用分布式环境的资源和低廉的机器组合成一个强大的服务系统。

微服务轻量级的 HTTP 通信，不同于传统的做法，使用事先设定的 IP 和端口进行访问，而是通过服务注册与发现的机制，使用服务的实例名称进行调用。在这个过程中，服务发现机制将协同路由代理服务和负载均衡器一起工作，当客户端使用服务实例名称发出请求时，将通过负载均衡器从服务注册列表中选择一个可用的服务实例，然后才通过实例注册的 IP 和端口路由到相关的服务中。所以提供 API 的微服务，可以发布在任意主机之中，并且可以随时更改主机和端口，也可以发布任意多个副本。

基于上面微服务的定义，我们可以总结出微服务架构设计的几个显著特点，具体如下。

1．小型化

微服务架构设计的突出之处就是进行服务组件化设计，组件化的结果最显著的特点就是应用程序变小了。使用组件化方式来构建的应用程序，每个组件将只负责完成一定范围的业务功能，更加专一地做好一件事情。因为小型化的特点，会让问题变得更加简单，也使开发变得更加容易。

2．自治化

使用去中心化的扁平化设计，将使每个服务都能够进行独立自治，这是对复杂功能的一种解耦设计。这种设计的特点也给每个微服务提供了更加自由的管理空间。

每个微服务都是一个独立的应用，独立使用数据库，独立部署，独立运行，这种独立性符合高内聚松耦合的设计原则。在微服务开发和维护中，每个微服务都是独立自治的， 一个服务的更新和迭代将不存在对其他任何服务的依赖，同时也不会给其他服务造成影响，或者将这种影响减少到最小限度。

3．扁平化

独立自治的微服务，可以更加自由地发挥每一个服务的优势和长处。但是这种自由并不是指随意的混搭和组合，而是使用了扁平化的服务治理，让更多的微服务在发挥个性优势的同时，处在一种杂而不乱的有序可控的状态之中。虽然从整体上微服务已经没有集中管理的概念了，但是微服务在整体上能够发挥更佳的性能优势。

4．轻量级设计

微服务的组件化特点，也是一种轻量级设计方法的体现，这种轻量级的设计同样体现在微服务的通信设计之中。

微服务的通信设计通常用到两种方式，即使用 API 的同步通信和使用消息通道的异步通信，不管使用哪种通信方式，都没有像 SOA 的 ESB（Enterprise Service Bus，企业服务总线）那样的重量级设计，而是分别使用简单的 REST 协议和轻量的消息总线来实现。

5．渐进式设计

一个产品从成型到成熟总是要经历一个过程，这个过程就是渐进式设计的特点。由于微服务小型而独立的特点，微服务设计可以使用业务驱动的方式进行，使用快速迭代进行不断地修正和调整，以使产品趋于成熟。

3 微服务架构与整体式架构的区别

如果是一个小型项目，使用整体式架构来设计，其好处是明显的，因为它的设计、开发、测试和部署，都在一个项目上就可以完成。

如果一个业务复杂的大型项目，也使用整体式架构来设计，就将存在很多问题。可能刚开始的阶段，还感觉不到什么，但是随着时间的推移，加入的功能越来越多，一个项目就变成了一块巨大的石头，十分笨重。

面对一个如此巨大的项目，开发人员要弄清楚它的代码逻辑，必须要花费很多的时间。而针对某一项功能的更改，极有可能动一线而牵全身，这会让实施的人员变得很难应对。所以这种项目将会变得越来越难以维护，越来越不便更新。

整体式架构的稳定性也不能得到有效的保障，如果其中的一个模块出现问题，将会影响到整个系统的正常运行，甚至造成整个系统的崩溃。而要进行问题的跟踪，因为系统庞大，往往难上加难。

另外，一个巨大的应用项目，也不方便进行持续开发，它不能适应需求的变更，不能适应快速迭代的敏捷开发方法，所以这样的项目最终就变成了业务发展的绊脚石。

相比之下，大型项目使用微服务架构就具有明显的优势。

微服务架构设计，就是将复杂事情进行简单化处理的方法，它将一个复杂的系统，拆分成一些小型的应用来开发，起到了一种“大事化小，小事化无”的效果。因为简单，代码的逻辑会变得更加清晰，这无疑减轻了程序员繁重的劳动；因为简单，所以能够专注，能够将每一件事情做好，做到极致。

微服务中独立的小型应用，也非常适合使用敏捷开发方法，能够快速响应需求的变化，进行快速更新，快速迭代，甚至将一个应用推倒重来也是很容易做到的。

因为每个微服务都是独立自治的，一个服务的故障也不会影响到全局系统的正常运行，或者说可以将这种影响降到最低限度。况且，微服务架构的容错设计可以避免这种情况发生。

微服务架构高可用的特点是系统稳定性的最好保障，而且微服务能够支持高并发的调用，支持高流量的访问，能够持续保证平台规模化发展的要求，这是整体式架构所不能做到的。

如果我们使用一个六边形结构来表示整体式架构的话，将可以绘制出如下图所示的结构图。

这个六边形的核心是整体式架构的领域业务模型，它通过系统接口使用各种适配器，例如数据库适配器、文件适配器等，与外部管理系统进行连接。然后通过接口使用诸如 Rest API 适配器、Web UI 适配器等对外部 App 和终端用户提供接口调用和 Web 访问等服务。

从上图可以看出，整体式架构是一个大而全的系统。在微服务架构设计中，我们可以使用一个小六角形来表示每个微服务，它相当于将整体式架构进行拆分之后得到的结果。

小六角形的微服务同样使用接口，通过各种适配器来连接外部管理系统，而微服务之间也可以通过接口，使用 Rest API 适配器进行通信，而对于 App 和终端用户，将分别由不同的微服务提供相应的适配器及其服务。

从上面这两种结构图形的比较中，可以非常明显地看出整体式架构与微服务架构的巨大区别。

有关这种图形结构的表示方式，参考了克里斯•理查德森在 2015 年 5 月发表的系列文章，对这些文章感兴趣的读者可以在nginx网站中搜索查询。