从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化

Posted IT有个圈儿

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化相关的知识,希望对你有一定的参考价值。

 
   
   
 
▲点击图片领取50本互联网书籍
推荐阅读

微服务近些年可谓是发展的如火如荼,和别人谈技术不聊点“微服务”,会让自己感觉很落伍。很多人聊微服务,但真的把微服务聊的通俗、聊的通透的人并不多。
我想以一种非常通俗的方式和大家解释一下微服务,就是以“夫妻摊位”到“五星饭店”发展的角度为例,为大家说明一下微服务及微服务所解决的问题,带来的挑战。

第一阶段:夫妻摊位

小夫妻俩刚结婚,手里资金有限,就想着开一个路边烧烤摊。丈夫负责烤串做菜、妻子负责服务收银及上菜。这是一个典型的路边烧烤摊的经营模式。大家仔细看这种经营模式的好处在于:

  • 因为摊位的桌椅板凳的容量通常是有限的,所以食品总的需求量的上限也基本是固定的。这种摊位很少会出现长时间的等菜的现象。

  • 沟通顺畅、快速,这头点菜点串吼一嗓子、那边就开始做上了。做好了再吼一嗓子,就上菜了。

  • 短小精悍、容易掉头。夫妻两有可能干一阵发现这个位置客流少或者只赚辛苦不赚钱,就可以立刻停止经营、换个地方经营或者找别的营生。

这个阶段就有点像一些创业公司,刚开始创业的时候,一般做的应用都是单体应用。笔者也见过一些创业公司,上来就想搞微服务,我觉得这是不太现实。企业的架构都是一步一步衍进的,不要总想着一口吃一个胖子。如果京东淘宝从第一天做应用的时候就想做成今天的样子,他们一定活不到今天。就像一个没开过饭店的人第一次创业就要开五星级饭店,等待他的十有八九就是失败!
那么单体应用的特点有哪些:

  • 能够接纳的请求数量时有限的,因为服务器的内存、CPU配置是有限的。

  • 展现层、控制层、持久层全都在一个应用里面,调用方便、快速。单个请求的响应结果超快。

  • 开发简单、上手快、三五个人团队好管好用。老板决定不干了,随时可以掉头,基本不太肉疼。

第二阶段:门面饭馆

但是,随着小夫妻俩经营有方、待客有道,开始有人愿意为了吃他们做的烧烤排队了。夫妻俩一想,我们这俩人也干不过来啊,怎么办?招人吧、扩大规模吧。

  • 招什么人?当然是厨师啊、端菜收银的妻子自己还能干得过来,主要是丈夫的活挺不住了。那就招厨师。

  • 不能让人站着吃吧?租一个附近的门市、添置更多的桌椅板凳。

客户端负载均衡与服务端负载均衡是什么?

  • 小夫妻两一口气为饭馆配置了三个厨师(含丈夫),这下可够用了。妻子将单号订单给张厨师、双号订单给李厨师,两人都干不过来了,再将订单给丈夫。反正外人不用白不用,自己家人能歇会就歇会。这种模式就是“客户端负载均衡”,所有的订单全都记在“妻子”的脑袋里,她说给谁就给谁。

  • 有一天这俩厨师提出意见:太累了,要么丈夫多出力,要么涨工资。夫妻俩一合计,还是丈夫多出力吧。那妻子也就没有必要记住“订单的单双号”了,所以就使用一款app,妻子输入顾客订单,该app可以实现订单的均衡分配给厨师。“这种模式就是“服务端负载均衡””,该app就是负载均衡器,常用的软件负载均衡器有nginx、haproxy等。还有一些硬件的负载均衡器,性能上要更好一些,当然收费也更“好”。

从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化

利与弊

  • “利”就是应用的处理能力增加了,能够处理更多的订单。

  • “弊”就是沟通成本增加了,原来吼一嗓子解决的问题,现在需要app转发了(负载均衡器)

