关于java:大话云原生负载均衡篇小饭馆客流量变大了

44次阅读

共计 2256 个字符,预计需要花费 6 分钟才能阅读完成。

一、前言

这是《大话云原生》系列的第二篇,第一篇《煮饺子与 docker、kubernetes 之间的关系》推出之后受到大家的欢送,很多敌人分割到我给我加油打气,感激!我会持续写下去!
书接上回介绍了《煮饺子与 docker、kubernetes 之间的关系》之后,小娜同学(我老婆)问:为什么不把服务对立开发成一个利用?搞什么分布式?这样感觉很宏大,很简单啊?为什么要这么搞?所以大话云原生第二篇 - 负载平衡篇,当初开始!

二、从路边摊说起

周五早晨加了班,上班的时候曾经很晚了,打电话给小娜打算去吃烧烤,就去咱们常常去的那家“夫妻摊位”烧烤。到了之后才发现“夫妻摊位”降级了,当初变成了“夫妻饭馆”。因为曾经比拟晚了,店里人并不多,就和老板娘聊了起来。聊聊小饭馆的昨天、明天和今天!

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

  • 她的摊位很少会呈现长时间的等菜的景象。因为摊位的桌椅板凳的容量通常是无限的,通常也没那么多客人,食品总的需求量的下限也根本是固定的,绝对好协调。
  • 沟通顺畅、疾速,这头点菜点串吼一嗓子、那边就开始做上了。做好了再吼一嗓子,就上菜了。
  • 短小精悍、容易掉头。夫妻俩之所以抉择从路边摊开始,是因为船小好掉头。有可能干一阵发现这个地位客流少,就能够立即进行经营或者换个中央经营。

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

这里我所说的单体利用的特点,其实和路边摊的特点是差不多的:

  • 可能接收的申请数量时无限的,一是从需要上没那么多用户,二是守业公司资源限度,服务器的内存、CPU 配置是无限的。
  • 单体利用的视图层、管制层、长久层全都在一个利用外面,调用不便、响应疾速。服务间没有近程调用 RPC,响应速度更快一些,具体到某个服务申请的响应后果更快。
  • 开发简略、上手快、三五个人团队好管好用。老板决定不干了,随时能够掉头,根本不太肉疼。

还是要恭喜老板娘啊,生财有道,还会总结经验!

三、开饭馆与负载平衡

前一段时间就曾经有人违心为了吃他们夫妻做的烧烤排队了,这夫妻俩一想,咱们这俩人也干不过去啊,怎么办?招人吧、扩充规模吧。

  • 招什么人?当然是厨师啊、端菜收银的妻子本人还无能得过去,次要是丈夫的活挺不住了,对,那就招厨师。
  • 不能让多进去的客人站着吃吧?租一个左近的门市、添置更多的桌椅板凳。

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

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

  • 小夫妻两一口气为饭馆配置了三个厨师(含丈夫),这下可够用了。妻子将 单号订单 给张厨师、双号订单 给李厨师,两人都干不过去了,再将订单给丈夫。反正外人不必白不必,本人家人能歇会就歇会。她说给谁就给谁,她有本人的一套算法。这种模式就是“客户端负载平衡”,妻子作为客户端调用“厨师”服务,会记得总共有几个厨师,而后依照本人的算法将用户申请转发给其中一个厨师。咱们常见的 Spring Cloud 每个服务申请其余微服务的时候,都在其外部保护一个微服务列表,而后依据申请指标及算法从微服务中抉择一个服务进行近程服务调用。
  • 有一天这俩厨师提出意见:这么干太累了没有闲着时候,要么丈夫多出力,要么涨工资。夫妻俩一共计当初实力也不是很雄厚,还是丈夫多出力吧。那妻子也就没有必要记住“订单的单双号”了,就应用一款 app 输出顾客订单,该 app 能够实现订单的平衡调配给厨师。“这种模式就是“服务端负载平衡””。对于软件架构而言该 app 就是负载均衡器,罕用的软件负载均衡器有 nginx、haproxy 等。还有一些硬件的负载均衡器,性能上要更好一些,当然免费也更“好”。架构如下图所示:

利与弊:

  • “利”就是利用的解决能力减少了,可能解决更多的订单。
  • “弊”就是沟通成本增加了,原来吼一嗓子解决的问题,当初须要靠 app 转发了(负载均衡器)。无论是近程服务调用,还是申请转发转发都是耗时的。

也就是说:饭店 (应用服务) 当初解决申请吞吐量上的能力加强了,然而在单个申请的处理速度上实际上是降落了。实际上这就是服务拆分的后果,服务拆分就是在 “用工夫换空间”。各位细品!

四、饭后沟通

吃完烤串之后,我将下面的一套实践将给了小娜,她很感兴趣:“软件架构真是脱离不开理论生存啊,到处都是活生生的例子”。我趁势吹起了牛逼:“这才哪到哪,下回带你去个大饭店见见世面,有微服务的大饭店!”。

欢送关注我的博客,更多精品常识合集

本文转载注明出处(必须带连贯,不能只转文字):字母哥博客 – zimug.com

感觉对您有帮忙的话,帮我点赞、分享!您的反对是我不竭的创作能源!。另外,笔者最近一段时间输入了如下的精品内容,期待您的关注。

  • 《kafka 修炼之道》
  • 《手摸手教你学 Spring Boot2.0》
  • 《Spring Security-JWT-OAuth2 一本通》
  • 《实战前后端拆散 RBAC 权限管理系统》
  • 《实战 SpringCloud 微服务从青铜到王者》
正文完
 0