浅谈系统架构设计-从架构设计原理、架构设计原则、架构设计方法展开

我们工作中一直强调要做架构设计、系分，最近前端同学在追求前端质量提升的时候，也在进行架构设计、前端系分的推广，那到底什么是架构设计和系分？该怎么做架构设计和系分？本文尝试对架构设计进行全面的介绍和分享，希望统一相关认识和术语，推动我们自己架构设计和系分工作的专业发展。

架构发展历程

第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）

《人月神话》作者布鲁克斯率领的IBM System/360操作系统开发，2000多个程序员共计5000人/年的工作量，将近100万行源码，总共投入5亿美元，是美国的“曼哈顿”原子弹计划投入的1/4，项目进度却一再延迟，软件质量也得不到保障。为了解决问题，1968、1969年，提出了“软件工程”和“结构化程序设计”两种解决方案。“结构化程序设计”就是面向过程的设计思想。

第二次软件危机与面向对象（20 世纪 80 年代）

第二次软件危机主要体现在软件的“扩展”变得非常复杂，促进了面向对象设计思想的发展。面向对象真正开始流行是在 20 世纪 80 年代，主要得益于 C++ 的功劳，后来的 Java、C# 把面向对象推向了新的高峰。到现在为止，面向对象已经成为了主流的开发思想。

软件架构的真正流行(20 世纪 90 年代开始)

软件架构的出现有其历史必然性。20 世纪 60 年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；20 世纪 80 年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；到了 20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。

架构设计原则

SOLID 原则

单一职责：与 Unix 哲学所倡导的“Do one thing and do it well”不谋而合；
开闭原则：用新增（扩展）来取代修改（破坏现有封装），这与函数式的 immutable 思想也有异曲同工之妙；
里式替换：父类能够出现的地方子类一定能够出现，这样它们之间才算是具备继承的“Is-A”关系；
接口隔离：不要让一个类依赖另一个类中用不到的接口，简单说就是最小化组件之间的接口依赖和耦合；
依赖反转：依赖抽象类与接口，而不是具体实现；让低层次模块依赖高层次模块的稳定抽象，实现解耦。

其他通用原则

正交性：架构同一层次拆分出的各组件之间，应该尽量保持正交，即彼此职责独立，边界清晰，没有重叠；
高内聚：同一组件内部应该是高度内聚的（cohesive），像是一个不可分割的整体（否则就应该拆开）；
低耦合：不同组件之间应该尽量减少耦合（coupling），既降低相互的变化影响，也能增强组件可复用性；
隔离变化：许多架构原则与模式的本质都是在隔离变化 —— 将预期可能变化的部分都隔离到一块，减少发生变化时受影响（需要修改代码、重新测试或产生故障隐患）的其他稳定部分。

架构设计思想

面向过程设计(POD:Procedure Oriented Design)

面向过程其实是一种与人的思维方式很一致的设计方法，将一个事情的处理步骤按照顺序的去执行。在这过程中一般都会使用Top-Down的方法，自顶向下逐步求精的逐步分解一个任务。并且在这个过程中考虑分层，模块化等具体的组织方式，从而分解软件的复杂度。当软件的复杂度不是很大或者要实现的功能的模型与面向过程的设计很契合的情景中，面向过程是一种简单直观的设计方法，也能得到很好的效果。

面向对象设计(OOD:Object Oriented Design)

面向对象的程序设计通过将现实世界中的事物概念映射到程序设计中的“对象”概念上，现实世界中事物的属性和行为映射到“对象”的属性和方法。程序通过各种对象之间的调用以及协作，从而实现计算机软件的功能。跟很多工程方法一样，面向设计的初衷就是一种处理软件复杂度的设计方法。

领域驱动设计(DDD:Domain-Driven Design)

是面向对象设计的一种方法，是一种与敏捷开发相适应的对系统进行逐步迭代的面向对象的分析和建模方法。

面向切面编程(AOP:Aspect Oriented Programming)

可以通过预编译方式和运行其动态代理实现在不修改源代码的情况下给程序动态统一添加某种特定功能的一种技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,提高代码的灵活性和可扩展性，AOP可以说也是这种目标的一种实现。
AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。
而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。

