讨论微服务以前，你知道微服务的 4 个定义吗？

关于“什么是微服务”的问题，其实并无一个统一的认识。这些年在不一样的场合里和不一样背景的朋友都在探讨微服务。但聊得越多，就愈加现你们聊的不是同一回事。和 DevOps 同样，“微服务”也是一个内涵十分普遍的词。本文从“Microservice“这个概念的源头出发，总结了 4 个经常使用的微服务定义。

James Lewis 原始版的微服务 6 大特征

这个版本起源于2012年，这里首先要注意年份，那时候尚未 Docker，并且 Netflix 的微服务化过程也在这个概念提出以前——2008年就开始了，那时候甚至连 DevOps 还没发明出来。James Lewis 在波兰第 33 次 Degree in Kraków 会议上分享了一个案例，名称是 “Micro Services - Java, the Unix Way”。在这个分享里， James Lewis 分享了在 2011 年中参与的一个项目中所采用的一系列实践，以 UNIX 的哲学从新看待企业级 Java 应用程序，而且把其中的一部分称之为“ Micro-Services ”。

这个时候的微服务所用的单词和咱们如今所用的 Microservices 这个单词有所不一样。一方面，采用 Micro 做为形容词，是和 Monolithic 相对，而不是和 Macro 相对是源于操做系统这门大学课程。咱们知道，现代的操做系统课程都是以 UNIX 做为案例进行讲解的。而这两个单词来自于“微内核”（Micro-Kernel）和“宏内核”（Monolithic kernel）的比较。而很是见的“微观经济学”和“宏观经济学”中的 Micro 和 Macro 两个相对应的单词。

另外一方面，服务要以复数形式出现，表示的是一个以上。因为汉语里单复数是同型的，因此咱们在翻译的时候会出现问题。所以，“微服务”在做为架构的形式出现的时候，咱们会用“微服务架构”称呼。单个的微服务从概念上为了和 SOA 以及其它领域的“服务”有所区分，会以“单个微服务”以示区别。而”微服务“单独拿出来是被看做为一系列技术实践的总称。

在这个分享里，James Lewis将所实践的“微服务架构”总结为 5 大特征：

1. Small with a single responsibility —— “小到只有单一原则”

   在这个特征里，关于微服务有多小有两个标准：

   第一个标准是：若是一个类复杂的超过一个开发人员的理解范围，那么它就太大了，须要被继续拆分。

   第二个标准是：若是它小到能够随时丢弃并重写，而不是继续维护遗留代码，那么它就足够小。这个标准有个很重要的原则就是 Rewrite over Maintain，即“重写胜于维护”。

2. Containerless and installed as well behaved Unix services —— “去容器化而且做为 Unix Service 安装”

   在这个特征中，James Lewis 提倡采用 Jetty 这样的工具集成到 Maven 里，能够很方便的调试或者部署。而后打包成一个可执行的 JAR 包并以 UNIX 守护进程的方式在系统启动时执行。

   特别是在 AWS 这样的公有云环境下，把这样的应用程序和虚拟机实例的初始化脚本结合在一块儿。使得应用程序的生命周期和虚拟机的生命周期绑定成为一体，因为守护进程在全部 Unix 系统中都是通用的，所以简化总体架构的开发和运维。

3. Located in different VCS roots ——“分布在不一样的版本控制代码库里”

   在这个特征中，James Lewis 提到了应用程序的分离，他认为一个“微服务”应该彻底和另一个服务实现完全的隔离，这里固然是指的从开始的代码库就开始隔离了。

   他一样也要求开发人员看到类似性和抽象，并采用单一的领域来指导开发团队的开发。

   所以接下来他继续讨论了领域驱动设计领域驱动设计和康威定律的重要性。他认为界限上下文要足够的清晰，但能够有所重合。若是没有办法作到领域之间很清晰，就经过“物理上的手段”——分离不一样的团队来作到这一点。

   这不可避免的带来一些公共代码，但要把这些公共代码做为“库”和“基础设施即代码”来对待，就像你代码中用到的开源软件。并搭建一个 nexus 库来存储那些二进制依赖。

