小强开饭店-从单体应用到微服务

本篇博客经过小强开饭店的通俗易懂的故事，带你了解后端服务是若是从单体应用演变到微服务的。若是有说的不对的地方，欢迎各位大佬强势怼。

小强开饭店

有一天，小强为了早日奔赴小康生活，打算开一个饭店来帮他快速的实现这个目标。

饭店开业了

因而他盘下了一个店面，一顿装修以后，雇了一个厨师，便开业了。

饭店生意变好了

刚刚开业那段时间还好，店里的人虽然多，可是都还能应付的过来。

小强请的厨师手艺很好，再加上小强经营得当，宣传的也不错，慢慢的店里的生意愈来愈好。

慢慢的，顾客愈来愈多。不少时候厨师都忙不过来，你们只有排队在外面等着。渐渐的有些顾客变得十分不耐烦，等不下去了就走了，而后给了这家店差评。这种状况愈演愈烈，小强看到这不是个办法啊，得作点什么。

招聘厨师

小强下了血本，又另外聘请了几位厨艺很好的厨师。

有了这些厨师的加盟，虽然客人不少，饭店的经营也仍是可以勉强的应付的来。口碑也慢慢的由差变好。随着口碑的变好，慕名而来的也随之愈来愈多。

生意火爆

随着顾客愈来愈多，即便厨房的厨师已经招聘满了，都仍是应付不过来。

因而厨师也变成了暴躁的厨师。有的时候由于太忙了还罢工不干了。还得小强去苦口婆心的劝。小强心想这也不是个办法，再这么下去口碑又得下去。因而小强摇身一变，变成了强老板。

强老板开了分店

强老板拿着开饭店赚的钱，在城里的不少地方开了分店，十分的膨胀。这样一来，客人不用大老远的跑到那一家店去了，能够选择离本身近的店。很快，原来的那家生意也渐渐的恢复正常，各个分店的业绩也有所提升。

可是随着强老板的强势宣传，以及顾客之间的自传播，这个参考被愈来愈多的人知道了。可是因为顾客分散，每家店的火爆程度都不一样。有的店甚至陷入了跟最开始的店同样的境地，大量的顾客排队。可是有的店的生意却又十分冷清。

强老板心想，这确定不行啊，这样下去迟早得血亏。因而强老板摇身一变，变成了强总。

强总开了个顾客中心

全部想去餐馆用餐的顾客都来这里，由强老板统一安排的大巴再送至各个分店。每辆车轮流的送至每一家分店。这样一来，就不存在某一家分店生意十分火爆而另外的店生意惨淡的状况了。

强总已达成奔赴小康的目标

读后感

其实这个想法是好久之前不知道在哪儿看博客的时候，看到一位大佬的类比，确实是忘了。而最近恰好在准备分享，因此就打算详细的以图文和故事的方式来让没有了解过这方面的人快速的了解一下。

其实我也纠结过要不要将里面类比概念的解释穿插到故事里，可是后面想了一下，这样应该会干扰到你们对故事自己的理解，从而达不到通俗易懂的效果。因此我将解释单独放在了最后面。

单个饭店

最开始的单个饭店其实就是一个App或者一个网站，来给用户提供服务。能够理解为前端，或者客户端。

单个饭店的厨师

而单个饭店中的厨师，其实就是后端，提供数据，提供服务。一个厨师就对应着一个后端服务的实例。

随着App的访问量愈来愈大，最初的单体应用已经没法扛住这么大的压力了。致使其余的用户进入系统时，系统没法正常的服务。就跟咱们如今打开一个网站同样，凡是超过2-3秒没有反应就直接宣告它的死刑了，直接退出-卸载二连。

单个饭店的多个厨师

多个厨师则是相应的后端服务启动了多个实例，每一个实例都是彻底同样的，只不过是运行在不一样的机器上或者不一样的端口上。

每次的请求由这些实例来均摊，这样也的确可以暂时解决访问量大的问题。可是维护起来十分的麻烦，部署的流程也很繁琐。每次部署你得更新全部的实例，万一数量多，又在不一样的机器上，颇有可能由于操做失误引起线上的事故。并且有可能让老版本的服务兼容新版的前端或者客户端，形成没必要要的BUG。

再退一万步，就算全部的实例都在同一个服务器上，万一真的访问量到了必定的量级，你得维护多少个实例啊。人工成本巨大。并且一不当心，一觉起来，自己没有问题的服务，由于一夜发生了事件引起了热点，致使你的应用访问量剧增，增到超过你的全部实例可以承受的极限，服务挂了。

再退一万万步，就算你本身维护没有烦死，前端的兄弟可能早就收拾你了。你没有作请求分发的话，全部的服务器地址得由前端去维护。

分店

这里的分店指微服务中的一个服务的多个实例。与以前人工维护的多个实例不一样，这个是由工具帮咱们维护。

这里我拿Docker Swarm举个例子。在Portainer中，你新建了一个服务以后能够选择设置Replicas，也就是实例的数量，固然默认是一个。你能够起10个，20个，可是这里得考虑到你的服务是否支持这样作。若是你的服务不是无状态应用，就很难作到能够自动的作横向扩展。

分店的生意火爆

其实也是同样的，即便有不少个实例，你若是不能控制请求打到哪一个服务上的话，某些实例承受的压力大了同样的会挂。

强总的顾客中心

顾客中心你们能够理解为网关。更具体点能够理解为Zuul。

你的服务有了网关以后，全部的请求都从网关走。根据以及配置的路由，网关能够判断到你想具体到哪一个服务去。

而后就会从本身的服务集群中找到对应的服务，获取到全部的服务实例的服务器IP以及端口。前面说到有可能请求会集中到某几个实例上。而咱们可使用工具来解决这个问题。例如，使用Spring Cloud的核心组件Ribbon。

这个组件的做用是作负载均衡，它可使全部到某个服务的请求，平均的分发到该服务的每一个实例上去。从而避免某几个服务的请求超过其能承受的阙值。固然，Ribbon须要和Spring Cloud的其余核心组件相互协做的。

另一个版本的故事

小强搞了个新闻App，用Spring Boot搭了一个后端，找人用React Native写了个App，就这样上线了。由于其内容和推广都还不错，因此受到了用户的喜好。

可是随着访问量愈来愈大，服务器渐渐扛不住压力。有的用户进App以后甚至要5-6秒才有反应，并且慢的出奇。因而小强开始给服务尽可能的无状态化，而后在一个服务器上启动了几个实例。

一段时间以后，访问量又增大了。小强只好硬着头皮，继续加实例数量，你强任你强，加实例我在行。

有一天，小强一觉起来，发现服务炸了...啊不是，是挂了。由于发生了一些事情引起了巨大的社会舆论，App的访问量剧增。致使新加的实例也没能扛住。

就这样，小强老实的开始了重构。使用Spring Cloud搭建了一个微服务集群，把服务拆分以后，给每一个服务启动了几个实例。同时使用Eureka和Feign来进行服务之间的通讯，使用Ribbon来作负载均衡。

就这样，这个App暂时稳定了下来。不过还有不少事情能够继续去作。

参考：

• 拜托！面试请不要再问我Spring Cloud底层原理

往期文章：

• 什么？你居然尚未用这几个chrome插件？
• 手把手教你从零开始搭建SpringBoot后端项目框架
• 用go-module做为包管理器搭建go的web服务器
• WebAssembly彻底入门——了解wasm的前世今身

相关：

• 我的网站： Lunhao Hu
• 微信公众号： SH的全栈笔记（或直接在添加公众号界面搜索微信号LunhaoHu）