架构设计分类

可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构。业务架构是战略，应用架构是战术，技术架构是装备。

业务架构（俯视架构）

包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

应用架构（剖面架构，也叫逻辑架构图）

硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

数据架构

数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

代码架构（也叫开发架构）

子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

技术架构

技术架构，确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

部署拓扑架构图（实际物理架构图）

拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。

四种架构框架

单体架构(MVC)

初级架构，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring mvc或者Python Drango框架的应用。

分布式架构(SOA)

中级架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也大量采用分布式数据库，如redis、ES、solor等。通过LVS/Nginx代理应用，将用户请求均衡的负载到不同的服务器上。
SOA即面向服务的架构，这种架构在九几年的时候就被提出了。SOA往往与企业服务总线联系在一起，通过业务将项目划分为不同的服务，部署在不同的服务器上，即我们以前常说的分布式即指SOA架构的应用。服务之间可以通过WebService等中间件进行通讯，像现在比较流行的Dubbo应用也属于SOA架构的应用。

微服务架构（容器化）

主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。

Serverless架构(云原生)

当我们还在容器的浪潮中前行时，已经有一些革命先驱悄然布局另外一个云计算战场：Serverless架构。
Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数、调用时长等方式进行计费，有效的节省应用成本。

四种架构方法

方法一：UML

架构师使用模型来表述系统，从需求的层次上，建模的主要对象是系统需求。而模型是一个抽象概念，需要借助于特定工具进行表述，目前使用最广泛的建模工具是UML。
三个主要的模型：
功能模型：从用户的角度展示系统的功能，包括用例图。
对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。
UML依然应该是每个程序员的制图工具箱中最常用和必备的工具之一。

方法二：4+1 View Model

系统架构的五种视图
逻辑视图（Logical view）：描述系统为终端用户提供的功能，一般会通过UML中的类图和状态图来表示；关注系统功能，包括：逻辑层次划分、子系统、子模块划分、功能接口、业务逻辑关系；
过程视图（Process view）：描述系统的动态行为，包括流程和交互等，一般会通过 UML 中的时序图、活动图和通讯图来表示；关注系统的并发和同步问题，包括：进程、线程、对象实例、并发、同步、通信、可伸缩、高可用、安全性；
开发视图（Development view）：从程序员的视角来阐述系统，也被称为“实现视图”，一般会通过 UML 中的组件图和包图来表示；关注程序实现，包括：源程序、第三方SDK、程序框架、类库、程序的可扩展、可重用、可移植、操作系统、中间件选型；
物理视图（Physical view）：从系统工程师的角度来描述系统，包括系统组件的物理拓扑、各组件之间的物理连接，也被称为“部署视图”，一般会通过 UML 中的部署图来表示；关注系统的安装和部署问题，包括：物理设备和网络的部署、软件安装、部署、系统软件选型、物理节点拓扑；
场景（Scenarios）：通过一小组用例或场景来描述架构，包括系统中各种对象和进程之间的交互时序，也被称为“用例视图”。这些场景会被用于识别架构元素（architectural elements）以及阐述和验证整个架构设计，也可以被作为架构原型的测试起点。
补充：数据视图：关注持久化数据的存储，包括：实体及实体关系、数据存储方式、格式、数据传递、复制、同步策略；

方法三：C4 Model

Context、Container、Component 和 Code（可选）
C4 模型通过容器、组件、代码以及人这几个抽象来描述一个软件系统的静态结构，它的核心理念是希望像 Google Map 一样，通过不同层次的细节，为代码建立一种可以放大和缩小的导览图。它最关键的思想就是自顶向下对系统的静态结构进行逐级拆分，依次描述各层次对象的职责、关系和外部依赖。除了核心的层次化静态结构视图，它还可以包含动态视图、部署视图等补充视图
L1：系统顶层大图（System Context diagram, big picture）视角。包括最中心的软件系统、周边的用户以及其他有交互的系统。其中最关键的两个概念分别是：人和软件系统。
L2：容器图（Container diagram）视角。容器图不仅展示了系统的进一步职责拆分，还包括了主要的技术选型、容器之间的通讯方式等关键架构信息。这类图可以面向全部的技术人员，既包括架构师、开发者，也包括运维人员、技术支持等。
L3：组件图（Component diagram）视角。包括各个组件的职责定义、技术与实现细节等。随着层次的下沉和细节的增多，组件图的受众范围进一步缩窄，一般只适用于软件架构师和开发者（其他角色没必要理解，一般也理解不了）。
L4：代码（Code）视角。以图的形式（e.g. UML 类图、数据库 E/R 图）展示类或文件粒度的代码结构，并不是真正的代码本身。

