【大话云原生】负载均衡篇-小饭馆客流量变大了

文章目录

一、前言

这是《大话云原生》系列的第二篇，第一篇《煮饺子与docker、kubernetes之间的关系》推出之后受到大家的欢迎，很多朋友联系到我给我加油打气，还得到了CSDN头部博主哪吒大佬的支持，感谢！我会继续写下去！

书接上回介绍了《煮饺子与docker、kubernetes之间的关系》之后，小娜同学（我老婆）问：为什么不把服务统一开发成一个应用？搞什么分布式？这样感觉很庞大，很复杂啊？为什么要这么搞？所以大话云原生第二篇-负载均衡篇，现在开始！

二、从路边摊说起

周五晚上加了班，下班的时候已经很晚了，打电话给小娜打算去吃烧烤，就去我们经常去的那家“夫妻摊位”烧烤。到了之后才发现“夫妻摊位”升级了，现在变成了“夫妻饭馆”。由于已经比较晚了，店里人并不多，就和老板娘聊了起来。聊聊小饭馆的昨天、今天和明天！

老板娘介绍到：“以前路边摊的时候我俩刚结婚，手里资金有限，就想着开一个路边烧烤摊。我老公负责烤串做菜，我呢、负责服务收银及上菜。挣点小钱！”。老板娘谦虚，等我年纪大了没准也搞个烤串的营生，谁让我爱吃呢！老板娘说之所以能走到今天，主要是因为以下几点：

她的摊位很少会出现长时间的等菜的现象。因为摊位的桌椅板凳的容量通常是有限的，通常也没那么多客人，食品总的需求量的上限也基本是固定的，相对好协调。
沟通顺畅、快速，这头点菜点串吼一嗓子、那边就开始做上了。做好了再吼一嗓子，就上菜了。
短小精悍、容易掉头。夫妻俩之所以选择从路边摊开始，是因为船小好掉头。有可能干一阵发现这个位置客流少，就可以立刻停止经营或者换个地方经营。

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

这里我所说的单体应用的特点，其实和路边摊的特点是差不多的：

能够接纳的请求数量时有限的，一是从需求上没那么多用户，二是创业公司资源限制，服务器的内存、CPU配置是有限的。
单体应用的视图层、控制层、持久层全都在一个应用里面，调用方便、响应快速。服务间没有远程调用RPC，响应速度更快一些，具体到某个服务请求的响应结果更快。
开发简单、上手快、三五个人团队好管好用。老板决定不干了，随时可以掉头，基本不太肉疼。

还是要祝贺老板娘啊，生财有道，还会总结经验！

三、开饭馆与负载均衡

前一段时间就已经有人愿意为了吃他们夫妻做的烧烤排队了，这夫妻俩一想，我们这俩人也干不过来啊，怎么办？招人吧、扩大规模吧。

招什么人？当然是厨师啊、端菜收银的妻子自己还能干得过来，主要是丈夫的活挺不住了，对，那就招厨师。
不能让多出来的客人站着吃吧？租一个附近的门市、添置更多的桌椅板凳。

同样的道理，软件应用中的单体应用服务扛不住用户需求了怎么办，加服务器啊，多部署几个服务啊，负载均衡啊。

说说客户端负载均衡与服务端负载均衡

小夫妻两一口气为饭馆配置了三个厨师（含丈夫），这下可够用了。妻子将单号订单给张厨师、双号订单给李厨师，两人都干不过来了，再将订单给丈夫。反正外人不用白不用，自己家人能歇会就歇会。她说给谁就给谁，她有自己的一套算法。这种模式就是“客户端负载均衡”，妻子作为客户端调用“厨师”服务，会记得总共有几个厨师，然后按照自己的算法将用户请求转发给其中一个厨师。我们常见的Spring Cloud每个服务请求其他微服务的时候，都在其内部维护一个微服务列表，然后根据请求目标及算法从微服务中选择一个服务进行远程服务调用。
有一天这俩厨师提出意见：这么干太累了没有闲着时候，要么丈夫多出力，要么涨工资。夫妻俩一合计现在实力也不是很雄厚，还是丈夫多出力吧。那妻子也就没有必要记住“订单的单双号”了，就使用一款app输入顾客订单，该app可以实现订单的均衡分配给厨师。“这种模式就是“服务端负载均衡””。对于软件架构而言该app就是负载均衡器，常用的软件负载均衡器有nginx、haproxy等。还有一些硬件的负载均衡器，性能上要更好一些，当然收费也更“好”。架构如下图所示：