讨论微服务之前，你知道微服务的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将所实践的“微服务架构”总结为 6 大特征：

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 ——“自动初始化”