软件架构设计方法论

Posted 2021-04-23 数据中台知行合一

摘要：在产业数字化转型的过程中，软件架构也与时俱进，如时下比较火热的中台架构，乃至更前沿些的无代码平台，甚至到机器编程，可以说无论怎么变，万变不离其宗，底层原理是一致的。本文将从软件架构发展、软件架构规范、软件架构的选型、软件架构的设计、软件架构的实现、软件架构的软技能、软件架构的评估与度量共七个维度阐述软件架构设计。

第一章 软件架构的发展

一、单体架构。

是什么？所有的功能模块耦合在一个服务内。

怎么用？在项目发展初期，由于所有的业务逻辑写在一个应用中，开发、测试、部署变得简单高效。可以快速上线，快速看到效果。

哪里用？商务人员赶某个会展，需要一个演示demo。TO G、TO B某个小众的应用。

二、水平分层架构。

是什么？《领域驱动设计模式、原理与实践》写道：为了避免将代码库变成大泥球（BBoM）并因此减弱领域模型的完整性且最终减弱可用性，系统架构要支持技术复杂性与领域复杂性的分离。引起技术实现发生变化的原因与引起领域逻辑发生变化的原因显然不同，这就导致基础设施和领域逻辑问题会以不同速率发生变化。分层架构将大任务分解成子任务组，其中每个子任务组处于一个特定的抽象层次上。

怎么用？按照单一职责原则划分层次，按照依赖倒置原则确定层与层之间的调用关系，避免层级划分过多影响系统性能。

哪里用？如需要快速构建的新应用程序、传统IT部门和流程的企业或业务应用程序、具有尚不了解其他架构的经验不足的开发人员的团队、需要严格的可维护性和可测试性标准的应用。

三、MVC架构。

（1）展示层（View）。

是什么？视图是用户看到并与之交互的界面。

怎么用？前后端分离。

哪里用？H5，小程序，企业官网宣传。

（2）控制层（Controller）。

是什么？接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示返回的数据。

怎么用？经典的技术有Servlet、Structs、Spring MVC等。

哪里用？业务逻辑整合，编排。

（3）模型层（Model）。

是什么？模型层是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。一个模型可以同时为多个视图提供数据。

怎么用？ORM框架逐渐流行起来，常用的有iBatis、MyBatis、mybatis-plus、Hibernate等。

哪里用？数据库适配、数据访问。

四、SOA服务化架构。

是什么？SOA是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

怎么用？不同类型的服务提供不同的接口，通过RPC接口实现远程调用。高内聚低耦合，标准化的服务接口。支持各种消息模式。精确定义的服务契约。

哪里用？企业服务集成。

五、分布式微服务架构。

是什么？微服务是在2014年由Martin Fowler大神提出的。是SOA服务化架构的延伸。

怎么用？

（1）单一职责。

（2）独立部署、升级、扩展和替换。

（3）支持异构／多种语言。

（4）服务无状态。

（5）服务隔离。

（6）自动化管理：需要对微服务提供自动化部署和监控预警的能力，实现真正的DevOps。

哪里用？大型公司、开发团队技术水平高、业务复杂场景下拆分服务颗粒度。

六、服务网格（Service Mesh）。

是什么？服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。

怎么用？提供统一的全局方法来控制和测量应用或服务之间的所有请求流量 (东西流量EAST-WEST traffic)。

哪里用？对应用程序的运行时操作进行标准化。

第二章 软件架构规范

这里我们使用一幅脑图来表示架构规范，各架构师可以参考这个模板。

第三章 软件架构的选型

一、软件架构建模

逻辑视图、开发视图、进程视图、物理视图、用例视图。

二、软件架构风格

1、数据流风格。批处理、管道-过滤器。

2、调用/返回风格。主程序/子程序、面向对象、层次结构。

3、独立构件风格。进程通信、事件驱动系统。

4、虚拟机风格。解释器、基于规则的系统。

5、仓库风格。数据库系统、超文本系统、黑板系统。

6、闭环控制架构。

7、C2风格。

8、层次架构风格。两层C/S、三层C/S、三层B/S：【表现层（MVC->MVP->MVVM）、中间层、数据访问层（ORM）、数据架构层】、混合架构。

