架构设计思维——阅读笔记11

原文链接：https://mp.weixin.qq.com/s/Rr9U8S8cLSfm186BHjtVLg

　　　　　https://mp.weixin.qq.com/s/f1ZlEpvbnox_re14ceCgFQ

分解作为架构设计中关键的步骤，架构分解没有成熟的方法体系来指导架构师，但是以上的过程和纬度可以作为一定的参考来进行架构分解，架构分解的关键点在于分解纬度和分解战术，

架构分解过程是一个迭代的模型。通过这个迭代的分解，从无到有、从粗到细、从模糊到清晰，一步步精（细）化、丰富架构。迭代的过程也是一个否定之否定的过程，随着分解的逐步推进或系统的架构演化，后面的分解除了会识别出隐性需求，也可能会对先前识别出的架构作出调整。

架构分解就是从多个维度多层次对系统进行分解，识别出架构元素，逐步精化、丰富系统架构的过程。从上面可以总结出，纬度大致有，业务纬度、业务功能纬度、技术纬度，涉众纬度。

根据具体的系统，还可发掘出许多分解维度，如时间维度、物理空间维度、优先级维度、职责角色维度（不同的角色）、客户端维度、调用方维度（不同的调用方）、请求类型维度、数据维度、数据处理维度。纬度就看架构师对于需求的理解程度多深刻。

将分解完成的各个组件或子系统，通过合适的方式，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。分解+集成可以理解为架构最核心的思考方式和方法。

架构思维中的分解和集成是随着系统的演化进行演化，从单体架构到ESB为代表的SOA架构再到现在流行的微服务，集成方式也从直接依赖到ESB为枢纽再到多种形式存在的微服务集成

SOA体系下，服务之间通过企业服务总线（Enterprise Service Bus）通信，许多业务逻辑在中间层（消息的路由、转换和组织）。

微服务架构倾向于降低中心消息总线（类似于ESB）的依赖，将业务逻辑分布在每个具体的服务终端。大部分微服务基于HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。