负载均衡篇-小饭馆客流量变大了

、前言这是《大话云原生》系列的第二篇第一篇《煮饺子与docker、kubernetes之间的关系》推出之后受到大家的欢迎很多朋友联系到我给我加油打气感谢我会继续写下去书接上回介绍了《煮饺子与docker、kubernetes之间的关系》之后小娜同学我老婆问为什么不把服务统一开发成一个应用搞什么分布式这样感觉很庞大很复杂啊为什么要这么搞所以大话云原生第二篇-负载均衡篇现在开始二、从路边摊说起周五晚上加了班下班的时候已经很晚了打电话给小娜打算去吃烧烤就去我们经常去的那家“夫妻摊位”烧烤。到了之后才发现“夫妻摊位”升级了现在变成了“夫妻饭馆”。由于已经比较晚了店里人并不多就和老板娘聊了起来。聊聊小饭馆的昨天、今天和明天老板娘介绍到“以前路边摊的时候我俩刚结婚手里资金有限就想着开一个路边烧烤摊。我老公负责烤串做菜我呢、负责服务收银及上菜。挣点小钱”。老板娘谦虚等我年纪大了没准也搞个烤串的营生谁让我爱吃呢老板娘说之所以能走到今天主要是因为以下几点她的摊位很少会出现长时间的等菜的现象。因为摊位的桌椅板凳的容量通常是有限的通常也没那么多客人食品总的需求量的上限也基本是固定的相对好协调。沟通顺畅、快速这头点菜点串吼一嗓子、那边就开始做上了。做好了再吼一嗓子就上菜了。短小精悍、容易掉头。夫妻俩之所以选择从路边摊开始是因为船小好掉头。有可能干一阵发现这个位置客流少就可以立刻停止经营或者换个地方经营。哎别说夫妻俩这个阶段就有点像一些软件服务创业公司刚开始创业的时候一般做的应用服务都是单体应用。笔者也见过一些小型创业公司上来就想搞微服务云原生我觉得这不太现实。企业的架构都是一步一步衍进的不要总想着一口吃一个胖子。如果京东淘宝从第一天做应用服务的时候就想做成今天的样子他们一定活不到今天。就像一个没开过饭店的人第一次创业就要开五星级饭店等待他的十有八九就是失败这里我所说的单体应用的特点其实和路边摊的特点是差不多的能够接纳的请求数量时有限的一是从需求上没那么多用户二是创业公司资源限制服务器的内存、CPU配置是有限的。单体应用的视图层、控制层、持久层全都在一个应用里面调用方便、响应快速。服务间没有远程调用RPC响应速度更快一些具体到某个服务请求的响应结果更快。开发简单、上手快、三五个人团队好管好用。老板决定不干了随时可以掉头基本不太肉疼。还是要祝贺老板娘啊生财有道还会总结经验三、开饭馆与负载均衡前一段时间就已经有人愿意为了吃他们夫妻做的烧烤排队了这夫妻俩一想我们这俩人也干不过来啊怎么办招人吧、扩大规模吧。招什么人当然是厨师啊、端菜收银的妻子自己还能干得过来主要是丈夫的活挺不住了对那就招厨师。不能让多出来的客人站着吃吧租一个附近的门市、添置更多的桌椅板凳。同样的道理软件应用中的单体应用服务扛不住用户需求了怎么办加服务器啊多部署几个服务啊负载均衡啊。说说客户端负载均衡与服务端负载均衡小夫妻两一口气为饭馆配置了三个厨师含丈夫这下可够用了。妻子将单号订单给张厨师、双号订单给李厨师两人都干不过来了再将订单给丈夫。反正外人不用白不用自己家人能歇会就歇会。她说给谁就给谁她有自己的一套算法。这种模式就是“客户端负载均衡”妻子作为客户端调用“厨师”服务会记得总共有几个厨师然后按照自己的算法将用户请求转发给其中一个厨师。我们常见的Spring Cloud每个服务请求其他微服务的时候都在其内部维护一个微服务列表然后根据请求目标及算法从微服务中选择一个服务进行远程服务调用。有一天这俩厨师提出意见这么干太累了没有闲着时候要么丈夫多出力要么涨工资。夫妻俩一合计现在实力也不是很雄厚还是丈夫多出力吧。那妻子也就没有必要记住“订单的单双号”了就使用一款app输入顾客订单该app可以实现订单的均衡分配给厨师。“这种模式就是“服务端负载均衡””。对于软件架构而言该app就是负载均衡器常用的软件负载均衡器有nginx、haproxy等。还有一些硬件的负载均衡器性能上要更好一些当然收费也更“好”。架构如下图所示利与弊“利”就是应用的处理能力增加了能够处理更多的订单。“弊”就是沟通成本增加了原来吼一嗓子解决的问题现在需要靠app转发了负载均衡器。无论是远程服务调用还是请求转发转发都是耗时的。也就是说饭店(应用服务)现在处理请求吞吐量上的能力增强了但是在单个请求的处理速度上实际上是下降了。实际上这就是服务拆分的结果服务拆分就是在“用时间换空间”。各位细品四、饭后沟通吃完烤串之后我将上面的一套理论将给了小娜她很感兴趣“软件架构真是脱离不开实际生活啊到处都是活生生的例子”。我趁势吹起了牛逼“这才哪到哪下回带你去个大饭店见见世面有微服务的大饭店”。