9、富互联网应用RIA。

10、基于服务的架构SOA。

11、微服务架构。

12、MDA（Model Driven Architecture），模型驱动架构。

13、特定领域软件架构DSSA。

14、基于架构的软件设计ABSD。

15、六边形架构。又叫“端口-适配器”模式。

16、CQRS架构。

三、技术选型

1、需求层面的影响。

2、系统设计层面的影响。

3、系统开发层面的影响。

4、系统实施层面的影响。

5、技术实现难度评估。

6、技术优缺点评估及同类技术差异性。

7、技术是否开源及是否稳定。

8、日志处理机制。

9、缓存处理机制。

10、异常处理机制。

11、事务处理机制。

12、并发处理机制。

第四章 软件架构的设计

一、数据架构

1、存储。

1.1、水平切分。

1.1.1、分库。水平分库是按照一定的规则对数据库进行划分。每个数据库中各个表的结构相同，数据存储在不同的数据库中。

1.1.2、分表。水平分表是按照一定的规则对数据表进行划分。每个数据表的结构相同，数据存储在多个分表中。

1.1.3、方法论。水平切分方式有两种：范围法和哈希法。

1.2、垂直切分。将同一类业务相关的数据表划分在同一个库中。

1.2.1、分库。垂直分库是根据业务进行划分的，将同一类业务相关的数据表划分在同一个库中。

1.2.2、分表。垂直分表就是将一个大表根据业务功能拆分成多个分表。例如原表可根据业务分成基本信息表和详细信息表等。

1.2.3、方法论。考虑频度和长度两个属性。

（1）长度较短、访问频率较高的放在一起。

（2）长度较长、访问频度较低的放在一起。

1.3、数据库分组。大部分互联网业务读多写少，数据库的读往往最先成为性能瓶颈。如果希望线性提升数据库的读性能，消除读写锁冲突，提升数据库的写性能，冗余从库实现数据的“读高可用”，那么可以使用分组架构。需要注意的是，在分组架构中，数据库的主库依然是写单点。

二、分布式架构数据一致性

1、特征。

1.1、强一致性。

1.2、弱一致性。

1.3、最终一致性。

2、解决方案

2.1、规避分布式事务——业务整合。A、B、C服务合并为D，本地解决。痛点：耦合。

2.2、分布式事务。

2.2.1、数据库事务中的四大特性（ACID）。

2.2.1.1、事务的原子性和一致性是通过Undo Log来实现的。

2.2.1.2、事务的隔离性是通过数据库锁的机制实现的。

2.2.1.3、事务的持久性是通过Redo Log（重做日志）来实现的。

2.2.2、CAP定理。C（Consistency）：一致性、A（Availability）：可用性、P（Partition Tolerance）：分区容错。

2.2.3、CAP原理证明，任何分布式系统只可以同时满足以上两点，无法三者兼顾。在分布式系统中，网络无法100%可靠，分区其实是一个必然现象。

2.2.4、BASE理论。Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）。

2.2.5、两阶段提交（2PC）。2PC分为两个阶段：

（1）投票阶段（Voting Phase）：参与者通知协调者，协调者反馈结果。

（2）提交阶段（Commit Phase）：收到参与者的反馈后，协调者再向参与者发出通知，根据反馈情况决定各参与者是提交还是回滚。

缺点。两个阶段提交这种解决方案属于牺牲了一部分可用性来换取一致性，对性能的影响较大，不适合高并发、高性能的场景。

2.2.6、三阶段提交（3PC）。是二阶段提交（2PC）的改进版本。

相比2PC的改动点。

（1）、引入超时机制。同时在协调者和参与者中都引入超时机制。

（2）、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

分为CanCommit、PreCommit、DoCommit三个阶段。

优缺点：相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

2.2.7、Paxos。无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

2.2.8、补偿事务（TCC）。TCC其实就是采用的补偿机制，其核心思想是：针对每个操作都要注册一个与其对应的确认和补偿（撤销）操作。分为以下三个阶段：

（1）Try阶段：主要是对业务系统进行检测及资源预留。

（2）Confirm阶段：主要是对业务系统进行确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的，即只要Try成功，Confirm一定成功。

