微服务架构被越来越多的系统架构使用到，甚至很多组织在无意识的情况下，也或多或少地使用到了微服务架构中的一些概念。就像Martin Fowler所说的，微服务架构其实由来已久，它作为SOA的其中一种实现方式已经被广泛使用了。只是到了最近，才用“微服务” (Microservices) 这么一个概念为其“正名”而已。在阅读了Martin Fowler的相关文章后，我觉得Martin Fowler的关于微服务的一些观念在国内比较少的被提出、讨论，所以这篇文章主要想提取Martin Fowler针对微服务架构的一些独特的观点，供大家讨论、参考。

微服务 vs 单一服务

当我们提及微服务，不可避免的，我们会讨论和微服务对应的架构形式：单一服务 (Monolithic)。注意，微服务和单一服务架构并没有孰优孰劣之分，只是根据其不同特点，应用的场景有所不同（这将在后文进行进一步的讨论）。为了方便展开讨论，我们先弄清楚微服务和单一服务架构的概念以及区别。

• 单一服务：把所有功能都集中在一个应用系统。在部署时，单一架构的应用以整体的方式进行部署，也就是说在进行集群时，也是以应用的整体进行集群。

• 微服务：应用系统由一些列功能独立的小规模服务组成。这些服务相互关联、沟通，从而支持应用系统的业务功能开展。由于这些服务的独立性，不同服务可能是基于不同开发语言进行开发的，数据的储存也是基于不同的方案。部署时，由于服务的粒度小，提供了更强的灵活性。

微服务的基本特点

由于不同人对微服务有不同的定义，业界很难形成统一的观点。Martin Fowler简化了定义流程，通过提出微服务的9个特点，如果应用架构符合了这些特点，那么可以认为是为服务架构（这里需要注意的是真实世界中并没有非黑即白的定义，可能你的架构部分具备微服务的特点，那么可以认为其已经体现了微服务的思想）。微服务的9个特点大家可以查看Martin Fowler的原文（参考文献#1），下面我将一些值得注意的特点提出来供大家参考、讨论。

• 围绕业务来组织人员

在传统的IT企业架构中，人员的组织一般是按照职能进行划分的，例如：前端开发、后端开发、DBA、BA、测试等。这种组织形式往往以项目的方式运行，也就是当项目开展时，项目团队由各个职能部门的人员组成，在短期内以项目的方式协同工作，交付产品。虽然项目方式可以有效的交付产品，但是由于项目的临时性，项目结束后，相关人员会回到职能部门中，其在项目的成果往往不会被主动的进行改进、总结。换句话说，项目的一些成果没能被有效的沉淀下来，可以被以后类似的项目复用。

而在微服务架构下，人员的组织是基于业务进行划分的，例如：某一个团队负责用户注册功能，某一团队负责的是订单功能。这种划分方式体现的一个要点是：you build, you run it，即：谁开发，谁负责到底。这种方式带来最大的好处是：由于团队只需要考虑自己的业务领域，所以团队可以在某一个业务上进行很深的积累，最大限度的提升某领域的效率、功能。

• 白痴的中枢 与 聪明的端服务

微服务的其中一种实现方式是基于ESB (Exterprise Service Bus)，ESB一般提供复杂的功能，例如：消息传输、路由、协调、转换、业务规划等。ESB方式可以将不同服务有效地进行相互协同，以满足业务的需求。但是其最大的问题是ESB会成为整个应用系统的瓶颈（即使采取集群的方式也易产生雪崩效果）。

因此，在微服务架构中提倡了另一种方式：将ESB中复杂的功能，转移到每一个服务中去，从而实现“白痴的中枢”配上“聪明的端服务”，以去处ESB单点的隐患。

• 异构技术的高容忍性

在单一服务架构中，所有的功能都必须根据既定的技术框架进行开发，例如：Java 8、MySQL等。但是，其实每一个功能由于其不同的特点，可能其它技术会更有利于该功能的实现，例如：某功能对数据一致性没有太高的要求，但是数据量巨大，那么可能NoSQL比关系数据库更适合该功能。因此，单一服务的功能可能会受到较多的技术限制，而无法高效的满足业务的需求。

在微服务架构中，由于服务的独立性，其技术可以根据业务的具体特点来进行独立的选择。另外，由于微服务对异构技术的支持，应用系统可以很方便的引入成熟的技术解决方案，帮助提高系统的开发效率。

• 自动化

虽然微服务有上述的许多优点，但是它引入比单一服架构多得多的复杂性，例如：一个应用的正常运行依赖于30个服务，当其中一个服务出现问题，那么整个应用也将出现问题。在微服务架构下，单靠人手、人脑已经很难支撑应用的运行。因此需要在部署、测试、监控几个方面进入自动化，在事前、事中控制由于微服务的复杂性带来的风险。

微服务就是SOA吗？

很多人认为SOA的主要核心就是ESB，所以所有应用都应该基于一个标准以帮助应用在ESB上进行通信。但是实际上SOA的核心是功能的合理模块化以及重用，从而可以根据业务的需求，通过模块间的组合快速适应业务的变化。而微服务，其实是实现SOA目标的一种方式，是SOA的一个子集。

服务的粒度

服务粒度的大小也是微服务讨论得比较多的一个问题。这个问题很难有一个绝对的答案，最好的答案应该就是适合你的企业就好。以下有两个标准可以帮你评判服务的粒度是否适合：

• 服务是否可以被独立的替换而不影响系统其它功能？
• 服务是否可以被独立升级而不影响系统其它功能？

什么情况适合使用微服务？

如上文所说，单一服务以及微服务并没有孰优孰劣，它们适应不同的场景以及需求，以下是一个针对单一服务以及微服务特点的总结：

使用微服务必要的条件

如果你要使用微服务，确保你已经具备了以下条件：

• 快速添加计算能力：通过灵活的计算能力调配，最大化微服务的伸缩性
• 服务监控能力：应对微服务间复杂的网状关系
• 快速的服务部署能力：适应Devops文化

参考文献

• [1] Microservices - a definition of this new architectural term (https://martinfowler.com/articles/microservices.html)
• [2] GOTO 2014 • Microservices • Martin Fowler (https://www.youtube.com/watch?v=wgdBVIX9ifA)

pstrike 2018.05.10 于常州

【尊重版权：转载之前请先联系我】