微服务架构进化论

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

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

生活中的单体应用

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

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

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

分布式系统阶段 (酒店)

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

1、为了解决客流量持续增高，夫妻又招聘了4位厨师

2、为了解决单个订单处理速度下降的问题，将厨师分为两组，一组专门做烧烤，一组专门做饭菜。专业的人做专业的事情，注意力越集中，办事越熟练、效率越高。

服务治理阶段（大酒店）

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

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

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

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

1.分布式系统架构存在问题通过___解决。服务治理

2. 下列描述微服务架构正确的是____。将一套系统拆分成不同子系统部署在不同服务器上

微服务的拆分规范和原则

压力模型拆分

压力模型简单来说就是用户访问量，我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。

压力模型拆解为三个维度：

1、高频高并发场景

低频突发流量场景

原因：

秒杀场景它并不是高频场景（偶尔发生），但是它会产生突发流量。再跟大家举一个例子，那就是“商品发布”，对新零售业务来说，当开设一个线下大型卖场以后，需要将所有库存商品一键上架，这里的商品总数是个非常庞大的数字（几十万+），瞬间就可以打出很高的QPS

低频流量场景

业务模型拆分

业务模型拆分的维度有很多，我们在实际项目中应该综合各个不同维度做考量。我这里主要从主链路、领域模型和用户群体三个维度。

主链路拆分

在电商领域"主链路"是一个很重要的业务链条，它是指用户完成下单场景所必须经过的场景。按照我们平时买买买的剁手经验，可以识别出很多核心主链路，比如商品搜索->商品详情页->购物车模块- >订单结算->支付业务，这是就是一条最简单的主链路。如果这是一场战斗的话，那么主链路就是这场战斗的正面战场，我们必须力保主链路不失守。

核心主链路拆分，有以下几个目的：

1、异常容错：为主链路建立层次化的降级策略（多级降级），以及合理的熔断策略。

2、调配资源：主链路通常来讲都是高频场景，自然需要更多的计算资源，最主要的体现就是集群里分配的虚机数量多。

3、服务隔离：主链路是主打输出的C位，把主链路与其他打辅助的业务服务隔离开来，避免边缘服务的异常情况影响到主链路。

领域模型拆分

领域驱动设计DDD（Domain-Driven Design 领域驱动设计）不是一个新概念，但老外们有个毛病，做什么事情特别喜欢提炼方法论，本来一个非常简单的概念，愣是被吹到神乎其神高深莫测。

用户群体拆分

根据用户群体做拆分，我们首先要了解自己的系统业务里有哪些用户，比如说电商领域，我们有2C的小卖家，也有2B的大客户，在集团内部有运营、采购、还有客服小二等等。对每个不同的用户群体来说，即便是相同的业务领域，也有该群体其独有的业务场景。用户群体相当于一个二级域，我们建议先根据主链路和领域模型做一级域的拆分，再结合具体的业务分析，看是否需要在用户领域方向上做更细粒度的拆分。

1.下列属于拆分模型的是___。压力模型拆分

为什么选择Spring Cloud

Spring Cloud与Netflix

Netflix是一家做视频网站的公司，之所以要说一下这个公司是因为 Spring Cloud在发展之初，Netflix做了很大的贡献。包括服务注册中心Eureka、服务调用Ribbon、Feign，服务容错限流Hystrix、服务网关Zuul等众多组件都是Netflix贡献给Spring Cloud社区的。