（3）Cancel阶段：主要是在业务执行错误，需要回滚的状态下将执行的业务取消，将预留资源释放。

后置提交。先执行事务，后统一提交。降低数据不一致概率。

缺点。后置提交虽然降低了数据不一致的概率，但是所有库的连接要等到所有事务执行完才释放，这就意味着数据库连接占用的时间增长了，系统整体的吞吐量降低了。

2.2.9、本地消息表（异步确保）。业界使用最多，核心思想是将分布式事务拆分成本地事务进行处理。

三、高可用

1、高可用的特征

1.1、主从

1.2、负载均衡

1.3、横向扩容

2、解决方案

2.1、LVS+Keepalive。

多个虚拟机抢占同一个虚拟IP。keepalive用来检测服务器存活。

2.2、nginx Keepalive

2.3、zookeeper、etcd。

2.4、客户端实现高可用。轮询服务端，选择可用服务器。

2.5、服务端间通信实现高可用。如Redis、kafka。

2.6、通过中间件实现高可用。如mycat实现mysql的高可用，读写分离

2.7、限流、降级、熔断

四、服务部署

1、灰度发布／金丝雀部署。在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是让测试人员对新版本进行线上测试，启动的这个新版本应用就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入新版本上，然后对新版本进行运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。当确认新版本运行良好后，再逐步将更多的流量导入新版本上。在此期间，还可以不断地调整新旧两个版本运行的服务器副本数量，以使新版本能够承受越来越大的流量压力，直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。如果在灰度发布过程中（灰度期）发现新版本有问题，就应该立即将流量切回老版本上，这样会将负面影响控制在最小范围内。

2、蓝绿发布。不停老版本的前提下，部署新版本，然后进行测试。确认新版本没问题后，将流量切到新版本，然后老版本也升级到新版本。

流程：

（1）开始状态：Service 1、Service 2、Service 3、Service 4集群服务一开始的版本为V1，部署在绿色环境。

（2）服务版本2开发了新功能，修复部分的Bug。

（3）在蓝色环境部署Service 1、Service 2、Service 3、Service 4集群服务，测试通过。

（4）通过Nginx将全部流量切到蓝色环境。

（5）删除绿色环境的4个实例：Service 1、Service 2、Service 3、Service 4。

（6）冗余产生的额外维护、配置的成本以及服务器本身运行的开销。

注意事项：

（1）新旧业务共存

（2）同时处理“微服务架构应用”和“传统架构应用”

（3）需要提前考虑数据库与应用部署同步迁移／回滚的问题。

（4）蓝绿部署需要有基础设施支持。疑问：什么基础设施？jenkins、docker、k8s。

（5）在非隔离基础架构（VM、Docker等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

3、滚动发布。一般是停止一个或者多个服务器，执行更新，并重新将其投入使用。

注意事项：

（1）没有一个确定可行的环境。

（2）修改了现有的环境。

（3）回滚困难。

（4）如果部署期间系统自动扩容／缩容了，我们还需判断到底哪个节点使用的哪个代码。

五、监控与运维

分类包括：容器与宿主机的监控（基础监控）、API监控、调用链监控以及应用本身的监控。工具包括：Spring Boot Admin、JsonView、spring-boot-starter-actuator、，Zipkin、OpenTracing、Promethus、Kong。

第五章 软件架构的实现

1、范围管理。

架构师需要和业务方一起确定软件需求范围，制定优先级，评估需求清单是否可以在给定的资源限定的时间内完成。在开发过程中，可以使用敏捷管理。

2、风险管理。

项目进展过程中，很少会有已知的风险跳出来咬你一口；相反，通常都是些未知的、未被发现的风险，不知从哪儿冒出来，让项目陷入停顿。如果可能的话，应在项目前期的评估调研阶段，尽量识别、记录并应对这些潜在的风险。从人、机、料、环、法、测按照MECE原则穷举。对于每一个决定，采用上下文方法提问，这个风险可能出现吗，应对的措施是啥，及时跟进关键节点的过程，实现风险闭环管理。

3、时间管理。

明确里程碑节点

4、沟通协调。

