如何给老婆解释什么是微服务

Posted by ZY on March 3, 2018

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

一个周日的清晨,阳光洒在我的脸上,慢慢把我唤醒。我翻过身,感觉好像少了些什么东西,缓缓地睁开眼睛,“咦,老婆呢?”
突然,我发现床上多了张纸条:

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

我一脸懵逼,将纸翻了过来:

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

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

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

不管怎样,既然你选择了这条路,也就别怪我不仁不义,再见。不,再也不见。 —— 对你很失望的静香

我渐渐地缓过神来,百感交集,思绪万千,冥想了一会,拿起手机,给她发了信息:
“下午四点,老地方,给你解释什么是微服务。”

沃尔兹百货超市

我提前十五分钟来到了咖啡厅。临近四点,我开始望着门口,59分49秒,一个熟悉的身影走了进来,戴着墨镜,披着纱巾,是她。
“服务员,一个芝士蛋糕,两杯拿铁,谢谢”,我对服务员说。

“说吧,你有什么要解释的?”
“嗯,首先,我向你保证,我在看的“微服务”,绝对不是你想的那种“服务””
“那是什么?”
“这个解释起来要花点时间,我们先吃点蛋糕,待会再慢慢和你解释”

过了一会,蛋糕吃的差不多了。“看到对面那家沃尔兹百货超市了么?”,我指着窗外面的沃尔兹超市,对老婆说。
“嗯?”
“那里面什么都有,衣服、食品、文具、家私、电器,应有尽有,而且不管你去到哪一家连锁店,店里的格局都是一模一样的。也正因为如此,这才带来了问题。”
“有什么问题呢?我觉得这样挺好呀,顾客去了那里,想买什么都找得着。”
“首先,这些卖不同物品的隔间之间会互相影响。你看,一楼是珠宝店和电器店,假如珠宝店想进行装修,装修时的噪声和灰尘,势必会影响到电器店;还有,假如由于电器店一名员工的疏忽,引发了火灾,旁边的珠宝店是不是也会受到牵连?”
“你这乌鸦嘴…”
“哈哈,都说是假如啦。除了这点,还有一个问题,我考考你,我们这个城市里有几家沃尔兹超市?”
“我想想,好像就这一家?”
“没错,只在西区这里开了一家店。这时候市场总监发现,住在东区的多是上层阶级,他们对珠宝的需求量比较大,这时候要怎么办?”
“那就在东区也开一家沃尔兹百货超市罗。”
“嗯,只能是这样了,可是东区的居民对其他东西的需求并不多,而沃尔兹超市又想让每家分店卖的东西都是一样的,所以他们不得不在东区开一家分店,不仅卖珠宝,也卖食品、衣服还有其他东西“
“这挺浪费的呀,为了满足人们对珠宝的需求,又开了一个百货超市。”,老婆若有所思。
“的确,什么都有、什么都卖的百货超市实在是太笨重了,这才有了“微服务””
“哦?终于要讲微服务了?哼哼。”

沃尔兹小店

“你看,假如我们把沃尔兹百货超市,拆成很多个卖不同商品的小店,比如卖珠宝的沃尔福、卖家私的沃尔家、卖食品的沃尔良还有卖衣服的沃尔衣,这些提供不同服务的店,分布在城市的各个地方,这样他们之间就不会互相影响了。东区二巷的沃尔家搞装修,三巷的沃尔福不会受到影响;三巷的沃尔福发生火灾了,二巷的沃尔家也安然无恙。”
“Soga,原来是这种微服务”,老婆笑着说。
“不仅如此,现在,我们发现东区的居民对珠宝的需求量大,那我们就在东区多开几家沃尔福,而在西区,中产阶级较多的地方,我们就多开几家沃尔良。”
“哇塞,这样看来,微服务让沃尔兹变得轻巧了许多!哪个地方对某种服务的需求大,就在对应的地方多开几家卖那种服务的小店就好了。”

沃尔兹网店

