“云时代架构”经典文章阅读感想六

（架构设计思维-分解）

这学期因为正在修软件体系架构这门课程，因此需要对软件架构进行深部了解，老师上课经常说的就是要站在架构师的高度去看设计，在设计师不应该是用户需要什么就实现什么，而是应该站在架构师的高度进行挖掘隐性需求。当我们站在架构师的角度去看问题时，视野也会更加明朗，因此一个合格的架构师应该具备的基本修养便是着眼于高远

身为架构师进行架构设计时的思路大体上是：分解、集成、分离、复用、分层、模式、抽象、结构化、迭代、勿做过度设计这几部分，按照这个思维方式来设计系统架构。

分解作为软件架构的关键步骤，而架构分解的关键点在于分解纬度和分解战术。

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

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

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

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

分解纬度就需要系统架构师通过多个维度、多个层次对系统进行分解，识别出架构元素，逐步精华、丰富系统架构的过程。纬度大致有业务的、技术的、涉众的以及业务功能纬度。

分解战术将在架构层面应对非功能需求特性的架构模式或架构策略称为战术，例如对可用性，常用的战术包括：冗余、错误检测。

当然还有其他的架构分解流程：分解的粒度：根据设计者、项目的大小、项目的完成要求等实现自己规定，并没有进行强制规定。

非功能需求类型战术

可用性：高可用集群、服务降级、异步消息

性能：负载均衡集群、缓存（页面、数据）、数据读写分离、数据分片、分库、分表、并发处理、异步处理

可伸缩性：采用弹性云计算平台

数据层面：缓存、垂直伸缩、读写分离、数据分片、分库、分表

应用层面：垂直伸缩、水平复制（水平伸缩）、功能分解（服务无状态）、应用分片

分而治之这是亘古不变的原则，在软件架构中也是如此，在进行软件架构设计时首先应该站在一个高度去看问题，而不仅仅停留在表象。要学会灵活运用架构分解的思想，不能生搬硬套，每个系统都有不同的地方，但是架构分解的思维方式确实应用于各个地方的一个方式。