大型项目需要跨部门、跨组织、跨公司协作时，需要统一目标，沟通时求同存异，统一思想，统一步调，技术上能解决的就在技术上解决，技术上不能解决的找领导或商务解决。

第六章 软件架构的软技能

1、温文尔雅。说到做到、坦诚相待，没有人喜欢大老粗，也没有人细化颐指气使的人。

2、沟通协调。多说肯定少说否定、先听后说、善于推销、用不同的语境分别和下级沟通、平级沟通、上级沟通。

3、协商。求同存异。最好的做法是使用架构决策文档来记录每个决定，其背景、替代方案以及选择其中某个方案的理由。

4、领导力。建立战略合作关系、身体力行、用好奥卡姆剃刀法则，做好减法、注意禀赋效应、激发人的善性、做到知行合一。

5、政治。积极参与政治游戏、最大化个人目标与公司目标的重合、帮助别人达成其目标、学会享受过程而不是目标、在关键之处力争出色、 愿意就低优先级目标妥协、不要被别人的糟糕举止得罪、私下处理人际问题。

6、见人说人话，见鬼说鬼话，不同的场景能游刃有余的切换语境。

7、商务知识。

7.1、了解商务：了解营销、财务、投入产出比和销售。

7.2、了解公司：了解产品对客户的价值所在。知道你的公司如何赚钱。了解你公司的历史/文化。

7.4、了解领域：收集领域知识。在商务环境中了解业务领域。帮助公司更好地了解技术。

8、不同角度的认知。市场视角、产品视角、技术视角、运营视角、公司治理视角。

10、智商、情商、逆商，都很重要。

第七章 软件架构的评估与度量

1、软件架构评估-质量属性

1.1、性能。系统的响应能力，代表参数有：响应时间和吞吐量，设计策略主要包括队列、资源调度。

1.2、可用性。正常运行的时间比例，一般用两次故障间的时间间隔表示或者用故障恢复到正常使用的速度。代表参数有：故障间隔时间，设计策略主要包括冗余和心跳检测。

1.3、安全性。向合法用户提供服务同时拒绝向非授权用户提供服务，代表参数有数据完整性、数据机密性、不可抵赖，设计策略主要包括追踪审计、对称加密解密、非对称加密解密、用户认证与授权、访问控制、CA证书、数字签名。

1.4、可修改性。能以较高的性价比响应系统的变更，代表参数有高内聚低耦合，主要策略包括信息隐藏、S.O.L.I.D原则：Single Responsibility Principle(SRP) 单一职责原则、Open Closed Principle(OCP)开闭原则、Liskov Substitution Principle(LSP) 里氏替换原则、Interface Segregation Principle(ISP) 接口隔离原则、Dependency Inversion Principle(DIP) 依赖倒置原则。迪米特法则（最少知道原则）、组合优于继承原则。

1.5、可靠性。在非正常情况下系统正常提供服务的能力，代表参数有MTTR、MTTF、MTBF，设计策略主要包括冗余、心跳。

MTTF (Mean Time To Failure，平均无故障时间)，指系统无故障运行的平均时间，取所有从系统开始正常运行到发生故障之间的时间段的平均值。MTTF =∑T1/ N

MTTR (Mean Time To Repair，平均修复时间)，指系统从发生故障到维修结束之间的时间段的平均值。MTTR =∑(T2+T3)/ N

MTBF (Mean Time Between Failure，平均失效间隔)，指系统两次故障发生时间之间的时间段的平均值。MTBF =∑(T2+T3+T1)/ N

很明显:MTBF= MTTF+ MTTR。

1.6、功能性。系统功能需求实现。代表参数有特性、用户故事、任务优先级，主要策略有UAT测试。

1.7、可变性。体系架构经过扩充能支撑新体系结构，如支撑新产品线。代表参数有可复制性，标准化程度，主要设计策略有领域架构设计，软件产品线。

1.8、互操作性。系统不是独立存在的，能提供接口供外部系统使用，代表参数有二次开发，设计策略包括SDK、REST接口、开放平台。

2、软件架构评估（大型项目架构会用到，控制交付风险和交付质量）

2.1、软件架构分析方法SAAM。

