系统架构完整实例

步基

已于 2024-09-24 12:19:10 修改

阅读量4.2k

点赞数 2

分类专栏：架构设计文章标签：架构设计

于 2021-08-23 10:18:38 首次发布

本文链接：https://blog.csdn.net/wangbuji/article/details/119762487

版权

架构设计专栏收录该内容

16 篇文章

订阅专栏

1 基本概念

软件架构是指软件系统的组织结构、部署方式和协作方式。它决定了软件系统的静态结构和动态行为。

软件架构设计的目标是实现软件系统的需求，同时满足可靠性、可扩展性、可维护性和性能等方面的要求。

软件架构的目的：解决好软件复用、质量和维护问题。

架构设计就是需求分配，将满足需求的职责分配到组件上。

软件架构为软件系统提供了一个结构（组织结构和拓扑结构）、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接）、指导构件集成的模式以及这些模式的约束组成。

组织结构：侧重位置

拓扑结构：侧重连接

软件架构本质是架构思维：遇到问题，定义问题，分析问题，解决问题

关键点：问题分解（抽象，模块划分）与集成（组合，组装，交互协作）

划分子系统的原则：

1、职责不同的单元，划分为不同的子系统

2、通用性不同的单元，划分为不同的子系统

3、需要不同开发技能的单元，划分为不同的子系统兼顾工作量，进一步切分太大的系统

逻辑拆分后的单元是模块；物理拆分后的单元是组件。

自顶向下：面向过程

自底向上：面向对象，面向服务

“分”相关的语义：分析，分类，分解，拆分，分割，切分，分层，分组，划分，分区，分布式

物理拆分后的组件之间通过接口交互

接口：

1组件与组件之间的交互（东西接口）

2 组件向表示层提供接口（南北接口，向上）

3 组件接口依赖底层的基础设施（南北接口，向下）

2 系统可行性

我们接到客户原始需求，首先要做的工作是系统可行性验证。如果可行，再继续深入需求分析，架构设计，编码，测试，交付等软件工程流程。

系统可行性验证，主要包含三步：

1 经济可行性：本项目大概投入的人力物力时间等，项目是否能赚钱。

2 技术可行性：是否可能会遇到不成熟的技术，专利授权等问题。

3 社会可行性：是否符合法律规范，社会道德底线等。

3 架构体系

可扩展架构是指系统设计和构建时考虑到未来需求增长和变化的能力，能够方便地扩展和适应新的业务要求而不影响系统的整体性能和稳定性。这种架构允许系统在需要时通过增加资源或组件而无需进行大规模的重构或升级。（面向对象开闭原则）

UML：用例图，类图，对象图，活动图，序列图，状态图，组件图，部署图

业务用例，系统用例

3.1TOGAF架构体系

TOGAF由国际标准权威组织The Open Group制定。The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表The Open Group Architecture Framework (TOGAF) 架构框架。TOGAF的基础是美国国防部的信息管理技术架构(Technical Architecture for Information Management: TAFIM)。它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可让您设计、评估、并建立组织的正确架构。TOGAF的关键是架构开发方法（Architecture Development Method: ADM）: 一个可靠的，行之有效的方法，以发展能够满足商务需求的企业架构。

业务架构、数据架构、应用架构、技术架构

1 业务架构是架构设计的基础，‌需要对业务需求（结构化）进行全面分析，‌了解业务场景，业务流程，输入输出数据流向，数据结构；根据语义相关性，功能相关性等识别出关键的业务名词和领域，‌构建业务模型。‌将业务需求分解为更小的部分，‌理解每个部分的功能和流程，‌以及它们之间的关系。‌它涉及将模糊的业务需求转化为清晰的问题域和业务流程。‌

业务架构包括业务规划、‌业务模块和业务流程，‌它定义了系统的核心功能和它们之间的关系。‌选择方案时，‌需要考虑各种约束条件，‌如时间、‌人力和硬件资源等。‌

2应用架构是在业务架构的基础上，‌进一步细化系统的实现方式。‌它关注于如何将业务需求转化为具体的应用程序或服务，‌包括定义各个组件的交互和系统的整体结构。‌如何通信，交互，接口参数返回值等

3技术架构是架构设计的最后阶段，‌它关注于如何实现应用架构中定义的功能和结构。‌这包括选择合适的技术栈、‌数据库设计、‌系统部署方式等。‌