4. Provisioned automatically ——“自动初始化”

   自动初始化的要点不在于如何自动化，由于不一样的应用不一样的平台有不一样的初始化方式。这里的重点在于管理分布式应用的复杂性。因此对于每一个服务，可以采用声明出这些初始化。例如：服务 A，须要一个 负载均衡，而且能够自动扩展。服务 B，也是一样的声明方式。而这些声明能够用基础设施即代码技术很好的管理起来。

5. Status aware and auto-scaling ——“关注状态和自动扩展”

   在这里，他认为这些应用应该是可以感知吞吐量的监控指标来自我进行扩展的。对于一个现代的应用而言，这是一个基本的架构性要求，但这须要团队有必定的 DevOps 能力。由于这不光要求开发人员可以让应用无状态化，并且要求基础设施能够及时捕获环境的变化。

6. They interact via the uniform interface —— “它们经过统一格式的接口进行交互”

   在这里，James 建议你们采用已经成熟的 HTTP 协议以及标准的媒体类型进行接口交互，而不是采用其它的方式。而且采用 HEATOS 的方式构建 Restful API，使其成为一个超媒体的应用状态引擎。这样就能够将状态和执行过程隔离区分开来，更加容易进行水平扩展。此外，它也构建了一个避免架构孵化的层，能够独立于客户端持续演进。

在总结的时候，它特地提到了 UNIX 哲学。这引用自Doug McIlroy 的一篇采访：

Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. “The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.”

从这段话里，咱们看到了“微服务架构”和 UNIX 哲学之间的关联：

1. 职责独立：让多个程序（注意是 Programs 不是 Program）作好一件事。
2. 统一接口：文本流是统一的接口，每一个程序均可以经过统一的接口进行消费。
3. 公共通讯：采用管道（pipe）的方式

能够说，微服务架构自己是对 UNIX 哲学在企业级 Java 应用系统中的另外一个案例。能够说，虽然应用场景变了，但 UNIX 分解复杂度的方式和保持简单的理念并未改变。

最后，James Lewis 把上述六点特征变成了一个六边形的业务能力：

Hexagonal Business capabilities composed of:
Micro Services that you can
Rewrite rather than maintain and which form
A Distributed Bounded Context.
Deployed as containerless OS services
With standardised application protocols and message semantics
Which are auto-scaling and designed for failure

翻译过来就是：

微服务你能够经过重写而非维护一个分布式的界限上下文，且做为一个无应用容器的操做系统服务部署。并以标准化的应用协议和消息语义，为失败设计且可自动扩展。

Martin Fowler & James Lewis 合做版的微服务 9 大特征

因为在 James Lewis 以后，有不少不一样的项目也采用“微服务”做为它们的实践的名称。然而，不一样的项目之间仍是存在一些差别的，且每一个人都按照本身的方式在实践“微服务”。所以，基于“求同存异”的原则，Jame Lewis 的同事 —— 大名鼎鼎的 Martin Fowler 采用一种概括的方式来解决这个问题：他认为“定义”是一些“共有的特征”(Common characteristics)。Martin Fowler 继续采用了 James Lewis 对这一系列实践的命名，而且作了修改，使之成为一个单独的名词 —— Microservices。

因此，他将微服务总结为如下9大特征：

1. 经过服务组件化

2. 围绕业务能力组织

3. 是产品不是项目

4. 智能端点和哑管道

5. 去中心化治理

6. 去中心化数据管理

7. 基础设施自动化

8. 为失效设计

9. 演进式设计

这 9 大特征的中文版具体内容请参考这里，限于篇幅缘由，本文不展开讨论。

咱们能够从中看出，Martin Fowler 试图将 James Lewis 的微服务定义进行通常化推广，使其不光之能够在不一样的语言架构和技术栈上使用。又能够兼顾敏捷、DevOps 等其它技术，成为一个架构的“最佳实践”集合。但这样一组实践本质上并无太多的创新，只是把咱们自己知道的不少架构和设计的原则结合在当前的技术栈上进行了一次总体的组合和应用。

