系统架构师之——软件架构设计

一 架构是什么

架构是什么？

IEEE 1471的定义是“一个系统的组织来实现特定的功能或一组功能组件的集合。术语“系统”包括单个应用程序，传统意义上的系统，子系统，系统系统，产品线，产品系列，整个企业以及其他感兴趣的集合”。

一个系统的诞生是一个软件过程，即将需求转换成实现的过程，是软件的生命周期。而软件生命周期的模型，称之为软件过程模型。如：

• -瀑布模型
• -增量模型
• -演化模型
• -喷泉模型
• -基于架构的开发模型
• -形式化方法模型
• 而，软件过程= 计算过程+架构设计，如下图

对于构件的组织与结构对于架构的描述有架构描述语言（ADL）描述。各种组织开发了不同的ADL，例如UML。常见的ADL元素是连接器，组件和配置。

例如：

架构定义描述组件结构：

架构定义描述行为：

工作、学习中我们经常会碰到“系统架构”“软件架构”这两个词，很多人认为他们是一样的，其实不然！系统=多个组件+子系统。

本文适用人群：

• -经常与信息化系统打交道的同学
• -需要经常写方案的同学
• -项目管理，系统架构
• -做二次开发的程序员等
• -即将成为不想被技术忽悠的企业高管、老板等
• -软考高级系统架构师
• -开发入门小白，编程开发初学者
• 更多资讯请关注公众号：freo-studio

二架构原则与风格

1-架构风格/架构模式是什么？

软件架构风格也称之为软件架构模式（有人认为架构模式与架构风格有区别，其实目的是一致的，一般不分开），是用于组织组件、结构构成的原理，依据结构组织定义了抽象框架。

软件架构模式负责的功能就是：

• 组件与连接器的清单及组合规则
• 针对常见问题提供解决方案，完善分区块与重构
• 描述组件与连接器的接口方式
• 组件要定义要：通用接口、可重构、可替换、低耦合、模块化
• 连接器定义要：通用性、低耦合、健壮性

总而言之，架构风格定义描述了系统，并给定约束和清单列表（component+connector）。

基本上一个软件系统都是基于多种架构风格模式组合而成，而每一种架构风格都是针对不同的系统需求目录而实现的。这些常见的系统架构目录需要包含以下内容：

• 一组组件component需要进行系统函数调用请求
• 一组连接器connector需要支持不同组件之间的通信、调用、同步、异步操作
• ADL描述需要包含如何集成组件以形成系统
• 运行时所有关系组件component的拓扑分布描述图

2-常用架构设计方法有哪些？

通常针对不同的场景区域有不同的架构设计，参考如下：

2-常用架构风格有哪些分类？

• 数据流风格：批处理序列、管道/过滤器
• 调用/返回风格：主程序/子程序、面向对象风格、层次结构
• 独立构件风格：进程通信、事件系统
• 虚拟机风格：解析器、规则系统
• 仓库风格：数据库系统、超文本系统、黑白系统

而根据企业架构分类分有：

• 业务架构
• 应用软件架构
• 信息架构：数据-存储，资源管理
• 信息技术架构：软硬件块组织，涵盖企业全部信息化

经典架构风格

• 管道/过滤器：数据流的方式，如UnixShell程序、传统编译器
• 
  

特点优点:

-使得构件具有良好的隐蔽性、高内聚、低耦合

-运行设计将IO行为看成多个过滤器行为的合成

-支持软件重用

-系统维护简单

-允许对吞吐量、死锁等属性进行分析

-支持并行执行

缺点缺陷:

-进程形成批处理结构，增量式处理数据

-不适合处理交互应用

-数据传输没有通用标准，导致每一个过滤器解析合成数据导致系统性能下降，且导致过滤器复杂。

• 面向对象风格：数据的表示与行为封装在抽象类型/对象中

特点优点：

-对象隐藏其数据、行为表示，操作方便，互不影响

-设计可以将数据存取问题分割成为交互的代理程序集合

缺点缺陷：

-对象更新导致的连锁问题，多次调用导致更新问题

• 基于事件的隐式调用：广播、订阅、注册中心

特点优点：

-软件重构方便

-系统迭代、更新方便

缺点缺陷：

