每次的请求由这些实例来均摊，这样也的确能够暂时解决访问量大的问题。但是维护起来十分的麻烦，部署的流程也很繁琐。每次部署你得更新所有的实例，万一数量多，又在不同的机器上，很有可能因为操作失误引发线上的事故。而且有可能让老版本的服务兼容新版的前端或者客户端，造成不必要的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暂时稳定了下来。不过还有很多事情可以继续去做。
参考：
往期文章：
什么？你竟然还没有用这几个chrome插件？
手把手教你从零开始搭建SpringBoot后端项目框架
用go-module作为包管理器搭建go的web服务器
WebAssembly完全入门——了解wasm的前世今身
相关：
个人网站： Lunhao Hu
微信公众号： SH的全栈笔记（或直接在添加公众号界面搜索微信号LunhaoHu）