3.2ADMEMS架构体系

ADMEMS是Architecture Design Method has been Extended to Method System的简称，是由CSAI顾问团架构设计专家组于2009年11月在第六届中国软件大会上公开发布的一个软件架构设计方法。

作为方法体系，ADMEMS通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。其中“3个阶段”是指预备架构阶段（PA阶段：把握需求特点，确定架构驱动力）、概念架构阶段（CA阶段：根据重大需求，确定概念架构）、细化架构阶段（RA阶段：细化架构设计，关注不同视图），“1个贯穿环节”是指对非功能目标的考虑。

五个视图：（前3个软件架构，后2个系统架构）

逻辑架构，关注功能需求，划分子系统，划分模块。用例图，流程图

开发架构，关注代码层次结构，程序包，sdk，第三方库，中间件等

运行架构，关注并发，同步，死锁等

物理架构，关注部署，网络结构，服务器等基础设施

数据架构，关注数据持久化，存储。分布式，复制，同步等问题

五视图法做架构设计的步骤是逻辑架构->数据架构->开发架构->运行架构->物理架构。用例图->流程图->领域建模->ER图->微服务->技术栈->并发->部署

领域建模方法：用例分析法，四色建模法，事件风暴法

用例分析法：找名词，加属性，连关系

a.概念分类列表：人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构（对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等）

b.名词分析法：识别问题域和用例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是一种标识、状态和行为）

四色模型

moment-interval（时标性原型）：时标性原型是建模的起点，它代表着我们需要记录的，某一时刻发生的事件。例如订单，行程，会议。
party, place, or thing（人-事-物原型）：一种有形的，可唯一识别的实体。可以是人、机构、地点、物品等。
role （角色原型）：角色是party, place, or thing的一种参与方式。例如，在一份雇佣关系中，某个人扮演者雇员的角色。那么这个人就是”party, place, or thing”，雇员就是”role”。
description（描述原型）：表示资料类型的资源，是一种类似目录条目的描述，用来对对象进行分类或标记，可以被其它原型反复使用。例如，一个商品的品牌、描述属性。

事件风暴

识别领域事件，按时间顺序，名词

识别领域命令，动词

寻找聚合，归类

领域边界确认

数据库设计充血模型c++和贫血模型java

自顶向下，自底向上

水平拆分，垂直拆分

宗旨：层次清晰，可维护，可复用，可扩展

模式：企业架构模式，设计模式，SOA模式，企业集成模式

SOLID设计原则

4 数据架构

1 ER图

矩形标识实体，相当与类图的类。椭圆标识实体的属性，下划线表示主键。菱形表示关系。1:N表示约束。双矩形表示弱实体，必须依赖其他实体才能存在。

3范式

1NF 第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性。下图不符合1NF

2NF 第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

3NF 若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

5 可复用

若新项目需求，可以从老项目现有的框架，模块，组件等复用，将加快新项目开发进度。

评估软件可复用性的方法主要包括模块化、抽象化、标准化以及数据设计和接口设计。‌

‌模块化‌：将软件系统划分为若干独立的模块，降低系统的复杂度，隐藏实现细节，提供接口供其他模块调用，从而促进软件系统的可复用性和可扩展性。（纵向分割）
‌抽象化‌：将软件系统划分为层次结构，实现高内聚低耦合，提高软件质量和可维护性。（横向分层）
‌标准化‌：制定统一的编程规范和标准，确保需求的完整性和一致性，促进代码重用和扩展性。
‌数据设计和接口设计‌：设计数据存储和处理的结构和算法，确保数据的完整性和一致性，同时定义软件系统与外部系统或用户交互的接口，确保系统的兼容性和易用性，实现模块之间的通信和数据交换。（接口是边界内外联络员）

通过这些方法，可以提高软件的复用性和可维护性，降低开发成本，提高软件开发效率‌。

6 技术选型

计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。

IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。

全栈开发语言：js可开发前端，移动端RN，桌面端electron，后端nodejs

python可开发桌面应用（PyQt、wxPython等），使用 kivy 开发安卓 APP，服务端（twisted等），web端（Django、Flask等），爬虫（pyspider等），硬件stm32（PyBoard等）