“看来微服务就是把一个百货店变成各个小店嘛,讲这个东西至于用那么厚一本书么?”,老婆是个好奇心很强的女生。
“哈,微服务当然不只是这些,我们现在只是把一个百货店拆成各个小店,但是对于如何管理这些小店,我们还没做好准备”
“哦?这里面还有什么门道?”
“当然,别忘了,沃尔兹可是有网店的。以前还是百货超市的时候,要是有顾客从网上买了一件衣服,那直接从百货超市的仓库里取出这件衣服,给顾客寄过去就好了;现在呢,每一家卖衣服的沃尔衣都有自己的仓库,顾客下单后,工作人员要怎么知道顾客所在区域有哪几家沃尔衣?要从哪家沃尔衣发货呢?
“哟西,还有这个问题。那沃尔兹总店肯定知道他们在哪个地方开有什么分店吧?”
“没错,这时候网店工作人员会从总店那里查出,顾客收货地址所在区域有哪些家沃尔衣,接下来就是从这些沃尔衣店里,选一家,给顾客寄快递过去。”
“就选离顾客最近那一家就好啦。”
“哈,那万一东区有两家沃尔衣,一家靠近居民区,一家靠近商业区,而顾客通常写的收获地址都是写自己家呢?”
“这样… 那靠近居民区的沃尔衣就会收到很多订单,经常要不断的进货,而靠近商业区的那家,就没什么订单了,是吧?”,老婆睁大双眼看着我。
“对!这就是问题,所以网店工作人员会对在一个区域内的沃尔衣,进行轮流发货的操作,比如这一次是靠近居民区的这家发货,那下一次,就让靠近商业区的沃尔衣发货。”
“Soga!”
“用计算机术语来说,就是Load Balancing,负载均衡”
“呵呵,少扯这些术语,我只知道New Balance”
“哈哈,怎么样,微服务不是你想象的那样吧,当然,在经济学领域,要考虑的因素还有很多,现实生活中的沃尔兹依然是一个大百货超市,自然是有它的道理的。微服务的应用主要是在更为纯粹的计算机领域,也就是你看到的那些代码”
“得了,看到那些头就大,走,带我去娘家拿行李”
“……”

对程序员的话

用了大白话,给老婆讲明白了微服务的来龙去脉,当然,我还是有些话想说的,还是怕老婆听完一脸懵逼,没给她说:
1、
讲微服务,就不得不从单体应用(Monolithic )讲起。
所谓单体应用,就像一开始的沃尔兹百货超市一样,把所有业务的代码都放在一起。这对于小型项目来说自然是很合适的,可是项目一旦大了起来,业务一多,这个单体也就膨胀了,膨胀后的单体应用主要有以下两个缺点:

  • 牵一发而动全身。我改了一个业务的一行代码,需要重启整个单体应用,这显然不不合理的。就像珠宝店装修时影响了旁边的电器店,电器店着火时殃及珠宝店一样。
  • 只能水平扩展,不能纵向扩展。对于单体应用,如果发现某一业务的请求量非常大,那么是无法单独扩展该业务的,只能拷贝整个单体应用,再部署一套环境,来实现集群。

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

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

  • 服务注册中心:一个服务可以有多个实例,那么我们在向一个服务发出请求的时候,怎么知道这个服务有哪些实例呢?为了减少手工维护的麻烦,我们需要服务注册中心。每个服务实例在启动时,向注册中心注册自己的IP地址等信息。这样,服务在调用别的服务的接口时,就可以通过注册中心,查询到其他服务的实例,向实例发起请求。沃尔兹总店就是起到注册中心的作用。
  • 负载均衡:由于一个服务可以有多个实例,所以不管是来自外部客户端的请求,还是微服务系统内部服务之间发起的请求,都需要引入负载均衡的机制,来发挥多实例集群的作用。有的书也称这两种负载均衡为服务器端负载均衡客户端负载均衡,各自具有代表性意义的实现分别是Nginx和Ribbon。
  • API Gateway:一个外部请求过来之后,我们需要知道这个请求是发给哪个服务的,也就是我们需要一个请求路由的功能,比如/cm/*的请求,要发给客户管理服务,/om/*的请求,要发给订单管理服务。另外,不是所有请求都可以被我们系统处理的,我们需要判断这个请求是否携带一些必要的鉴权信息,并对其进行鉴权,也就是请求过滤的功能。而API Gateway,就是起到了这两个功能,它就像整个微服务系统的门面,所有请求,都要先经过它的处理,才会转发到对应的服务。
  • ……

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

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

  • 对微服务的来源有更深入的了解,知道微服务这种设计模式,和Unix以及康威定律的关系;
  • 看到微服务是如何影响软件开发的组织结构的,其实也就是康威定律;
  • 看到Martin Fowler总结的设计微服务系统的几个原则;
  • 从这篇著作底下的参考文献,看到一些助推了微服务架构的原始论文

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

参考