架构设计图参考

1. 什么是架构？

架构是一种整体与局部关系的抽象描述，是描述系统要素之间的关系。

2. 架构公式

架构 = 要素 + 连接 + 解决问题

• 要素：具有特定功能地工具对象

• 连接：通过对象地功能、特性、规则关联一起

• 问题：即需求、矛盾

3.架构类型

3.1 项目系统架构分类6个：

3.1.1 业务架构 :

定义业务战略、治理、组织和关键业务流程。

3.1.2 数据架构 :

描述组织的逻辑与物理数据资产及数据管理资源的结构。

3.1.3 应用架构 :

应用之间结构和交互的描述。

3.1.4 技术架构:

描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力，包括 IT 基础设施、中间件、网络、通信、处理和标准等。

3.1.5 安全架构：

设计是指遵循安全设计的基本原则，在充分理解现有的业务和应用场景，并对面临的攻击威胁充分了解的前提下，正确的部署、使用安全控制技术以满足保护信息资产的安全需求。

3.1.6 部署架构：

通过建立不同应用和业务之间的沟通机制，可以把系统中各项独立的部分整合为一个整体，以此来提升企业业务效率，降低业务成本，提高数据精确性及流程的合理性。也正因此，成熟、完美的系统架构部署能力是衡量系统运作能力的重要指标。

3.2 经典软件架构分类5个：

3.2.1 分层架构：

将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见：表现层、业务层、持久层、数据库。

表现层（presentation）：用户界面，负责视觉和用户互动
业务层（business）：实现业务逻辑
持久层（persistence）：提供数据，SQL 语句就放在这一层
数据库（database） ：保存数据

3.2.2 事件驱动架构：

通过事件进行通信的软件架构。

事件队列（event queue）：接收事件的入口
分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
事件通道（event channel）：分发器与处理器之间的联系渠道
事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

3.2.3 微核架构：

又称为"插件架构"，指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。内核通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

3.2.4 微服务架构：

是服务导向架构的升级。每一个服务就是一个独立的部署单元。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

微服务架构分成三种实现模式：

• RESTful API 模式：服务通过 API 提供，云服务就属于这一类
• RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
• 集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成

3.2.5 云架构：

主要解决扩展性和并发的问题，是最容易扩展的架构。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）：

• 处理单元：实现业务逻辑
• 虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
  

虚拟中间件又包含四个组件：

• 消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
• 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
• 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
• 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

3.3 C4模型软件架构4个

架构组成：系统、容器、组件和代码。

按场景分类4个：

3.3.1 环境图：

环境图是绘制一个软件系统的开始。在一个方框的中间画出系统，系统周围画出一些与之交互的使用者和其他功能系统。这里的细节并不重要，因为这是您的缩小视图，显示了系统概况。重点应该放在人员（角色，角色，角色等）和软件系统上，而不是技术，协议和其他低级细节上。您可以向非技术人员展示这种图表。

• 范围：单个软件系统。

• 主要元素：范围内的软件系统。

• 支持元素：在范围内直接连接到软件系统的人员（例如，用户，参与者，角色或角色）和软件系统（外部依存关系）。通常，这些其他软件系统不在您自己的软件系统的范围或边界之内，因此您不承担任何责任或所有权。

• 目标受众：软件开发团队内部和外部的所有人，包括技术人员和非技术人员。
  

3.3.2 容器图：

了解了系统如何适应整个IT环境后，下一步真正有用的步骤就是使用“容器图”放大系统边界。“容器”类似于服务器端Web应用程序，单页应用程序，桌面应用程序，移动应用程序，数据库架构，文件系统等。本质上，容器是可单独运行/可部署的单元（例如，单独的进程空间） ）来执行代码或存储数据。

容器图显示了软件体系结构的高层结构以及如何在其中分配职责。它还显示了主要的技术选择以及容器之间的通信方式。这是一个简单的，专注于技术的高级图表，对软件开发人员和支持/运营人员均非常有用。

• 范围：单个软件系统。

• 主要元素：范围内软件系统内的容器。

• 支撑要素：人员和软件系统直接连接到容器。

• 目标受众：软件开发团队内部和外部的技术人员；包括软件架构师，开发人员和运营/支持人员。

注意：此图未说明部署方案，集群，复制，故障转移等。

3.3.3 组件图

接下来，您可以放大并分解每个容器，以识别主要的结构构件及其相互作用。

组件图显示了容器如何由多个“组件”组成，每个组件是什么，它们的职责以及技术/实现细节。

• 范围：单个容器。

• 主要元素：范围内的容器中的组件。

• 支持元素：容器（在范围内的软件系统内）以及直接连接到组件的人员和软件系统。

• 目标受众：软件架构师和开发人员。
  

3.3.4 代码图：

最后，您可以放大每个组件以展示如何将其实现为代码。使用UML类图，实体关系图或类似的图。

这是可选的详细级别，通常可以从IDE等工具中按需获得。理想情况下，此图将使用工具（例如，IDE或UML建模工具）自动生成，并且您应该考虑仅显示那些允许您讲述自己想要讲述的故事的属性和方法。除了最重要或最复杂的组件外，不建议使用此级别的详细信息。

• 范围：单个组件。

• 主要元素：范围内组件内的代码元素（例如，类，接口，对象，函数，数据库表等）。

• 目标受众：软件架构师和开发人员。
  

3.4 “4+1” 视图模型软件架构4类

• 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
• 过程视图（Process View），捕捉设计的并发和同步特征。
• 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。
  

4. 架构图作用

解决沟通障碍
达成共识
减少歧义
快速理解