也就是说:饭店(应用)现在在处理并发请求的能力和容量上增强了,但是在单个请求的处理速度上下降了。实际上,这就是服务拆分,服务拆分就是在 “用时间换空间” 。你细品!

第三阶段:核心分工精细化

为了解决上一阶段遇到的问题:单个请求的处理速度下降。也就是饭店针对单个订单做菜响应速度下降了,但是由于饭店的菜确实好吃、菜品精良,客流量又持续的增高。该店又再次面临扩容的问题。

  • 为了解决客流量持续增高,夫妻又招聘了4位厨师

  • 为了解决单个订单处理速度下降的问题,将厨师分为两组,一组专门做烧烤,一组专门做饭菜。专业的人做专业的事情,注意力越集中,办事越熟练、效率越高。

新的问题又出现了,有的顾客既点烧烤又点饭菜。导致后端两组厨师之间沟通不畅,怎么组合套餐推送给前台?厨师之间怎么调用、怎么沟通啊?谁是头?谁是大脑?谁记得A厨师的烧烤和B厨师的饭菜是一桌的?
从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化
丈夫一看这种情况,我也别再做厨师了,那做什么?做菜品的配置管理、做订单的服务注册。丈夫负责主动观察问询各工种的工作状态并记录,妻子主动向丈夫问询后端厨师的状态,并根据丈夫的反馈分配订单(客户端负载均衡)。丈夫的新工作实际上就产生了微服务非常重要的组件:服务注册中心和配置管理中心。比如:Spring Cloud Alibaba nacos、eureka、consul、zookeeper、Spring cloud config等

第四阶段:配套管理专业化

从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化

  • 需要有统一的门面了:前台。所有的顾客进来,由前台统一接待。比如:Spring Cloud Gateway和zuul。

  • 需要有安保人员了:档次高了、进入饭店有预约。最起码得尊重用餐礼仪,不能是背心裤衩大跨栏,否则就不让你进。比如:OAuth2 认证服务器和资源服务器。

  • 菜品限量提供了:法式菜品、意大利菜品、日本料理。什么时间可以吃得到、可提供多少人份?这些服务都是有限制的。比如:Hytrix熔断限流。

  • 工作效率监督:工作流程中每个岗位做了什么工作、用了多长时间。哪个环节出现问题、哪个岗位需要调整。比如:Sleuth、Zipkin、日志监控ELK等。

第五阶段:容器化、自动化

饭店的规模越来越大了、岗位分工也越来越细了。真的成了超级大饭店了,怎么管?这就需要专业的机器人服务租用公司,这种公司专门出租各种行业专用机器人。

  • 服务员统一包装:用自动点餐机、机器人。身高必须一米65,微笑必须漏出四颗牙。

  • 物料统一包装:也不用人了,流水作业,一盘菜几块肉、什么料全都自动化配置好。厨师就负责炒熟就行了(拜托,这例子理解就好,不要抬杠)

总之全都自动化。这时公司内部的devops团队就出现了,制定规范、集体包装、流程自动化。突然有一天,饭店承接了大型运动会大型展览,怎么办?要去招服务员么?招员工培训么?不要,租机器人就行了,用完了就还回去。每年的双十一、淘宝京东也都是用容器自动化扩容的方式应对暴涨的服务需求。容器化最大的好处就是:轻量级的发布于与销毁、自动化的扩容。

  • 这里的机器人公司,我们可以认为是kubernetes、mesos、swarm

  • 这里的机器人,我们可以认为是docker、containerd等








以上是关于从“夫妻摊位”到“五星饭店”,从发展角度看微服务架构进化的主要内容,如果未能解决你的问题,请参考以下文章

从一个实验看微服务架构---不谈理念讲干货

SoundCloud的微服务启示:从交付流程和康威定律看微服务

从服务治理以及分布式发展史的角度剖析Service Mesh的精髓

从源码看微信小程序启动过程

银行业金融机构实施分布式架构的思考

10 月 30 日 北京 LiveVideoStack 阿里云视频云专场限量赠票 100 张