恰逢一系列互联网公司的成功事迹带来的新实践（持续交付、DevOps）和新技术（Docker）在经历了早期实践者（Early Adopter）实践积累后的结果井喷后。这样的最佳实践的集中反应当然获得了技术人员的掌声。然而，这样的一种定义对于妄图采用“微服务架构“的人来讲是一个很高的门槛。若是这样的 9 个特征的总结是对”微服务架构“的定义。那么，为了要知足以上的 9 个定义，则须要花费很大的精力来进行改造，并且已经超出了技术升级和企业 IT 部门的职责范围。此外，即使咱们知道其中每一个特征所带来的收益，但却很难拿出案例和数据去佐证知足这 9 个特征的改造收益。

避开这 9 个特征的概念正交性不谈，即使这 9 个特征能够从既有的结果来回答”什么（What）是微服务“，但却没有给出“为何（Why）要知足这些特征”和”如何（How）同时知足这些特征”。

若是本身挖的坑填不了，就教给别人来填吧：

Sam Newman 版微服务的 两大特征和 7 个原则

一样做为 Martin Fowler 的同事，Sam Newman 在其著做 ”Building Microservice“（中文译名为”微服务设计“）的第一章就从新回答了”什么是微服务架构“并回答了”为何要采用微服务架构“的问题。

Sam Newman 在书中是这么定义微服务的（《微服务设计》的翻译）：

微服务就是一些协同工做的小而自治的服务。

Sam Newman 自述的微服务的定义更加简单，包含了两个特征：“小” 和 “自治”。

除了继承 James Lewis 关于微服务应该有多小的描述之外（固然，大小都是基于我的的主观判断），还创造性的用康威定律来约束微服务的大小，即“可否和团队结构相匹配”：若是你的团队维护单个服务很吃力，须要保持团队大小不变的状况下还对维护工做游刃有余，那么这个服务就须要继续被拆分。

而“自治” 则很谨慎的把 Martin Fowler 微服务定义的 9 大特征中的“去中心化”、“独立” 、”松散耦合“等字眼进行了统一。并进一步解释到“一个微服务就是一个独立的实体”。而且从外部，也就是黑盒的角度来看每一个符合”自治”的单个微服务所具备的特征，即：

1. 能够独立部署。
2. 经过网络通讯。
3. 对消费方的透明。
4. 尽量下降耦合，使其自治。

此外，他还采用了更简单的“黄金法则”来判断期”自治性”。即可否修改一个服务并对其部署，且不影响其余任何服务。若是答案是否认的，说明你的微服务还不够”自治“。

从 Sam Newman 的定义中，咱们能够推导出“微服务”的几个基本事实：

1. 微服务架构是一个分布式系统架构。
2. 微服务是微服务架构的基本单元。
3. 网络隔离是”必要的“解耦手段。
4. 微服务的业务功能从概念上是完整的，并符合用户角度的“独立”认知。

简而言之，以上的两个特征的表述主要是将微服务从逻辑架构上和部署架构上都看做是一个正交的原子功能单元。而要作到这一点，则须要而要把整个应用系统正确的建模到这个层次，则须要参考不少的内部外部因素。

此外，为了达到“小”和“自治”的目的，Sam Newman 还总结了 7 条原则用来在实施的时候和具体实践结合，分别是：

1. 围绕业务概念建模
2. 接受自动化文化
3. 隐藏内部实现细节
4. 让一切都去中心化
5. 可独立部署
6. 隔离失败
7. 高度可观察

能够看出，Sam Newman 把 Martin Fowler 的 9 大特征用更加具体的术语来从新描述，而且从逻辑上处理了 Martin Fowler 微服务 9 大特征中概念重复和不明确的部分，使其更简单和明确而且更加可操做。例如把“去中心化的数据管理” 和 “去中心化治理”合并为“让一切都去中心化”等。

更重要的是，Sam Newman 提出了采用微服务技术的主要好处，告诉了咱们“为何要用微服务”：

