如何给老婆解释什么是微服务？（文末有福利）-CSDN博客

戳蓝字“CSDN云计算”关注我们哦！

640?wx_fmt=jpeg

程序员有了老婆之后就是累，上次好不容易给她解释了什么是Restful，这不，麻烦又来了…

一个周日的清晨，阳光洒在我的脸上，慢慢把我唤醒。我翻过身，感觉好像少了些什么东西，缓缓地睁开眼睛，“咦，老婆呢？”

突然，我发现床上多了张纸条：

看到这封信时，我已经在回娘家的路上，原因我相信你懂的。如果你不懂，请将信翻到背面。

我一脸懵逼，将纸翻了过来：

哼，你怎么可能不知道原因，你翻过来看就是想确认我发现的是不是你那个秘密而已，那我就告诉你吧。

在你的书桌上，有一本叫 《微服务设计》 的书，我虽然是女生，但也知道“服务”是个什么勾当，没想到你放着好好的程序员不做，居然做起了“服务”，你和旧时代的老鸨有什么区别？

书我翻了一下，想看看你的这种“微服务”是怎么个“微”法，哼，你们程序员挺精明的，看的书都加密过的？别以为我不知道那些是代码，是你们程序员的通用语言。鬼知道里面讲了什么东西。

不管怎样，既然你选择了这条路，也就别怪我不仁不义，再见。不，再也不见。

—— 对你很失望的静香

我渐渐地缓过神来，百感交集，思绪万千，冥想了一会，拿起手机，给她发了信息：

“下午四点，老地方，给你解释什么是微服务。”

沃尔兹百货超市

我提前十五分钟来到了咖啡厅。临近四点，我开始望着门口，59分49秒，一个熟悉的身影走了进来，戴着墨镜，披着纱巾，是她。

“服务员，一个芝士蛋糕，两杯拿铁，谢谢”，我对服务员说。

“说吧，你有什么要解释的？”

“嗯，首先，我向你保证，我在看的“微服务”，绝对不是你想的那种“服务””

“那是什么？”

“这个解释起来要花点时间，我们先吃点蛋糕，待会再慢慢和你解释”

过了一会，蛋糕吃的差不多了。“看到对面那家沃尔兹百货超市了么？”，我指着窗外面的沃尔兹超市，对老婆说。

640?wx_fmt=png

“嗯？”

“那里面什么都有，衣服、食品、文具、家私、电器，应有尽有，而且不管你去到哪一家连锁店，店里的格局都是一模一样的。也正因为如此，这才带来了问题。”

“有什么问题呢？我觉得这样挺好呀，顾客去了那里，想买什么都找得着。”

“首先，这些卖不同物品的 隔间之间会互相影响 。你看，一楼是珠宝店和电器店，假如珠宝店想进行装修，装修时的噪声和灰尘，势必会影响到电器店；还有，假如由于电器店一名员工的疏忽，引发了火灾，旁边的珠宝店是不是也会受到牵连？”

“你这乌鸦嘴…”

“哈哈，都说是假如啦。除了这点，还有一个问题，我考考你，我们这个城市里有几家沃尔兹超市？”

“我想想，好像就这一家？”

“没错，只在西区这里开了一家店。这时候市场总监发现，住在东区的多是上层阶级，他们对珠宝的需求量比较大，这时候要怎么办？”

“那就在东区也开一家沃尔兹百货超市罗。”

“嗯，只能是这样了，可是东区的居民对其他东西的需求并不多，而沃尔兹超市又想让每家分店卖的东西都是一样的，所以他们不得不在东区开一家分店，不仅卖珠宝，也卖食品、衣服还有其他东西”

“这挺浪费的呀， 为了满足人们对珠宝的需求，又开了一个百货超市 。”，老婆若有所思。

“的确，什么都有、什么都卖的百货超市实在是太笨重了，这才有了「微服务」”

“哦？终于要讲微服务了？哼哼。”

沃尔兹小店

“你看，假如我们把沃尔兹百货超市， 拆成很多个卖不同商品的小店 ，比如卖珠宝的沃尔福、卖家私的沃尔家、卖食品的沃尔良还有卖衣服的沃尔衣，这些提供不同服务的店，分布在城市的各个地方，这样他们之间就不会互相影响了。东区二巷的沃尔家搞装修，三巷的沃尔福不会受到影响；三巷的沃尔福发生火灾了，二巷的沃尔家也安然无恙。”

“Soga，原来是这种微服务”，老婆笑着说。

“不仅如此，现在，我们发现东区的居民对珠宝的需求量大，那我们就在东区 多开几家沃尔福，而在西区，中产阶级较多的地方，我们就多开几家沃尔良。”

640?wx_fmt=png

“哇塞，这样看来，微服务让沃尔兹变得轻巧了许多！哪个地方对某种服务的需求大，就在对应的地方多开几家卖那种服务的小店就好了。”

沃尔兹网店

“看来微服务就是把一个百货店变成各个小店嘛，讲这个东西至于用那么厚一本书么？”，老婆是个好奇心很强的女生。

“哈，微服务当然不只是这些，我们现在只是把一个百货店拆成各个小店，但是对于 如何管理这些小店 ，我们还没做好准备”

“哦？这里面还有什么门道？”

“当然，别忘了，沃尔兹可是有网店的。以前还是百货超市的时候，要是有顾客从网上买了一件衣服，那直接从百货超市的仓库里取出这件衣服，给顾客寄过去就好了；现在呢，每一家卖衣服的沃尔衣都有自己的仓库，顾客下单后，工作人员要怎么知道顾客所在区域有哪几家沃尔衣？要从哪家沃尔衣发货呢？ ”

