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

本文选自《Spring Cloud与Docker高并发微服务架构设计实施》，了解详情请点击阅读原文。

• 微服务概念的由来

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

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

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

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

……

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

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

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

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

• 微服务的定义

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

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

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

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

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

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

• 小型化

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

• 自治化

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

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

• 扁平化

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

• 轻量级设计

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

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

• 渐进式设计

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

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

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

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

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

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

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

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

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

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

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

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

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

整体式架构六边形结构图

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

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

微服务架构结构图

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

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

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

• 微服务架构与SOA的比较
  

SOA（Service-Oriented Architecture，面向服务架构），是一种粗粒度、松耦合的面向服务架构设计方法。SOA 可以看作 B/S 模型、XML（标准通用标记语言的子集）/Web Service 技术之后的自然延伸。

SOA 是一种企业级的架构设计方法，使用企业服务总线（ESB）的方式来构建一个更高效、更可靠、更具重用性的企业信息系统。相比于以往 C/S 和 B/S 等模式的设计，使用SOA 架构的系统已经取得了很大的进步，系统可以更加从容地面对业务的急剧变化。所以 SOA 曾经风靡一时，例如 Dubbo、Dubbox、Mule、WSO2、CXF 等都是一些比较优秀的 SOA 开源工具。

微服务架构与 SOA 在表面看来还是有一点相似的，以至于早期有人会认为微服务是一个细粒度的 SOA，其实它们的区别还是很大的。

微服务的轻量级设计与 SOA 重量级设计是这两种架构的最大区别。微服务的通信设计使用简单的 HTTP 协议，一般使用 Restful 实现。而 SOA 一般使用复杂的协议，如WebService 或 BPEL（Business Process Execution Language，业务流程执行语言）等，还需要使用服务描述性语言来定义标准接口。

微服务的自治性与 SOA 的集中式管理的区别：微服务架构使用去中心化的扁平化管理方式，每个服务都是一个独立的应用程序，独立管理，使用独立的数据库，独立部署和独立运行。SOA 是一种整体式架构，使用集中式的管理方式和统一的数据中心。所以微服务的开发和部署更加灵活和快速，可以更快地响应需求的变化和业务的更新。

微服务架构与 SOA 的另一个区别是应用的规模不同，SOA 是在企业计算领域中产生的一种架构设计方法，在应用规模上是一个有限的范围，而微服务架构是产生于互联网环境中的一种设计方法，它的设计更能适应无限广阔的环境，更能适应互联网高流量、高并发的规模扩张。

微服务架构的高可用设计、自由伸缩性、负载均衡、故障转移等特性是 SOA 设计不够重视的地方。微服务的高可用设计通过微服务治理，为每个微服务的管理和部署提供一个可以扩展的无限广阔的空间，它可以表现为一个三维结构。

微服务治理的三维结构

在这个三维结构中，如果我们用 Y 轴表示微服务应用，用 X 轴表示微服务应用部署的多个副本，那么用 Z 轴表示微服务治理，它将提供服务路由和负载均衡管理等功能，并且还可以提供分区管理的功能。

• 为什么要使用微服务架构

整体式架构已经不再适合于一个大型项目或者一个应用平台的开发，而 SOA 架构虽然曾经风靡一时，但是其重量级的设计也已经成为快速开发的障碍，所以这两种架构设计方法都将被微服务架构所取代。微服务架构轻量级的设计风格， 不管从理论上还是从技术实现上，已经越来越多地得到更多人们的肯定和认可，大家对它的未来发展趋势都抱有一种乐观的态度。使用微服务的好处如下。

• 开发简单

微服务架构将复杂系统进行拆分之后，让每个微服务应用开发都变得非常简单，没有太多的累赘。对于每一个开发者来说，这无疑是一种解脱，因为再也不用进行繁重的劳动了，每天都在一种轻松愉快的氛围中工作，其效率将会成倍地提高。

• 快速响应需求变化

一般的需求变化都来自于局部功能的变更，这种变更将落实到每个微服务上，而每个微服务的功能相对来说都非常简单，更改起来非常容易，所以微服务非常适合敏捷开发方法，能快速响应业务需求的变化。

• 随时随地更新

一方面，一个微服务的部署和更新并不会影响到全局系统的正常运行；另一方面，使用多实例的部署方法，可以做到一个服务的重启和更新在不易被察觉的情况下进行。所以， 每个微服务任何时候都可以进行更新部署。

• 系统更加稳定可靠

微服务运行在一个高可用的分布式环境之中，有配套的监控和调度管理机制，并且还可以提供自由伸缩的管理，充分保障了系统的稳定可靠性。

• 规模可持续扩展

每个互联网应用都具有巨大的市场潜力，一旦这种潜力被激发，就需要系统能支持大规模的高并发访问机制，使用微服务架构设计的系统，将能适应业务的快速增长，并可持续支持规模化的扩展。

《Spring Cloud与Docker高并发微服务架构设计实施》

 

博文视点

您阅读的专业智库

喜欢请分享至朋友圈

了解更多本书详情请点击阅读原文

长按二维码轻松关注

点击阅读原文，即可快速抵达本书详情页！