1. 技术异构性：采用更合适的技术栈灵活的处理局部问题。
2. 弹性：这里的“弹性”是弹性工程学的概念，指的是局部失败会被隔离，使得总体不会失败。
3. 扩展：能够根据系统的部分组件按需扩展。
4. 简化部署：这里简化部署不是指的是部署的拓扑结构，而是经过持续的小批量、小范围的部署来下降总体失败的风险。
5. 与组织结构相匹配：微服务架构可让组织的团队转化为合适的大小，并采用透明的制度来进行规范和复制。避免团队的人数增加而带来更多的管理层，使组织熵的上涨。
6. 可组合性：因为各个微服务间不存在依赖关系，因此能够根据用户界面的状况进行灵活的调整和复用，避免对单体应用进行总体的大规模调整。
7. 对可替代性的优化：因为风险和领域更加独立和隔离。所以，抛弃一个微服务并重写的成本并就变的十分低廉。

Chris Richardson 的“微服务架构模式”

2017 年，Chris Richardson 使用 Microservices.io 域名开始推广本身的微服务理念。他是这样定义微服务的：

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

中文翻译过来，大意以下：

微服务，也就是微服务架构。是一种用于把一个应用程序结构化为一个实现业务功能的松散耦合的服务集合的架构风格。
微服务架构使得在大型、复杂的应用程序中实现持续交付和持续部署成为可能。它使得组织能够演进本身的技术栈。

在 Chris Richardson 采用了较为简单的架构定义和准确的目标定义相结合的方式来定义”微服务架构“：它一方面简单的把微服务架构定义成一个实现业务功能的松散耦合的服务集合，另外一方面又以十分具体的目标和结果（持续交付/持续集成）来约束这样一个松散耦合系统的效果：组织能够演进本身的技术栈。

Chris Richardson 将“单体架构”和“微服务架构”看作两种架构模式。而且在一样的上下文中对两者各自的优劣进行了比较。更加剧要的是，Chris Richardson 采用 AFK 扩展立方来拆分微服务从而回答了“如何作微服务”的问题。

值得注意的是，Chris Richardson 所采用的例子虽然在一样的上下文中，但因为特征不一样并不具有可比较性。所以，他采用了在”单体架构模式“（Pattern: Monolithic Architecture）的基础上描述其局限性的方法引出了”微服务架构模式“（Pattern: Microservice Architecture）。严格的说，Chris Richardson 的“单体架构模式“是一种对现状的和举例，并无给出其特征和方法的描述，所以不能称之为模式。而”微服务架构模式“则又是一系列模式的总和，以下图所示：

PatternsRelatedToMicroservices

从这个角度看，Chris Richardson 的这些模式并无突破 Sam Newman 在《微服务设计》中总结出的实践。但相较于咱们所知道的微服务的优势。Chris Richardson 也列出了微服务的缺点：

1. 开发者的 IDE 对分布式系统的在线开发和调试相对于单体应用架构来讲并不友好。
2. 测试更加困难。
3. 开发者必须实现跨服务的通讯机制。
4. 不采用分布式事务来跨服务构建业务是十分困难的。
5. 须要进行跨团队的协调工做。
6. 部署更加复杂。
7. 更多的内存消费，对于 Java 应用来讲，独立的部署意味着没法共享 JVM 的内存管理。

相较于以前的微服务定义而言， Chris Richardson 的微服务体系比较完整，而不只仅是总结和列举实践。Chris Richardson 的”微服务架构模式”不光回答了“什么是（What）微服务”，也回答了“为何（Why）要用微服务”，“何时（When）用微服务”，“什么场景（Where）下”以及“如何（How）实现微服务”的问题。

Chris Richardson 还编写了一套微服务的指南，能够在这里 查看。

比”什么是微服务“更重要的事

本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为何要用微服务？你想从微服务中得到什么益处？你是否了解为了追求这些益处所带来的代价？若是不先明确这些问题，在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务，可能带来的结果并不理想。

不过，在讨论这些问题以前，坐下来统一一下对微服务的理解，会提高咱们讨论和实践微服务的效率。