微服务架构进化论

单体应用阶段 (夫妻摊位)

在互联网发展的初期，用户数量少，一般网站的流量也很少，但硬件成本较高。因此，一般的企业会将所有的功能都集成在一起开发一个单体应用，然后将该单体应用部署到一台服务器上即可满足业务需求。

 生活中的单体应用

小夫妻俩刚结婚，手里资金有限，就想着开一个路边烧烤摊。丈夫负责烤串做菜、妻子负责服务收银及上菜。这是一个典型的路边烧烤摊的经营模式。

单体应用的特点：

• 能够接纳的请求数量时有限的，因为服务器的内存、CPU配置是有限的。
• 展现层、控制层、持久层全都在一个应用里面，调用方便、快速。单个请求的响应结果超快。
• 开发简单、上手快、三五个人团队好管好用。

垂直应用阶段 （门面饭店）

随着小夫妻俩经营有方、待客有道，开始有人愿意为了吃他们做的烧烤排队了。夫妻俩一想，我们这俩人也干不过来啊，怎么办？招人吧、扩大规模吧。

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

 

问题：

在处理并发请求的能力和容量上增强了，但是在单个请求的处理速度上下降了。

分布式系统阶段 (酒店)

为了解决上一阶段遇到的问题：单个请求的处理速度下降。也就是饭店针对单个订单做菜响应速度下降了，但是由于饭店的菜确实好吃、菜品精良，客流量又持续的增高。该店又再次面临扩容的问题。

• 为了解决客流量持续增高，夫妻又招聘了4位厨师
• 为了解决单个订单处理速度下降的问题，将厨师分为两组，一组专门做烧烤，一组专门做饭菜。专业的人做专业的事情，注意力越集中，办事越熟练、效率越高。

  

服务治理阶段 （大酒店）

新的问题又出现了，有的顾客既点烧烤又点饭菜。导致后端两组厨师之间沟通不畅，怎么组合套餐推送给前台？厨师之间怎么调用、怎么沟通啊？谁是头？谁是大脑？谁记得A厨师的烧烤和B厨师的饭菜是一桌的？

 

 随着服务数量的不断增加，服务中的资源浪费和调度问题日益突出。此时需要增加一个调度中心来治理服务。调度中心可基于访问压力来实时管理集群的容量，从而提高集群的利用率。

 

注意：

在服务治理(SOA）架构中，需要一个企业服务总线(ESB）将基于不同协议的服务节点连接起来，它的工作是转换、解释消息和路由。说白了就是丈夫做菜品的配置管理、做订单的服务注册。丈夫负责主动观察问询各工种的工作状态并记录，妻子主动向丈夫问询后端厨师的状态，并根据丈夫的反馈分配订单。

微服务阶段 （五星大酒店）

饭店的规模越来越大了、岗位分工也越来越细了。真的成了超级大饭店了，怎么管？

么是微服务：

将系统的业务功能划分为极小的独立微服务，每个微服务只关注于完成某个小的任务。系统中的单个微服务可以被独立部署和扩展，且各个微服务之间是高内聚、松耦合的。微服务之间采用轻量化通信机制暴露接来实现通信。

 解释：

• 服务网关：前台。所有的顾客进来，由前台统一接待。比如：Spring Cloud Gateway。
• 熔断机制：菜品限量，法式菜品、意大利菜品、日本料理。什么时间可以吃得到、可提供多少人份？这些服务都是有限制的。
• 工作效率监督：工作流程中每个岗位做了什么工作、用了多长时间。哪个环节出现问题、哪个岗位需要调整。比如： Sleuth、日志监控ELK等。
• 配置中心：菜单，川菜，东北菜，杭帮菜，烩菜。
• 服务集群：厨师微服务集群包含，川菜厨师微服务，杭帮菜厨师微服务等。
• 高可用注册中心：大堂经理，负责那些人上班了,他在哪里干的什么工作。