这里有一份关于系统架构知识的汇总，请查收...

任何软件产品或项目前期都少不了&＃xff1a;需求收集整理、业务规划过程&＃xff0c;后续实施&＃xff0c;研发过程不管采取瀑布模式还是敏捷模式&＃xff0c;在这两者中间还是少不了软件系统架构规划设计过程&＃xff0c;只是架构设计颗粒度和目标要求不同而已&＃xff0c;可作为后续回溯和研发总体方向。

基于以往项目产品实施经验和参考其他相关系统架构理论书籍等&＃xff0c;本文对软件系统架构的总体认识理解&＃xff0c;同时整理做系统架构设计时应遵循模式的相关理论知识&＃xff0c;希望能给初级架构师、系统分析师、产品经理、项目经理、研发经理、研发工程师等有所参考。

01 何为系统架构

虽然命题为软件系统架构&＃xff0c;但软件基本上服务各个领域&＃xff0c;软件系统架构与现实生活中各业务领域的架构本质是一脉相承的。

每个领域都有其相关的特性&＃xff0c;运作当中就存在不同的需求。为了满足不同的需求&＃xff0c;各领域会针对不同需求不断发展出不同的解决方法、手段或工具等。

而在需求提出到实现&＃xff08;涉及方法、工具、手段等&＃xff09;之间&＃xff0c;存在一个对业务需求、业务结构、行为逻辑、属性、关系等理解及分析的过程&＃xff0c;系统性总结出来针对该过程的抽象化描述定义就是系统架构。

举个例子&＃xff0c;下面就我们所熟悉的行业领域来了解的架构是什么。

电影行业的系统架构过程&＃xff0c;如下图&＃xff1a;

从上面业务领域的系统架构&＃xff08;粗颗粒度&＃xff09;过程例子&＃xff0c;我们可以看出架构有如下主要特性&＃xff1a;

• 架构是基于需求的&＃xff0c;在一定范围内&＃xff0c;具有抽象性、时效性、针对性&＃xff1b;
• 需求是有颗粒度的&＃xff0c;所以架构需要根据需求的颗粒度来设计&＃xff1b;
• 需求是多方面的&＃xff0c;需特别关注风险和约束&＃xff0c;所以架构必须体现风险、约束条件等&＃xff1b;
• 架构包含了众多关联群体和他们所关注的事情&＃xff0c;因此架构要体现多维度的视角。

02 设计的前提条件

在开始进行系统架构分析设计时&＃xff0c;有几点是需要遵守的&＃xff1a;

• 只针对某一领域、某一时段内存在的业务需求&＃xff0c;服务于某特定领域业务范围需求&＃xff0c;不可本末倒置&＃xff1b;
• 系统架构设计是需求驱动的&＃xff0c;是会随着需求变化而变化的&＃xff0c;首要条件必须要了解需求&＃xff1b;
• 系统架构只是一个系统性的抽象化描述定义&＃xff1b;
• 系统架构是需要充分考虑约束条件、风险的&＃xff1b;
• 系统架构为所有涉众的人提供一个共同的远景目标&＃xff0c;但架构不包括每个部分的细节。

03 软件系统架构定义

国外相关书籍关于软件系统架构的一种定义如下&＃xff1a;

软件架构为探索如何以最佳方式划分一个系统、如何标识组件、组件之间如何通信、信息如何沟通、组成系统的元素如何能够独立地进化&＃xff0c;以及上述的所有东西如何能够使用形式化的和非形式化的符号加以描述。

简化理解来说&＃xff1a;

软件系统架构可以说是为软件系统提供一个结构、行为和属性的高级抽象过程。

04 软件系统架构价值

软件的系统架构设计体现的价值如下&＃xff1a;

• 保持系统完整和质量&＃xff0c;系统的结构在需求变更中保持弹性。
• 控制复杂度&＃xff0c;架构是一个不同问题和关注点的分解过程。
• 可复用&＃xff0c;架构通过协助行为定义了边界&＃xff0c;从而使各种粒度可以重用。
• 可预见/测试&＃xff0c;系统结构、行为、属性在开始就定义了系统的原型。
• 改善项目沟通和管理&＃xff0c;不同视图支撑不同涉众的关注点&＃xff08;例如组件或者子系统的并行开发&＃xff09;。

架构追求系统的长期效益&＃xff0c;没有架构的系统是代价高昂的&＃xff0c;架构优劣可以用“需求变更成本”衡量。

现实中&＃xff0c;软件行业的相关人员在整个软件研发实施周期过程中&＃xff0c;对软件系统架构设计存在一定认识误区。

下面是主要常见认识误区。

01 架构 &＃61; 系统分析

