架构实战营毕业总结

作者：娜酱

2021 年 12 月 05 日
本文字数：2223 字
阅读完需：约 7 分钟

一、架构的定义

系统、框架、组件、模块、架构，这几个概念常常让人混淆。要学习架构首先要区分架构相关易混淆的概念，准确掌握架构的定义。系统是一群有关联的个体，个体间按照规则运用，系统能力大于个体能力，自顶向下逐层分解的。子系统是系统的一部分。模块是系统按照逻辑拆分，实现职责分离的作用，即每个模块在系统中扮演它特定的角色，承担特定的任务。组件是系统按照物理结构拆分，以期达到单元复用的目的。比如：学生信息管理系统按逻辑拆分可分为用户模块、成绩模块等，按物理拆分位 Nginx、Web 服务器和 MySQL 等组件。

图 1 概念区分

框架是某个业界标准和完成特定基本任务的软件组件规范或实现规范时所提供的具有基础功能的软件产品。而架构指的是软件系统的“基础结构”，创造这些基础结构的准则以及对这些结构的描述。

以上概念解释清楚后，那如何准确定义架构了，4R 法则清晰地定义架构。软件架构指软件系统的顶层结构（Rank），是分层的，它定义系统由哪些角色（Role）组成，角色之间的关系（Relation）和角色根据运作规则（Rule）协作完成系统工作，简称 4R 架构。以人体来类比，说清楚架构后，会有两个容易混淆的概念分层架构和架构分层。分层架构是一种可扩展架构模式，目的是可扩展，而架构分层是自顶向下，逐步细化。

图 2 4R 架构

作为架构师，主要需要自顶向下的确定层级、拆解系统中包含的角色、定义角色之间的关系和设计角色之间的协作规则。架构文档呈现架构设计的内容，在架构文档中要指明层级、描述角色、定义关系和展现规则。

参照软件开发领域的指导思想、设计原则、成熟模式和实施流程，提出面向复杂度的架构设计体系。

图 3 面向复杂度架构设计体系

二、面向复杂度的架构设计

目前常见的架构设计方法论为面向模式的软件架构、面向风险驱动的架构设计、DDD 和整洁架构。软件系统的复杂度主要来自于业务和质量两方面，李老师将复杂问题简单化，为降低软件系统的复杂度，针对复杂的地方进行架构设计，提出面向复杂度的架构设计体系，如图所示。

图 4 面向复杂度架构设计环

该方法的整体思路为，在进行需求的复杂度判断之前，对需求进行不断的澄清和细化。当需求清晰明了后，判断需求的主要复杂度，并对复杂度进行拆分。针对拆分的复杂度，设计 3 至 4 个备选架构。对备选架构进行判定和取舍，再细化架构方案中的层级(Rank)、角色(Role)、联系(Relation)和运作规则（Rule）,从而形成完整的架构设计方案，实现需求。

在图中，针对需求判断、复杂度拆解和备选架构的取舍，李老师提出架构设计三原则合适原则、简单原则和演化原则。

合适原则：成熟的架构设计方案有很多的，那是简单用以业内通用的架构设计方案，套用自己的软件系统，或者紧跟潮流，用上最新的技术方案？这两种都不可取，架构设计应该根据系统开发拥有的资源、开发周期和业务当前规模，选择合适的架构设计方案，牢记一个原则，“合适优于业界领先”，即不生搬硬套，也不盲目追求领先技术。

简单原则：架构设计是否将业务系统模块拆分的越细越好？NO! 若无必须，不要增加多余的实体。实体数量增加，各实体之间的联系增加，会增加系统的内部复杂度和外部复杂度。从系统的可靠性、可扩展和故障处理效率来说，越复杂，越不可靠，越复杂越难扩展，越复杂，在出故障的时候，故障定位难，处理效率低。因此在架构设计中，简单优于复杂。

演化原则：架构设计需要预测未来的业务规模，从而一步到位，将系统做大做全吗？NO！一个好的架构设计满足当前的业务需求即可，若有业务的变动，对系统进行迭代优化，若当前架构设计迭代优化已经不能满足需要时，再对系统进行重构和重写，即系统整个发展是不断的演化的，演化优于一步到位。

一个软件系统从 0 到 1，往往受到资源、时间和技术三方面的约束，架构设计要在各种约束下，从业务、团队和技术三个判断维度出发，设计出的架构方案要满足当时的业务需要，符合团队和技术的能力水平，符合合适原则；先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化，符合简单原则；当业务发生变化时，架构要扩展、重构，甚至重写，符合演化原则。

在以复杂度为架构设计切入点，架构设计三原则作为指导，以 4R 理论细化架构方案，可得出完整的面向复杂度的架构设计理论。如图所示