方法四：arc42

arc42 并不是一种架构制图方法，而是一个架构文档模板。
本质上 arc42 中提倡的制图方法与C4模型是等价和兼容的，完全可以配合使用：以 arc42 作为架构文档框架，其中的架构制图采用更具体的 C4 模型。

各阶段架构要点

架构视图	关注点	工具&输出
业务架构	包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象	PRD、用例图、业务流程图
应用架构	应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。应用架构图关键有2点： ① 职责划分：明确应用（各个逻辑模块或者子系统）边界逻辑分层；子系统、模块定义；关键类。 ②职责之间的协作：接口协议：应用对外输出的接口。协作关系：应用之间的调用关系。	逻辑架构图、时序图、接口文档
数据架构	1数据是集中还是分布存储的？如何考虑分布式存储 2领域模型到数据库表的转换？表结构关系的设计 3实体如何设计？充血模型和贫血模型 4使用什么数据库关系型还是非关系形	数据架构图、ER图、uml类图
技术架构	确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握	部署架构图（抽象）
代码架构	1分层结构设计 2开发语言、开发框架、开发工具 3模块划分 4开发规范 5软件质量属性	开发脚手架、开发规范、测试规范、接口文档
部署架构	拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础	物理架构图（实际）

质量评估标准

功能适合性	与产品实际需求一致	需求评审，系分评审，测分评审
性能效率	有无压测	是否进行压力测试记录性能指标
兼容性	前端系统兼容,系统升级接口兼容	多平台（机型）兼容性测试,新老版本接口兼容性测试
可用性	与产品实际需求一致	需求评审
可靠性	是否有监控告警，是否是单点	架构设计，系分评审
安全性	安全扫描编码规范	云服务使用waf/IDC
可维护性	方便修改/扩展	架构设计,系分评审

问题和规划

问题：

公司项目上线初期该具备的文档/图都具备，只是在后续需求的迭代过程中，存在更新不及时的情况，如架构图时更新不及时，导致后续的维护/查阅产生相应的不便。

目前各业务线目前需求较多，暂时没有时间去补充相应的材料，且随着业务的变化，有些系统在迭代过程中已经或是将要发生调整，可以在确认后再进行梳理。

规划：

1、各业务线相关资料（全局库）更新及时，业务线人员对系统状态理解一致，方便用于了解相关业务最新情况。

2、推动开发内部最佳实践的积累，规避常见工具使用不当引发的问题，减少因技术栈/工具不统一，中间件使用不规范带来的后续维护成本的增加。

3、关注公共组件和中台能力的开发及应用，在日常需求开发中，对复用程度高的代码和模块进行组件化封装和中台化建设，比如前端活动组件、埋点组件；后端日志组件、消息组件；中台消息中心、扶摇活动引擎、星火投放等。

其他相关内容

软件设计模式

设计模式简介 | 菜鸟教程
设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。
根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）

软件质量模型

功能适合性：功能完整度、功能正确性和功能恰当性；
性能效率：时间表现（e.g. 响应时间）、资源利用和容量；
兼容性：共存能力（e.g. 多版本组件共存）和互操作性；
可用性：可学习性、可运维性、用户错误保护（e.g. 自动纠错）、UI 美观度、可访问性；
可靠性：成熟度、可用性、容错性、可恢复性；
安全性：机密性、完整性、不可伪造性、权威性和可审计；
可维护性：模块度、可复用性、可分析性、可修改性、可测试性；
可移植性：可适配性、可安装性、可替代性。