什么是微服务

什么是微服务？

什么是微服务？一句话，就是：

• 庙小妖风大，水浅王巴多

如果你没有学过微服务，你可能不知道我在说什么；反过来，如果你学过了微服务，你再来品上面这句话，你可能会哈哈大笑起来。

以 SpringCloud 来说，微服务一般来说，有五虎上将，有什么Eureka、Ribbon、Hystrix、Feign、Zuul 什么的，它们代表了微服务架构中，最主要的功能组件。譬如：

• Eureka，负责服务注册，代表着注册中心这么一个组件
• Ribbon，代表着负载均衡这么一个组件
• Hystrix，则是服务容错的功能组件
• Feigh，则是作远程调用的组件
• Zuul，是服务网关组件

为什么会是这么个样子呢？很好理解，你就想着打天下这么一个事，用打天下这么一件事来理解，就可以了。什么意思？很好理解，且听我讲：

无论是什么单体架构、垂直拆分、水平拆分、分布式、SOA，还是微服务，本质上都是在讲服务器端的软件架构，无论什么样的软件架构，作为服务品端的软件，本质上讲，都是在做服务？为谁服务？为客户服务呀，为上帝服务呀，为天下人服务呀。

这个架构也，相对来说，有好有坏，有强有弱，这就像儒家传统讲的一句话，叫修身、齐家、治国、平天下，它是一个由个体到众人，由小家到大家，由小规模到大规模，由社会到国家，总之，是一个不断适应、不断发展的过程。

但是，类似按儒家的思想从修身到平天下的过程，一样，所谓的什么单体架构、垂直拆分、水平拆分、分布式、SOA，还是微服务，本质上讲，都有一个家的概念在里边，是以家的概念来治理的，从最简单的单体结构开始，你就可以将整个单体看成是一个家，一直到微服务，你就可以看成是一个更大的家，就像儒家思想的所谓小家，小到一户人家，一个家庭，是家，大到国家，还是家，国家再大，还是有家的影响在里边。

只是从小家到大家，是一个规模由少到多、由小到大，总之越来越大的过程，都说多则乱，而乱则需要治，服务架构从单体架构，到垂直拆分、水平拆分，再到分布式、SOA，以及微服务，既是一个由小到大的过程，也是一个由乱到治的过程，一个不断调整和适应的过程，一个发展的过程。

讲这么多，有些人觉着有点虚，不知道我在讲什么，其实，以 SpringCloud 来说，其微服务组件当然不只Eureka、Ribbon、Hystrix、Feign、Zuul 这几件，但拿这几个基本的组件来讲，你就能很好地理解，什么是微服务了。

这就像打天下一样，最开始的时候，可能天下并没有打下来，只是占了一个山头，但水泊梁山，落草为寇，好歹也是一支队伍，有自己的地盘，有自己的城头旗，有自己山寨门，也就相当于是一个系统，这个系统，有自己的队伍，也就有自己的机构部门和管理机构，以及把守的关隘，那是麻雀虽小，五脏俱全呐。

所以，你可以忘了什么Eureka、Ribbon、Hystrix、Feign、Zuul这些东西，就像部门的名称，部门名称可以换，甚至可以重新组建新的部门，但是你不能忘了系统本身，不能忘了各个功能部门的职责使命，不能忘了家的概念，忘了打天下的宗旨和远景，明白了吗？不能忘了微服务的本质是服务，打天下的本质，是为人民服务，为天下人服务。

打个比方，Zuul 就相当于一个守山寨、守城门的职责部门或某个人，通常我们称之为网关，如果有一天，我们觉着 Zuul 这个人做的不够好，我们可以把他撤了，换一个做的更好的人来做，这是完全没有问题的，如果你将它当成是一个部门或机构，这个机构是可以撤掉重建或重组的，这也是完全没有问题的，我们完全可以找一个更称职的人来做，组建一个焕然一新的部门来做，但做的事，部门的功能，它的使命和职责，大体还是差不多的，具体来讲，就以 Zuul来说，它不过就是整个微服务系统的一个网关组件而已，市面上可以充当网关软件或组件，不只 Zuul 一个或一家，你完全可以在你的微服务系统中使用其它网关软件，这一点问题都没有。

同样，Eureka是一个注册中心，但市面上的注册中心不只Eureka一家，这就像一个插座一样，插头和插座的关系，是可以插拔的，用软件构架的思想来说，就叫作解耦，组件和系统之间的关系，在微服务系统架构中，也是一种即插即用的关系，它们之间的耦合性不强；同样，Ribbon是作负载均衡，Hystrix是作服务容错用的，Feign是做远程调用的，它们统统都是可以换掉的，甚至哪怕市面上没有其它的可替代的相关组件，只要你的编程能力足够强，你完全可以手搓一个。所以，哪怕你把Eureka看成是整个系统或整个大家庭的老大，那又怎样？王侯将相，宁有种乎？

甚至，你可以把整个SpringCloud换掉，换成Dubbo，换成Spring Cloud Alibaba，或者别的，那也是没有问题的。

当然，我上面说的，有些理论化，或理想化，历史发展通常不完全是这样的，我们说，打天下，打天下，打到最后，也有可能会天下一统，十八路诸候，十八路兵马，合于一处，秦王扫六合，最后的结局如何，谁又知道呢？