-放弃了对系统计算的控制，下游调用的不可控、不确定是否对其他构件的影响，需要增加接口发布版本控制来保证

-数据交互问题，全局性资源调用数据交互不便

-过程依赖于被触发事件的上下文

• 分层系统：下层服务层、下层客户层
• 仓库系统及知识库：黑板系统
• C2组件连接器风格：一条绳上多个蚂蚱
• C/S客户机服务器风格
• B/S浏览器服务器风格
• 多层架构风格：三层架构MVC模型
• 富互联网应用风格:RIA/Flex/Silverlight等
• 正交软件架构风格Orthogonal
• 层次消息总线架构Hierarchy Message Bus ,HMB
• 特定领域软件架构DSSA：垂直域、水平域

3-架构设计的整体过程？

主要过程是对系统进行分解成为一个个组件及其交互，以满足非功能、功能性需求。架构设计一般是三部分：硬件架构、软件架构、系统架构，整体过程如下：

大致需要经历以下几个步骤：

Step 1 业务需求及问题的理解及分析

• 关键性的一步，影响到后续的软件质量
• 没有理解关键性问题，不可能提出有效的解决方案
• 项目失败的关键问题所在于此

Step 2 确定设计元素和彼此的关系

• 为系统边界、上下文定义好基线baseline
• 根据需求进行分解组件

Step3 评估架构设计

• 列好系统质量相关属性的要求，确定评估方向，方便评估
• 如果没有做质量属性评估，架构设计工作可能会被推翻重来

Step4 转换实现架构设计

• 架构评估后进行，进行优化、分解、转换成ADL
• 关注于设计解决方案
• 利用运算符、应用设计描述符来标识，如分解、复用、压缩、抽象
• 反复递归评估设计

4-架构设计一般要遵守什么原则？

针对架构设计好坏的标准，我们需要遵守一定的设计原则，这样设计出来的系统架构才能更友好、更优雅，才是好架构。原则一般分两部分：架构原则+设计原则。

架构原则主要是针对宏观的，整体项目的把控原则，为保证项目交付；设计原则是针对软件设计部分的原则，对整体编码程序的把控原则，为保证程序交付。

主要架构原则有：

• 用得久不如用的好：不要想着设计架构使得一个系统能很久很多年，要想着设计一个架构能使得系统更容易适应业务变化而变化；
• 需要风险评估、模型分析：利用可视化设计工具如UML进行需求分析与决策设计、矛盾冲突分析
• 利用模型、视图作为交流协作的工具：理解关键的技术块和区域是最容易出差
• 使用增量、迭代开发模型（方法）

主要设计原则有：

• 关注联系分离，将系统划分为各个组件，避免重叠冲突。高内聚、低耦合，避免组件之间过依赖高
• 功能单一性原则，每一个模块提供特定功能。方便模块之间整合、用户使用
• 透明性原则,组件之间、模块之间应该透明，减少依赖
• 大量设计前需要细化
• 避免功能重复交叉
• 重构时，尽量组合，而不是继承
• 逻辑层组件做好组件的区分
• 做好各个层次之间的通信协议、数据格式
• 系统服务组件应该抽象化
• 做好错误异常处理机制
• 做好日志审计跟踪机制
• 命名规则规范化

三 架构模型

1-架构模型种类

传统分类如下：

• 结构模型
• 框架模型
• 动态模型
• 过程模型
• 功能模型

各有优缺点，集合其优点一哥们Kruchten提出“4+1”视图模型。也就是我们现在常用的架构模型。其模型图如下：

逻辑视图如：

开发视图如：

进程视图如：

物理视图如：

而随着云技术云服务的发展，传统的架构理念已经无法满足我们系统需求。而根据Mark Richards《软件架构模式》最新的架构模型分类为：

• 分层架构
• 微内核架构
• 微服务架构模型
• 事件驱动架构
• 基于空间的架构

图书参考：

https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/

3-如何根据实际情况选择适合自己的架构模型？

软件架构的模型涉及到影响系统的质量、性能、可维护性和整体性、安全性等，针对侧重点进行取舍。不考虑常见问题和长期后果可能会使您的系统面临风险，通常采用多样式的组合构成整个系统。

参考：

1. https://www.tutorialspoint.com/software_architecture_design/key_principles.htm