• 宏观而言&＃xff0c;都需要对需求进行分析。
• 在传统软件开发过程中&＃xff0c;系统分析更侧重于解决某一领域问题&＃xff0c;配合进行可行性分析&＃xff0c;强调与客户(需求方)的沟通&＃xff0c;分析/讨论/评估不确定的需求&＃xff0c;给出系统的设计解决方案。
• 架构则是针对确定的需求进行分析&＃xff0c;并充分考虑领域外的需求&＃xff0c;对软件系统提供结构、行为和属性的抽象&＃xff0c;对软件系统逻辑、运行、开发和部署各个方面给出表述。

02 架构 &＃61; 设计

• 架构是设计的一个表象&＃xff0c;它关注关键元素&＃xff0c;特别是对于性能、可靠性、成本、适用性等有重大影响的元素。
• 架构定义了一些重要的设计决策&＃xff0c;是高层设计规约。
• 架构不关心每个独立元素的详细设计。

03 架构 &＃61; 蓝图

• 架构定义了基础架构&＃xff08;蓝图&＃xff09;&＃xff0c;但更侧重揭示架构元素间的互操作关系。
• 架构还需要表达代码运行时的结构。
• 架构需要使用多个视图&＃xff0c;从多个维度表述不同涉众的不同关注点。

04 架构 &＃61; 技术框架

• 框架实现了架构风格/模式所要求的一些设计规约。
• 框架是设计过程赖以实现的平台&＃xff0c;是开发架构的组成部分。
• 架构是一个动态过程&＃xff0c;而框架是一个相对稳定的工具或者设计模型。

01 设计关注点

软件系统架构是一个演进的过程&＃xff0c;也可以理解是有生命周期的&＃xff0c; 每一阶段的架构都可能被新的架构推翻&＃xff0c;没有完美、恒定的架构。

进行架构设计时我们常关注下面四个方面&＃xff1a;

架构关注的是设计的高层规约&＃xff0c;不关注组成元素内部的细节。

国外相关书籍对“风格/模式“的一定义如下

一种架构风格是一组协作的架构约束&＃xff0c;这些约束限制了架构元素的角色和功能&＃xff0c;以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。

好比我们常提及的面向对象、面向方面、服务组件化架构、SOA、ESB、微服务、消息总线、客户端/服务端等等都是“风格/模式”。

02 应具备的特性

根据前面谈到业务领域的架构特点&＃xff0c;软件系统架构设计也应具备如下几点主要特性&＃xff1a;

A. 相对性

B. 时效性

C. 前瞻性

D. 约束性

同时对于开发人员来说&＃xff0c;技术架构作为系统架构的一部分&＃xff0c;好的架构还应该关注以下指标&＃xff1a;

可靠性、可移植性、可重用、可配置、可定制、可扩展、可进化、可伸缩、效率、性能等。

&＃xff08;具体含义可参考相关的软件架构设计书籍定义&＃xff09;

03 设计流程表述

关于如何开展软件系统架构设计&＃xff0c;综合一些方法论和业界目前普遍的做法&＃xff0c;归纳总结整体流程如下图。

对于架构视图&＃xff0c;不同维度存在各种视图&＃xff0c;目前软件行业内多采用一种软件架构设计方法学&＃xff1a;4&＃43;1视图模型&＃xff0c;使用了5种协作的视图来对软件架构的描述加以组织。每种视图致力于解决一组特定的关注点。

以上为4&＃xff0b;1视图模型图&＃xff08;摘自国外相关书籍&＃xff09;&＃xff0c;即场景视图、逻辑视图、开发视图、过程视图、物理视图5种视图描述。但实际过程中并非每种软件系统架构都需要全部涉及到这5种视图&＃xff0c;需根据实际业务需求而定。

&＃xff08;4&＃43;1视图模型详细说明可参考相关书籍或网上资料&＃xff09;

04 实际设计参考维度

前面提到软件系统架构设计所需关注的要点和方法理论&＃xff0c;在目前软件研发实施周期过程中&＃xff0c;进行软件系统架构设计时&＃xff0c;系统架构师经常会考虑涉及的主要维度如下&＃xff1a;

上图也是我们实际软件系统架构设计时&＃xff0c;经常会用到的参考总图&＃xff0c;但并不是每种软件系统都需要涉及到5个架构&＃xff0c;需根据具体实际需求综合考量使用。

&＃xff08;每种架构详细说明可参考相关书籍或网上资料&＃xff09;

以上只是关于软件系统架构的概述&＃xff0c;提及到的系统架构相关的定义、关注点、价值、目前业界流行的架构设计方法论。所有理论知识参考软件系统架构设计相关书籍和之前多年项目实施经验及验证总结。

最后总结出来的经验&＃xff1a;需求是系统架构的前提&＃xff0c;只有深刻理解需求&＃xff0c;才可能设计出优秀的软件架构。没有完美的软件系统架构&＃xff0c;只有适合的软件系统架构&＃xff1b;没有不变的软件系统架构&＃xff0c;只有不断演进变化系统架构。