上面我们说了，微服务可以一句话大体来概括：

• 庙小妖风大，水浅王巴多

这个所谓的庙小，可以以架构的基本思想和基本组件来形容，就像以 SpringCloud 来说，一样，基本的架构，并不复杂，它们的主要的组件，屈指可数，五虎上将，五个，不多吧，一只手就数过来了，也就是 Eureka、Ribbon、Hystrix、Feign、Zuul ，这就像一个山寨，Eureka所谓注册中心，你可以将它理解为是山寨的王，是管事的，大家都由它指挥、听它调遣或调度，Zuul 所谓网关，就是守山寨关隘或城门的，Ribbon所谓负载均衡，可以理解分配不公时，做同样的事情，有些人做的多，有些人做得少，就会有人抱不平、喊冤喊苦，说自己受不了、做的太多了、不公平，于是就得有人来平事，Ribbon相当于平事的幕僚或参谋在平事时充当的角色，或者平事时的一种公平的做法，对于程序或软件来说，它的核心就是一种均衡性的算法，本质上也是调度功能的一种，负载均衡组件，一句话，就是通过负载均衡算法对主机负载实现或达成均衡目标的一种微服务组件。所以，Ribbon有点类似于一个群体中的和事佬。

Feign远程调用组件，就相当于同一个公司或集团内部不同的分公司、子公司、部门或车间实现配合工作的一种方式，我们可以简单以车间之间的运作之式来理解它，比如一个生产部，它是有半成品车间、成品车间之分的，成品车间的工作是基于半成品车间的半成品进行加工变成成品的：

半成品车间（半成品）------->成品车间（[半成品] -->成品）

所以，成品车间，是需要调用半成品车间的东西也，也就是半成品车间的工作成果；半成品车间和成品车间之间，相当于处于上下游关系的两个微服务，而远程调用组件，相当于二者之间实现调用的某种协议的实现或工具化，你可以将它视作是两个车间之间的调用的方式约定和那些车间内负责从半成品车间拉运或搬运半成品到成品车间的人或组件的集合。

Hystrix则是服务间调用时容错机制的一种实现。Hystrix有点类似于一个群体中出了问题之后的判官或阴阳法师。

总之，你可以将它们理解成不同的一个单位系统中的不同的职能部门或机构，这就是所谓的微服务组件。之所以称之为微服务组件，是因为为了打天下、为了更多的人做好服务，职能部门或机构的拆分或组建，是基于单一职责来实现的，就是一个部门尽可能职责单一化，而不是一个部门挂一堆牌子、干各种各样的事，什么活都揽。

所以，单一职责是微服务系统进行服务拆分的一个原则，目的，就是为了把活干好、干精细，更好地实现为客户服务，这就像一个饭店或餐饮一样，切菜的切菜，炒菜的炒菜，端菜的端菜，各干各的活，活儿是分了类的，由不同的职责的人负责，这个概念，叫做分布式，或者服务拆分。

为了把活干好，由于越拆越细，你会发现里边的学问非常的大，我们说，其实微服务，远不止上面五种组件或五种职能，你对微服务接触的越深，做的项目越大，你学习和了解的微服务组件就会越多，知道的其中的实现方式、构成内容、各种算法就会越多，所以我们说，庙小妖风大。

另一句，是水浅王巴多，这个东西，就对群集概念的一种理解，同样，像饭店一样，同一个部门或职能的人，就像一个服务器集群，或者说是同一种微服务部署的服务器集群，它们干的活虽然一样，但随着任务压力或工作负载或负荷的增大，服务器的数量也可以不断的增多，这就是切菜一样，如果来的客人少，可能一个切菜的师傅就够了，如果来的客人很多，同样是切菜，可能就会安排更多的切菜师傅，更多的端菜服务员，同一个部门、干同种事情的人，可以看成是同一个服务（器）集群。

集群就是干同样事情、承担同样的职责、实现同样的功能的服务器集合的一种称谓，这个概念非常好理解，概念是非常简单的，我们可以称之为水浅，但是，同样的一个集群内，可能存在大量的服务器或服务主机，我们可以称之为王巴多。

所以，水浅王巴多，可以用来形容或理解【集群】这样的软件或软件部署的概念。

庙小妖风大，可以用来理解微服务架构，庙小就像家的概念，家的概念看起来并不复杂，但它却可以直到家天下，直到国家的概念，简单的背景藏着复杂的业务和发展趋势以及相关联的各种各样的问题，这就像【一入侯门深似海】一样，侯门的门也代表着家，但里边却深似海，复杂得很，庙小妖风大，是对一种看似简单、实则复杂的现实或现象概念，微服务的本质，是分布式和面向服务理念和架构的一种强化和升缘，它的基本理念和基本架构的实现并不复杂，复杂的是它和现实业务的结合和客户要求的结合，和对历史或现实发展要求的适应。

总体上讲，微服务是服务器端服务软件架构发展的一种历史产物，这和服务集群、云计算等概念密切相关，和服务的大规模应用相关，是一个比较高级的软件架构概念，我用庙小妖风大、水浅王巴多来形容它，总体上讲，它并不是一个简单的东西，简单是一种表象，复杂才是它的真相。微服务的出现，其实在原来的服务架构基础之上，同样引入了非常多的问题，当然，这是另外一个值得进一步探讨的话题了。