架构中的分而治之

今天在云时代架构微信公众号看了一篇文章，叫做《架构设计思维》，文章中多次提到一个词，就是分而治之。所有的系统开发方法都要解决从需求到实践的转换问题，为了提高系统的质量，前人提出了需求分析工程和各种建模技术，但是在需求和设计之间还是很难逾越，也就是说缺乏能够反映做决策的中间过程，于是系统架构设计应运而生。

分而治之是一种处理复杂问题的通用方法，在系统架构中也是一种很重要的手段，例如多层架构、OSI 七层模型都体现了分而治之思想。在架构设计过程中，通过将关注点分离对架构进行多层次分解，将系统层层分解为多个架构元素，进而识别架构元素。同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。

分解的作用：

架构分解是架构师接到需求到完成架构设计中最关键的一步，分解可以帮助架构师了解需求中未呈现出来的隐性需求要素，分解也是架构师解决非功能层面需求的重要手段，架构要解决高性能、高可用、伸缩性、可扩展性等问题，针对这些问题，我们一般从几个方面进行入手：

应用层：按照功能或者微服务进行分解，将系统划分未若干子系统，低耦合存在，在业务角度可以将单个应用独立为应用单元（应用单元是无状态的），这样可以灵活地进行伸缩。

数据层：对数据库进行垂直拆分按照子系统纬度进行分库和水平拆分按照业务纬度进行分表；但是进行分库分表中要避免分布式事务，实在无法避免可利用消息系统来进行规避。

代码结构层：代码层一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。这也是Java Web中重要的三层架构中的三个层次。区分层次的目的即为了“高内聚低耦合”的思想。

 

1. 通过API网关实现级轻量级消息路由，鉴权；
2. 运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；
3. 避免通过数据库集成；
4. 避免部署多个版本来兼容。
   1. 面对一个系统，特别是前人没有做过的新系统，通常难以一下子设计出合适的架构。在架构设计的初期，通常都要经历一个不断探索的阶段。在架构设计过程中，架构分解是必不可少的的关键步骤。如何进行架构分解？从哪里入手开始进行分解？我们需要有一个架构分解的过程模型来指导分解过程，启发和探索架构分解的维度和线索，提高架构分解的效率。
   2. 架构分解过程如下图所示，是一个迭代的模型。通过这个迭代的分解，从无到有、从粗到细、从模糊到清晰，一步步精（细）化、丰富架构。迭代的过程也是一个否定之否定的过程，随着分解的逐步推进或系统的架构演化，后面的分解除了会识别出隐性需求，也可能会对先前识别出的架构作出调整。