在使用微服务架构下，leader让开发自足决定服务的拆分和创建，加上大家撸起袖子就干的精神。导致服务像雨后春笋般拔地而起。一开始我们都认为这种方式很健康：开发效率提高了、服务能够独立部署和回滚。但是等服务到达一定数量后出现的问题也越来越多。
-
服务部署越来越麻烦，部署的服务存在依赖关系，运维完全不清楚应该优先部署哪个服务。
-
服务调用凌乱，出现循环依赖，基础服务调用业务服务等问题。
上面问题的出现是因为没有做好依赖管理而导致的结果。在最初创建服务的时候我们更多的关注在服务的职责上，快速迭代开发完成功能，很少关注服务的依赖关系，祸根由此埋下。
既然知道问题的原因就好解，回顾我们在单体解决依赖问题的规则：自顶向下，不能同层调用等。由此梳理我们现有的服务得出三层服务，三层服务的出现是为了起到指导作用：
- 控制调用层数，按照现有规模和能力控制在三层内；
- 稳定性要求由服务所在层数决定；
- 服务越通用，越要下沉；
服务分层的出现要求创建服务时除了要回答服务的职责还要回答"为谁服务"。
依赖关系必须指向更稳定的方向
在微服务架构下，我们常常想如何评估一个服务的稳定性。但是因为没有一个统一的标准，所以都是根据已有的经验进行感观的判断，这种判断往往是拍脑袋决定。直到翻开《架构整洁之道》看到了稳定依赖原则。
稳定依赖原则定义了一个方法来量化稳定性。
- Fan-in：入向依赖，这个指标指代了组件外部类依赖于组件内部类的数量。
- Fan-out：出向依赖，这个指标指代了组件内部类依赖于组件外部类的数量。
- I：不稳定性，I = Fan-out/(Fan-in + Fan-out)。该指标的稳定范围是[0,1]，I=0意味着组件是最稳定的，I=1意味着组件是最不稳定的。
这个方法同样适用于量化服务的稳定性且可复制。
爆炸半径是指爆炸发生时距爆炸源的距离。
回顾我们出现过的P1事故，原因往往是因为基础服务（上图L2/L3的服务）异常而导致。在微服务架构下，不同层服务因为存在调用关系，越底层的服务出现异常，影响的服务越多，事故级别自然越高。所以我们对L2/L3层服务稳定性和性能要求更高，而且需要服务的职责更单一、通用，从而减少改动，减少事故发生。
在一个比较长的时间里我们都很纠结什么是平台？什么是中台？它们之间的区别是什么？翻查了很多资料因为没有得到一个明确的答案，所以我们不再纠结于它们的区别而是回到它的本质：复用。复用的目的是为了避免重复造轮子，从而提升开发效率，加速产品推向市场。在这个目的指导下我们应该更多的思考：如何在不同业务/团队/部门/子公司之间找到该复用但没复用的技术资源，并把它下沉成能够复用的资源，支撑业务发展。
L1、L2、L3中我们把L2、L3定为平台服务，而这里面的大部分服务都是从L1层下沉而来，可以说是L1基石，也因为有了L2，L3层，才让L1层服务可以在市场上快速试错。快到一个开发在一个版本期间就可以实现一个新业务。这个过程离不开平台的逐渐沉淀，所以说平台/中台不是设计出来，而是演进而来，根据公司业务慢慢沉淀。
在微服务架构下运维遇到的其中一个问题是：应该优先部署哪些服务？在每次版本提测期间都会有十几，二十个微服务需要部署，而服务之间由于存在依赖调用关系，如果部署顺序出错就会导致服务短暂的不可用，但是运维又如何知道它们之间的关系呢？这时分层的作用就展示出来了，只要按照L3->L2->L1进行部署，这个问题也就解决了。
服务分层属于架构治理的范畴，但是这块因为在前期即使没有遵守好规则也只是造成不痛不痒的问题，所以被我们忽略了。但是当服务变多的时候，表面的问题又把本质问题掩盖了，最后导致微服务的收益下降，所以前期还是要做好架构治理。