软件架构分析方法（SAAM）是一种通过假想例子的分析，判断给定的应用的软件质量指标是否达标。软件质量指标包括可修改性，健壮性，移植性和可扩展性中得到应用。

2.1.1、服务可修改性。设想不同的应用场景，提前应对各种修改带来的影响。需要满足的原则包括 S.O.L.I.D原则：Single Responsibility Principle(SRP) 单一职责原则、Open Closed Principle(OCP)开闭原则、Liskov Substitution Principle(LSP) 里氏替换原则、Interface Segregation Principle(ISP) 接口隔离原则、Dependency Inversion Principle(DIP) 依赖倒置原则。迪米特法则（最少知道原则）、组合优于继承原则。

2.1.2、服务健壮性。应用的健壮性指标是用于评估软件应对异常情况的能力。异常是指（但不限于）系统设计过程中未考虑到的场景。例如：错误的数据，网络连接异常，权限不足，或者其他系统异常。需要满足的原则包括：1）系统碰到异常的时候是停止还是进行处理呢？2）系统是否会把异常的信息记录到日志里面，以便日后调试呢？3）系统异常后，用户会收到什么样的提示信息呢？

2.1.3、服务可移植性。可移植性指标是用于评估应用是否容易的部署到一个全新的操作系统或设备之上、能在不同的浏览器上正常运行、适配多种屏幕分辨率。需要注意的原则包括：1）是否依赖于硬件，2）是否依赖于操作系统，3）是否依赖于数据源，4）是否依赖于网络。

2.1.4、服务可扩展性。用于评估系统是否易于添加新的功能而对现有功能没有影响。需要注意的原则包括：1） 硬编码 VS 配置，2）应用程序文档（外部文档和代码库文档），3）使用 S.O.L.I.D 设计原则。

2.2、架构权衡分析方法ATAM

架构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)是一种系统架构评估方法，主要在系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。

ATAM可以分为九个步骤。

（1）ATAM 方法的表述：评估负责人向参加会议的项目代表介绍ATAM（简要描述 ATAM 步骤和评估的结果）。

（2）商业动机的表述。项目决策者从商业角度介绍系统的概况。

（3）架构的表述。对架构进行详略适当的介绍。设计师要描述用来满足需求的架构方法或模式，还应描述技术约束条件及与其他系统的交互等。

（4）对架构方法进行分类。通过研究架构文档及倾听上一步的表述，了解系统使用的架构模式和方法（进行明确命名）。

（5）生成质量属性效用树。可以选取这样一棵树：根——质量属性——属性求精（细分）——场景（叶）。修剪这棵树，保留重要场景（不超过 50 个），再对场景按重要性给定优先级（用 H/M/L 的形式），再按场景实现的难易度来确定优先级（用 H/M/L 的形式），这样对所选定的每个场景就有一个优先级对（重要度，难易度），如（H，L）表示该场景重要且易实现。

（6）分析架构方法。评估小组按优先级对上述效用树的场景进行分析（小组成员提问，设计师回答、解释），探查实现场景的架构方法。评估小组把相关架构决策编成文档，确定其有风险决策、无风险决策、敏感点、权衡点，并对其进行分类（分别用表格列出）。

（7）集体讨论并确定场景的优先级。由于项目关系人的不同角色及所关心的场景不一致，因此，应鼓励项目关系人考虑效用树中尚未分析过的场景。集体讨论后，可通过投票的方式获得各场景的优先级。通过把集体讨论确定了优先级的一组场景与效用树中的那组场景进行比较，能发现设计师所想的与项目关系人实际所要的是否存在差距，这一差距是否导致风险。

（8）分析架构方法。类似于第 6 步，这时，评估小组引导设计师实现在第7 步中得到的优先级最高的场景。

（9）结果的表述。把在 ATAM 分析中得到的各种信息进行归纳总结，并呈现给项目关系人。主要有：

• 已编写了文档的架构方法；

• 经过讨论得到的场景集合及其优先级；

• 质量效用树；

• 所发现的有风险决策；

• 已编成文档的无风险决策；

• 所发现的敏感点和权衡点。

至此，本文尝试按照软件生命周期过程介绍不同过程中使用的一些方法论，与诸君共勉。愿诸君一起在终生学习、终生成长。