“哟西，还有这个问题。那 沃尔兹总店肯定知道他们在哪个地方开有什么分店吧 ？”

“没错，这时候网店工作人员会从总店那里查出，顾客收货地址所在区域有哪些家沃尔衣，接下来就是从这些沃尔衣店里，选一家，给顾客寄快递过去。”

“就选离顾客最近那一家就好啦。”

“哈，那万一东区有两家沃尔衣，一家靠近居民区，一家靠近商业区，而顾客通常写的收获地址都是写自己家呢？”

“这样… 那靠近居民区的沃尔衣就会收到很多订单，经常要不断的进货，而靠近商业区的那家，就没什么订单了，是吧？”，老婆睁大双眼看着我。

“对！这就是问题，所以网店工作人员会对在一个区域内的沃尔衣，进行 轮流发货 的操作，比如这一次是靠近居民区的这家发货，那下一次，就让靠近商业区的沃尔衣发货。”

“Soga!”

“用计算机术语来说，就是 LoadBalancing ，负载均衡”

“呵呵，少扯这些术语，我只知道New Balance”

“哈哈，怎么样，微服务不是你想象的那样吧，当然，在经济学领域，要考虑的因素还有很多，现实生活中的沃尔兹依然是一个大百货超市，自然是有它的道理的。微服务的应用主要是在更为纯粹的计算机领域，也就是你看到的那些代码”

“得了，看到那些头就大，走，带我去娘家拿行李”

“……”

对程序员的话

用了大白话，给老婆讲明白了微服务的来龙去脉，当然，我还是有些话想说的，还是怕老婆听完一脸懵逼，没给她说：

1、讲微服务，就不得不从 单体应用 （Monolithic ）讲起。

所谓单体应用，就像一开始的沃尔兹百货超市一样，把所有业务的代码都放在一起。这对于小型项目来说自然是很合适的，可是项目一旦大了起来，业务一多，这个单体也就膨胀了，膨胀后的单体应用主要有以下两个缺点：

牵一发而动全身 。我改了一个业务的一行代码，需要重启整个单体应用，这显然不不合理的。就像珠宝店装修时影响了旁边的电器店，电器店着火时殃及珠宝店一样。

只能水平扩展，不能纵向扩展 。对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。

正因为单体应用有着这些缺陷，才有了微服务。微服务和单体应用的区别，可以用Martin Fowler的这张图来解释：

640?wx_fmt=png

2、微服务虽然带来了架构上的优势，但同时也引入了 复杂性 。我们不得使用一些组件，来解决技术复杂性提高之后带来的问题：

服务注册中心 ：一个服务可以有多个实例，那么我们在向一个服务发出请求的时候，怎么知道这个服务有哪些实例呢？为了减少手工维护的麻烦，我们需要服务注册中心。每个服务实例在启动时，向注册中心注册自己的IP地址等信息。这样，服务在调用别的服务的接口时，就可以通过注册中心，查询到其他服务的实例，向实例发起请求。沃尔兹总店就是起到注册中心的作用。

负载均衡 ：由于一个服务可以有多个实例，所以不管是来自外部客户端的请求，还是微服务系统内部服务之间发起的请求，都需要引入负载均衡的机制，来发挥多实例集群的作用。有的书也称这两种负载均衡为 服务器端负载均衡 和 客户端负载均衡 ，各自具有代表性意义的实现分别是Nginx和Ribbon。

API Gateway ：一个外部请求过来之后，我们需要知道这个请求是发给哪个服务的，也就是我们需要一个 请求路由 的功能，比如/cm/*的请求，要发给客户管理服务，/om/*的请求，要发给订单管理服务。另外，不是所有请求都可以被我们系统处理的，我们需要判断这个请求是否携带一些必要的鉴权信息，并对其进行鉴权，也就是 请求过滤 的功能。而API Gateway，就是起到了这两个功能，它就像 整个微服务系统的门面 ，所有请求，都要先经过它的处理，才会转发到对应的服务。

……

640?wx_fmt=png

微服务系统的衍生组件还有很多，比如对各个服务进行的配置管理的分布式配置中心、各个服务之间进行消息通讯的消息总线和消息驱动机制（上图中的Message Queue）等，这里就不一一列举了。这篇文章只是想用一种比较有趣的方式，让大家对微服务有一个初步的了解。就像学设计模式，如果直接去看四人帮的《设计模式——可复用面向对象软件的基础》，也许很多人学到一半就学不下去了，而如果先去看《Head First设计模式》，再去看前面那本书，也许就会发现轻松很多。

大家如果想对微服务有进一步的理解，我这边首推Martin Fowler的 Microservices - a definition of this new architecturalterm ，微服务这个词也是在这篇文章里被首次提出，可以说是微服务的一手资料了。阅读这篇著作，你可以：

对微服务的来源有更深入的了解，知道微服务这种设计模式，和Unix以及 康威定律 的关系；

看到微服务是如何影响软件开发的 组织结构 的，其实也就是康威定律；

看到Martin Fowler总结的设计微服务系统的几个原则；

从这篇著作底下的参考文献，看到一些助推了微服务架构的 原始论文 。

架构这种东西，和设计模式非常相像，两者都是针对某一类问题的解决方案。和设计模式一样，每种架构都有其优点，当然也会有缺点。只有弄清楚为什么要用这种架构，不用会怎样，用了又会怎样，知其然知其所以然，才能对架构进行灵活运用，在实际项目中发挥架构的优势。

哈哈，最后的最后，福利来了，填写以下调查问卷，并积极留言，将有机会获得由微服务架构大神Chris Richardson所著的《微服务架构设计模式》图书一本！

640?wx_fmt=jpeg