软件架构风格
| 类型 | 子类型 | 说明 |
| 数据流风格 | 批处理 | 每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，而且数据必须是完整的，以整体的方式传递。
|
| 管道过滤器 | 把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。
| |
| 调用/返回风格 | 主程序/子程序 | 一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。
|
| 面向对象风格 | 这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。
| |
| 层次结构风格 | 每一层为上层提供服务，并作为下层的客户。
| |
| 客户端/服务器风格 | 二层C/S ：二层C/S 体系结构由3各主要组成部分：数据库服务器、客户应用程序和网络；
三层C/S: 与3层C/S 架构相比，三层 C/S 架构增加了一个应用服务器。
B/S 架构：用浏览器代替了客户端
| |
| 独立构件风格 | 进程通信 | 构件之间通过独立的进程来实现消息传递；构件是独立的过程，连接件是消息传递。
|
| 事件驱动的系统 | 事件驱动系统风格是基于事件的隐式调用风格，构件不直接调用一个过程，而是触发或广播一个或多个事件。后续执行过程会被注册在一个或多个事件，当对应的事件被触发或广播时，系统会自动调用该事件中注册的过程，执行相应的模块功能。
| |
| 虚拟机风格 | 解释器 | 一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。
|
| 基于规则的系统 | 基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存
| |
| 仓库风格（数据共享风格） | 数据库系统 | 仓库是存储和维护数据的中心场所。在仓库风格中，有两种不同的构件：中央数据结构和一组对中央数据进行操作的独立构件。
|
| 黑板系统 | 黑板体系结构风格适用于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。
| |
| 闭环控制风格 | 适用于嵌入式系统，用于解决简单闭环控制问题
| |
| C2 风格 | 构件和连接件都有一个顶部和底部；构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连一个连接件可以和任意数目的其他构件和连接件连接。
| |
轻量级架构
SSH
- SSH ： Struts2（前端控制器） + Spring （管理各层组件）+ Hibernate（负责持久化层）
SSM
- SSM：SpringMVC（前端控制器）+ Spring（管理各层组件）+ Mybatis（负责持久化层）
| 所在分层 | SSM | |
| JSP | ||
| 控制器（Controller） | Struts2 | |
| 业务层（Service） | Java | |
| 持久层（DAO） | Hibernate | |
| 数据库层（DB） | Mysql/Oracle | |
| 组件管理层（Bean） | spring |
轻量级架构分层
轻量级架构一般包括：表现层、业务逻辑层、持久层、数据库层
- 表现层：用户界面的逻辑位于最顶层。表现层负责把用户要求的业务逻辑处理结果以可视化的有好的方式返回给用户，并提供接受用户命令的接口和表现层页面控制逻辑的代码。
- 业务逻辑层：业务逻辑层负责处理问题领域的业务规则和根据用户需求进行的业务处理以满足用户的功能需求。通常情况下，业务逻辑层处理使用的实体对象由持久层提供。
- 持久层：数据通过持久层进行持久化。所谓持久化，即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）
- 持久层的设计屏蔽了数据库平台的变化对业务逻辑层的影响
- 通过持久层的封装处理，可以在持久层实现支持多种数据库平台，而对业务逻辑层提供统一的接口
- 代码可重用性高，能够完成所有的数据库访问操作
- 数据库：
面向服务的架构设计
定义
面向服务的架构（Service-oriented achitecture,SOA)其实就是如何“基于服务”或“基于一堆服务”来实现的业务机构。面向服务是在面向对象的基础上发展起来的，但这里的服务与对象不同：
- 对象主要是面向系统的而服务是面向业务的
- 对象的粒度级别主要集中在类级而服务是粗粒度的
- 类是以函数调用为基础来交互的，而服务是以网络请求为基础来交互的
SOA 作用
SOA 对应实现企业资源共享，打破“信息孤岛”。
SOA 设计的标准要求
SOA 设计的标准要求包括：文档标准化、通信协议标准(XML Schema)、应用程序统一注册管理、保障服务质量
- 文档标准化：自我描述的XML 文档
- 通信协议标准：使用XML Schema定义服务间通信的消息
- 应用程序统一登记与集成：应用程序在登记处寻找并调用某项服务
- 服务质量（Qos）：可靠性、安全性、策略、控制、管理
实现方式
- SOA的实现方式包括：服务注册表方式、ESB 企业服务总线方式
服务注册表
| UDDI | |
| WSDL | Web 服务描述语言是对服务进行描述的语言 |
| 简单对象访问协议定义了服务请求者和服务提供者之间的消息传输规范 | |
|
ESB 企业服务总线
企业服务总线（Enterprise Service Bus，ESB）架构模式在于整合，可能是公司内部各团队的服务，也可能是公司之间的不同服务，组成一个整体，来向外提供服务。
- ESB 的作用
- 是SOA 的一种实现方式，ESB 在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合；
- 描述服务的元数据和服务注册管理
- 在服务请求者和提供者之间转递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；
- 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。
- 高级一些的能力，包括对安全的支持，服务质量保证、可管理性和负载平衡等。
SOA原则
| 无状态 | |
| 单一实例 | 避免功能冗余 |
| 服务的接口由WSDL定义，WS-Policy 用于描述服务规约、XML Schema 用于定义所交换的消息格式 | |
| 独立进行部署、版本控制、自我管理和恢复 | |
| 服务数量不应该太大 | |
| 服务私有数据对服务使用者是不可见的 | |
| 服务应该是可以重用的 | |
SOA 实施过程
SOA 实施过程包括：业务流程分析、建立服务模型、建立业务流程
- 建立服务模型
- 自顶向下分解法：从业务着手
- 业务目标分析：从业务目标分解
- 自底向上分析法:利用已有资产来实现服务
- 建立业务流程
- 建立业务对象：实体业务对象、过程业务对象、事件业务对象
- 建立服务接口
- 建立业务流程
SOA 企业集成架构
SOA 企业集成架构可划分为6大类，分别是：业务逻辑服务、控制服务、连接服务、业务创新和优化服务、开发服务、IT 服务管理
业务逻辑服务
包括用于实现业务逻辑的服务和执行业务 逻辑的能力，其中包括业务应用服务 (Business Application Service)、 业务伙伴服务 (Partner Service) 以及应用和信息资产 (Application and Information asset)。
- 业务应用服务包括：组件服务、核心服务、接口服务
- 业务伙伴服务（B2B、B2C）：社区服务、文档服务、协议服务
- 应用和信息资产：可接入服务、事件发现服务
控制服务
包括实现人 (People)、 流 程 (Process) 和信息 (Information) 集成的服务，以及执行这些集成逻辑的能力。
- 信息服务：以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务。
- 联邦服务：提供将各种类型的数据聚合的能力
- 复制服务：提供远程数据的本地访问能力
- 转换服务：用于数据源格式到目标格式的转换
- 搜索服务：提供对企业数据的查询和检索服务，既支持数据库等结构 化数据，也支持像PDF等非结构化数据
- 流程服务：以服务为中心的企业集成通过流程服务来完成业务流程集成
- 编排服务：通过预定义的流程逻辑控制流程中业务活动的执行，并帮助业务流程从错误中恢复
- 事务服务：用于保证流程执行中的事务特性 (ACID)。 对于短流 程，通常采用两阶段提交技术；对于长流程，一般采用补偿的方法。
- 人工服务：用于将人工的活动集成到流程中
- 交互服务：以服务为中心的企业集成，通过交互服务来实现用户访问集成
- 交付服务：提供运行时的交互框架，它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、 PDA和无线终端等) 上运行
- 体验服务：通过用户为中心的服务增强用户体验，其中的技术包 括个性化、协作和单点登录等
- 资源服务：提供运行时交互组件的管理，如安全配置、界面皮肤等
连接服务
通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
- 企业服务总线 (Enterprise Service Bus,ESB)
业务创新和优化服务
用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
业务创新和优化服务以业务性能管理技术为核心提供业务事件发布、收集和关键业务指标监控能力。
- 公共事件框架服务：通过一个公共事件框架提 供IT和业务事件的激发、存储和分类等
- 采集服务：通过基于策略的过滤和相关性分析检测感兴趣的服务
- 监控服务：通过事件与监控上下文间的映射，计算和管理业务流程的关键性能指标
开发服务
贯彻整个软件开发生命周期的开发平台，从需求分 析，到建模、设计、开发、测试和维护等全面的工具支持。
- 建模服务：用于构建可视化的业务流程模型
- 设计服务：根据业务模型，进一步分解为服务组件，设计服务用于设计和开发这些服务组件
- 实现服务：用于将设计和开发的服务组件部署到生产环境中
- 测试服务：支持服务组件的单元测试和系统的集成测试
IT服务管理
支持业务系统运行的各种基础设施管理能力或 服务，如安全服务、目录服务、系统管理和资源虚拟化
- 安全和目录服务： 企业范围的用户、认证和授权管理， 如单点登录 (SSO)
- 系统管理和虚拟化服务：用于管理服务器、存储、网络和其他IT 资源
微服务架构设计
定义
微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（通常是HTTP/JSON），每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署。
微服务架构特征
微服务架构特征包括：去中心化治理、基础设施自动化、具有自治性、容错性、弹性
- 去中心化治理：微服务架构倾向于去中心化的治理模式，每个服务团队可以自主选择技术栈、开发工具和部署流程。
- 基础设施自动化：微服务架构要求高度的自动化，包括持续集成、持续部署、自动化测试和监控
- 自治性：每个微服务都是独立的，拥有自己的数据库和数据模型，可以独立部署
- 容错性：微服务架构设计上考虑了服务的故障隔离，一个服务的失败不会影响到其他服务的正常运行
- 弹性：微服务可以根据需求独立扩展，只对需要更多资源的特定服务进行扩展
微服务架构的优势
微服务架构的优势有：复杂应用解耦、独立开发与部署、技术栈多样性、故障隔离、服务易于拓展
- 复杂应用解耦。微服务架构将单一模块应用分解为多个微服务，同时总体功能保持不变
- 独立开发与部署：每个微服务都可以独立开发和部署，因而可以聚集在局部，提高了开发效率和灵活性
- 技术栈多样性：不同的微服务可以采用最适合其业务需求的技术栈，无需整个系统统一技术选型
- 故障隔离：单个微服务的故障不会影响到整个系统，提高了系统的稳定性和可用性
- 易于拓展：微服务架构支持水平拓展和垂直拓展，可以根据业务需求灵活调整资源分配
微服务架构的挑战
微服务架构的挑战包括：性能问题、数据一致性、分布式复杂性、运维复杂性
- 并非所有的系统都能转成微服务。
- 性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。
- 数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。应对策略包括采用最终一致性模型、分布式事务或补偿事务等机制
- 分布式复杂性：微服务间的通信和依赖管理变得复杂。应对策略包括使用API 网关，服务发现机制和分布式事务解决方案
- 运维复杂性：系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，同时增加了系统的运维复杂度。应对策略包括引入容器技术、DevOps 和 CI/CD 流程，实现自动化运维和监控。
微服务架构分类
- 微服务架构类型可分为：聚合器微服务、代理微服务、分支微服务、链式微服务、数据共享微服务、异步消息传递微服务
与SOA 架构的对比
| 对比维度 | 微服务 | |
| 粗 | ||
| 服务通信 | 重量级，ESB | |
| 服务交付 | 慢 | |
| 应用场景 | 企业级 |
云原生架构设计
定义
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的分离，从而让云设施接管应用中原有的大量非功能特性，是业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
云原生基金会（CNCF） 关于云原生的定义是：云原生的代表技术包括容器，微服务，服务网格，不可变基础设施和声明式API。
云原生架构关键组件
- 容器技术容器是一个标准的软件单元，它将代码及其所有依赖关系打包起来，使资源调度，微服务更容易，并具备强大的可移植性。
- 微服务架构微服务架构是一种架构模式，它提倡将单体应用划分成一组多个小服务，每个服务运行在其独立的进程中，服务与服务采用轻量级的通信机制互相沟通
- DevOps高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快，更频繁的交付更稳定的软件
云原生架构原则
云原生架构原则包括：服务化原则、弹性原则、可观测原则、韧性原则、所有过程自动化原则、零信任原则、架构持续演进原则
- 服务化原则
- 拆分为微服务或小服务
- 从架构层面抽象化业务模块之间的关系
- 弹性原则
- 系统规模随着业务量自动伸缩
- 可观测原则
- 多种手段观测系统运行状况
- 韧性原则
- 软件出现异常的抵御行为
- 所有过程自动化原则
- 自动化部署、测试、监控、故障恢复等
- 零信任原则
- 身份中心化
- 架构持续演进原则
- 架构设计和实施具备演化能力
云原生的价值
- 从技术视角
- 极致的弹性扩展能力，毫秒级弹性响应
- 服务自治故障自愈能力
- 大规模可复制能力，跨区域，平台快速复制
- 从应用视角
- 容器技术解决异构资源标准化
- 变革研发运营的生产方式提升交付效率
- 提升业务应用的迭代速度，赋能业务创新
- 从产业效能方面
- 云原生极大的释放了云的红利，最大程度发挥云的优势
- 云原生成为驱动业务增长的重要引擎
云原生的技术范畴
- 云原生核心六大技术
- 容器
- 容器编排技术
- 云原生微服务架构
- 云原生中间件
- Serverless
- DevOps
- 云应用定义与开发流程
- 应用定义与镜像制作
- CI/CD 持续集成，持续交付
- 消息和Streaming （消息队列)
- 数据库
- 云应用编排与管理
- 应用编排与调度
- 服务发现与治理
- 远程调用
- API网关
- ServiceMesh （服务网格) 解决应用的非功能性需求
- 监控与可观测性
- 监控
- 日志
- Tracing （快速定位问题）
- 混沌工程 （验证应用的可用性和稳定性）
- 云原生底层技术
- 容器运行池
- 云原生存储技术
- 云原生网络技术
- 云原生工具集
- 流程自动化与配置管理
- 容器镜像仓库
- 云原生安全技术
- 云端密码管理
- Serverless (无服务化，帮助用户管理基础设施)
- FaaS （基于函数）
- BaaS （基于后端）
- Serverless 计算
典型的云原生架构反模式
1. 庞大的单体应用
2.单体应用“硬拆”为微服务
3.缺乏自动化能力的微服务
Serverless 无服务器技术
- serverless技术特征：全托管的计算服务、通用性、自动弹性伸缩、按量计费
- 技术关注点：计算资源弹性调度、负载均衡和流控、安全性
- 计算资源弹性调度
- 容错：多个实例部署在不同节点
- 资源利用率：计算密集/IO 密集型由相同节点计算、动态迁移不同节点”碎片化“实例
- 性能：复用实例与函数节点、利用缓存
- 数据驱动：使用离线分析验证在线调动算法结果
- 负载均衡和流控
- 流量隔离控制
- 资源调度服务
- 安全性
- 关注权限管理、网络安全、数据安全、运行时安全
- 使用轻量安全容器
- 计算资源弹性调度
服务网格
服务网格（service Mesh）是分布式应用在微服务架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。
层次式架构设计
定义
层次式体系结构设计是一种常见的架构设计方法，它将系统组成为一个层次结构，每一层为上层服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。层次式体系结构的每一层最多影响两层，同时只要给相邻层提供相同的接口，也允许每层用不同的方法实现，这种方式也为软件重用提供了强大的支持。
大部分的应用会分成表现层、中间层（业务层）、访问层（持久层）、数据层
特征
关注点分离：每层中的组件只负责本层的逻辑，组件的划分也很容易明确组件的角色和职责，比较容易开发、测试、管理和维护。
优缺点
- 优点：
- 开发人员可以只关注整个结构中的其中某一层
- 可以很容易的用新的实现来代替原有层次的实现
- 可以降低层与层之间的依赖
- 有利于标准化
- 利于各层逻辑的复用
- 扩展性强。不同层负责不同的层面
- 安全性高。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了
- 项目结构更清楚，分工更明确，有利于后期的维护和升级
- 缺点：
- 严格的分层可能导致性能问题，具体取决于层数
- 建立清晰的分层架构并不是很容易
注意事项
- 容易成为污水池反模式：请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。
- 分层架构可能会让应用变得庞大
表现层架构设计
MVC （Model-VIew-Controller）模式
- MVC 模式组成：模型、视图、控制器
- MVC 是一种软件设计模式。MVC 把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图 3个核心模块。
- 控制器（Controller）：接受用户的输入，并调用模型和视图去完成用户的需求
- 模型（Model）：应用程序的主体部分，表示业务数据和业务逻辑
- 视图（View）：用户看到并与之交流的界面
- 优点
- 允许多种用户界面的拓展
- 易于维护
- 易于构建功能强大的用户界面
- 增加应用的可拓展性、强壮性、灵活性
MVP （Model-View-Presenter）模式
- MVP 模式组成：模型、视图、呈现器
- 在MVP 模式中，Model 提供数据，VIew 负责显示，Controller/Presenter 负责逻辑的处理。MVP 不仅避免了View 和 Model 之间的耦合，还进一步降低了 Presenter 对 View 的依赖。
- 优点
- 模型与视图完全分离，可以修改视图而不影响模型
- 所有的交互都发生在一个地方-Presenter 内部，因此可以更高效地使用模型
- 可以将一个Presenter 用于多个视图，而不需要改变Presenter 的逻辑。因为视图的变化总是比模型的变化频繁。
- 如果把逻辑放在Presenter 中，就可以脱离用户接口来测试这些逻辑（单元测试）
MVVM （Model-View-View Model) 模式
- MVVM 模式组成：模型、视图、视图模型
- MVVM 和MVC、MVP 类似，主要目的是为了实现视图和模型的分离。不同的是MVVM 中，View 与Model 的交互通过 ViewModel 来实现，也就是 View 和Model 不能直接通信，两者的通信只能通过VIewModel 来实现。ViewModel 是MVVM 的核心，通过DataBinding 实现View 与Model 之间的双向绑定，其内容包括数据状态处理、数据绑定及数据转换。
中间层架构设计
业务逻辑层组件分为接口和实现两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个数据访问对象（Data Access Object，DAO）组件作为基础，从而实现对外提供系统的业务逻辑服务。
1. 业务逻辑层工作流设计
工作流管理联盟（WFMC）将工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。
2. 业务逻辑层实体设计
逻辑层实体提供对业务数据及相关功能的状态编程访问。业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分I/O参数传递。业务逻辑层实体是可序列化的，以保持它们的当前状态。
3. 业务逻辑层框架
业务逻辑层框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。在业务容器中，业务逻辑是按照 Domain Model-Service-Control 思想来实现的。其中：
- Domain Model 是仅仅包含业务相关的属性的领域层业务对象。
- Service 是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。
- Control 服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。
数据访问层设计
数据访问模式
数据访问模式包括：在线访问、DAO、DTO、离线数据模式、对象/关系映射（ORM）
- 在线访问：最常用的方式。访问占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。
- Data Access Object ：DAO 是标准J2EE 设计模式，这种方式将底层数据访问操作与高层业务逻辑分离开。一个典型的DAO 实现通常会有一个DAO 工厂类、一个DAO 接口、一个实现了DAO 接口的具体类、数据传输对象。
- Data Transfer Object：DTO 属于 EJB 设计模式之一。DTO 是一组对象或容器，需要跨越不同的进程或是网络的边界来传输数据。
- 离线数据模式：离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中，成为应用的中心。这种方式对数据的各种操作独立于各种与后台数据源之间的连接或是事务。
- 对象/关系映射（ORM）：这种方式利用工具或平台能够帮助将应用程序中的数据转换成关系型数据库中的记录：或是将关系数据库中的记录转换成应用程序中代码便于操作的对象。
工厂模式在数据访问层的应用
工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。这里可能会处理对多种数据库的操作，因此，需要首先定义一个操纵数据库的接口，然后根据数据库的不同，由类工厂决定实例化哪个类。
事务处理设计
事务必须服从ISO/IEC 所制定的ACID 原则，ACID 原则及：原子性、一致性、隔离性、持久性
- 原子性：表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。
- 一致性：表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。
- 隔离性；表示在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。
- 持久性：表示已提交的数据在事务执行失败时，数据的状态都应该正确。
物联网层次式架构设计
典型的物联网层次式架构分为三层，分别是：感知层、网络层、应用层
- 感知层：用于识别物体，采集信息。感知层包括二维码标签和识读器、RFID 标签和读写器、摄像头、GPS 、传感器、M2M 终端、传感器网管等，主要功能是识别对象、采集信息，与人体结构中皮肤和五官的作用类似。
- 网络层：用于传递信息和处理信息。网络层包括通信网与互联网的融合网络、网络管理中心、信息中心和智能处理中心等。网络层将感知层获取的信息进行传递和处理，类似于人体结构中的神经中枢和大脑。
- 应用层：实现广泛智能化。应用层是物联网与行业专业技术的深度融合，结合行业需求实现行业智能化，这类似于人们的社会分工。
通信系统架构设计
局域网网络架构
- 局域网是单一机构专用计算机的网络。通常由计算机、交换机、路由器等设备组成。
- 特点是覆盖地理范围小，数据传输速率高，低误码率，可靠性高，支持多种传输介质，支持实时应用。
- 局域网可以有有线、无线两种类型。
- 局域网的拓扑结构包括：星型、总线型、环形、树型
- 局域网架构风格包括；单核心架构、双核心架构、环形架构、层次型架构
广域网网络架构
- 广域网是将分布于相比局域网网络更广区域的计算机设备连接起来的网络。
- 广域网架构类型包括：单核心广域网、双核心广域网、环形广域网、半/全冗余架构、对等子域广域网架构、层次子域广域网架构
存储网络架构
- 存储网络设计磁盘存储访问方式包括：直连式存储（DAS）、网络连接的存储（NAS）、存储区域网络（SAN）
- 直连式存储（DAS）：存储设备通过IDE/ATA/SCSI 接口或光纤通道直接连接到单台计算机，计算机通过I/O访问存储设备，存储设备可以是硬盘驱动器、RAID 阵列、CD、DVD、磁带驱动器。
- 网络连接的存储（NAS）：存储设备通过标准的网络拓补结构连接到计算机群组，计算机通过IP 局域网或广域网TPC 或UDP 协议，通过RPC 接口访问NAS 存储设备
- 存储区域网络（SAN）：一种采用网状通道技术专门为存储建立的独立于TCP/IP 网络之外的专用网络，通过网状通道交换机连接存储阵列和服务器。
| NAS | |||
| 架构类别 | 单机存储架构 | 网络存储架构 | |
| I/O 总线 | 网络 | ||
| 单机存储 | 共享存储 | ||
| 总线 | 以太网/光纤通道 | ||
| 易用易管理设备成本低 |
软件定义网络
软件定义网络是通过对网络设备的控制面与数据面进行分离，控制面集中化管理，同时对外提供开放的可编程接口，为网络应用创新提供极佳的能力开放平台；而数据面则通用化、轻量化、高效转发，以提升网络的整体运行效能
- 数据平面由网络转发设备组成，网络转发设备之间通过由不同规则形成的SDN 数据通路连接起来；
- 控制面包含了逻辑上为中心的SDN 控制器，它掌握着网络全局信息，负责转发设备的各种转发规则的下发；应用平面包含各种基于SDN 的网络应用，应用无需关心网络底层细节就可以编程、部署新应用。
- SDN 中的接口具有开放性，以控制器为逻辑中心，南向接口（采用 OpenFlow 协议）负责与数据平面进行通信，北向接口负责与应用平面进行通信，东西向接口负责多控制器之间的通信
网络构建和设计方法
网络需求与设计
- 网络需求分析主要从业务需求、用户需求、应用需求、计算机平台需求和网络需求来进行分析
- 层次化网络模型设计。层次化设计优点是能降低成本，充分利用模块化设备/部件，网络变化或演化容易。层次化网络设计一般采用三层模型设计思路：接入层、汇聚层、核心层。
- 层次化设计原则
- 控制网络层次
- 从接入层开始，向上分析规划
- 尽量采用模块化设计
- 严格控制网络结构
- 严格控制层次化结构
网络安全控制技术
网络安全控制技术主要包括：防火墙、虚拟专用网络技术、访问控制技术、网络安全隔离、网络安全协议、网络安全审计
- 防火墙
- 防火墙是网络间的安全屏障，可以保护本地网络资源。防火墙可以允许/拒绝/重定向数据流以及审计进出网络的访问或服务。防火墙的体系有：
- 硬件防火墙
- 软件防火墙
- 嵌入式防火墙
- 防火墙的种类包括
- 代理服务
- 应用层网关
- 包过滤
- 防火墙是网络间的安全屏障，可以保护本地网络资源。防火墙可以允许/拒绝/重定向数据流以及审计进出网络的访问或服务。防火墙的体系有：
- 虚拟专用网络技术（VPN）
- 该技术利用公共网络建立私有专用网络，具有成本低，接入方便，可拓展性强，管理和控制方便等优点
- 访问控制技术
- 自主访问控制DAC
- 强制访问控制MAC
- 基于角色的访问控制 RBAC
- 基于任务的访问控制 TBAC
- 基于对象的访问控制 OBAC4.
- 网络安全隔离
- 网络安全隔离。将攻击隔离在网络外，保证网络内信息不外泄。
- 子网隔离
- 物理隔离
- VLAN 隔离
- 逻辑隔离
- 网络安全协议
- SSL 协议是介于应用层和TCP 层之间的安全通信协议，提供保密性通信、点对点身份认证、可靠性通信三种安全通信服务。其继任者为传输层安全协议 TLS
- PGP 是一种加密软件，应用了多种密码技术包括RSA、IDEA、完整性检测和数字签名算法，实现了一个比较完善的密码系统。广泛用于电子邮件安全
- IPSec 是工作在网络层的安全协议，主要优点是它的透明性，安全服务的提供不需要更改应用程序
- SET 安全电子交易协议，是基于信用卡在线支付的电子商务安全协议；主要用于解决用户、商家和银行之间通过信用卡支付的交易问题，保证支付信息的机密，支付过程的完整、商户和持卡人身份合法性及可操作性
- HTTPS 协议：是以安全为目标的HTTP 通道，在HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础上加入SSL，HTTPS 的安全基础就是SSL，因此加密的详细内容就需要SSL
- 网络安全审计
- 用来测试，评估和分析网络脆弱性。
信息系统架构设计
定义
- 信息系统架构（ISA）：是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的活动。
- 软件或计算机系统的信息系统架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性以及它们之间的关系组成。
- 信息系统架构为软件系统提供了一个结构、行为、和属性的高级抽象，由构成系统元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。
- 信息系统架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间，构件与环境之间的关系，以及指导其设计和演化的原则上。
分类
信息系统物理结构包括：单体应用、分布式结构
信息系统逻辑结构包括:
- 横向综合：将同一管理层次的各个业务职能综合到一起
- 纵向综合：将同一业务的各个管理层次智能综合到一起
- 横纵综合：将各个业务的各个管理层次统一综合到一起，主要从信息模型和处理模型两方面着手，建立公用的数据库和统一的信息处理系统
信息系统常用架构
- 单机应用模式
- 分层架构
- 典型的两层客户机/服务器架构
- 三层C/S 与B/S 架构
- 典型的多层客户机/服务器架构
- MVC 架构的分层体系 （Mode-VIew -Contorller）
- 面向服务架构（SOA）
- 企业服务总线（ESB）/企业数据交换总线架构（EDB）
企业信息系统的总体框架
企业信息系统包括：战略系统、业务系统、应用系统、信息基础设施
- 战略系统
- 两层含义
- 信息系统对企业高层管理者的决策支持能力
- 企业战略规划对信息系统建设的影响和要求
- 两层含义
-
- 两部分组成
- 高层决策支持系统：以计算机为基础
- 企业战略规划体系：
- 长期规划：调整产品结构；
- 短期规划：新产品类型。
- 两部分组成
- 业务系统
- 定义：企业中完成一定业务功能的各部分（物质、能量、信息和人）组成的系统。
- 作用：建模、优化重组业务过程进行企业应用系统的开发和信息基础设施的建设。
- 应用系统
- 定义：应用软件
- 组成：内部功能实现，外部界面
- 企业信息基础设施
- 定义：指根据企业当前业务和可预见的发展趋势，及对信息采集、处理、存储和流通的要求，构筑由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。
- 组成
- 技术基础设施：计算机、网络、系统软件、支持性软件、数据交换协议
- 信息资源设施：数据与信息本身、数据交换的形式与标准、信息处理方法
- 管理基础设施：组织结构、人员的分工 、管理方法与规章制度
信息系统架构设计方法
TOGAF
- TOGAF ：开放式企业架构框架标准，为标准、方法论和企业架构专业人员之间的沟通提供一致性保障。
- 核心思想：模块化架构、为架构产品提供内容框架、为大型组织开发提供拓展指南、适用于不同架构风格
- 九大组件：
- 企业连续体和工具
- 架构活动的输出和存储
- 企业连续体和工具
-
- 架构开发方法
- ADM 方法
- 核心
- 架构开发方法
-
- TOGAF 参考模型
- 技术参考模型
- 继承信息基础设施参考模型
- TOGAF 参考模型
-
- ADM 指南和技术
- 用于ADM 的指南和技术
- ADM 指南和技术
-
- 架构能力框架
- 组织、流程、技能、角色和职责
- 架构能力框架
-
- 架构内容框架
- 架构工件的结构化元模型
- 可重用架构构建块
- 架构可交付成果
- 架构内容框架
ADM 架构开发方法
ADM 架构开发方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。ADM 形成3个级别的迭代周期。
- 基于ADM 整体的迭代：一个阶段结束直接进入随后的下一个阶段。
- 多个开发阶段间的迭代：一个阶段结束重新回到上一个阶段。
- 在一个阶段内部的迭代：一个阶段内部多个活动可以迭代
| ADM 阶段 | |
| 准备阶段 | 为实施成功的企业架构项目做好准备，包括定义组织机构、特定的架构框架、架构原则和工具 |
| 完成需求的识别、保管和交付，相关联的ADM 阶段则按优先级顺序对需求进行处理。TOGAF 项目的每个阶段，都是建立在业务需求之上并且需要对需求进行确认。 | |
| 设置TOGAF 项目的范围、约束和期望。创建架构愿景，包括： 确认业务上下文环境、 取得上级批准 | |
| 阶段C：信息系统架构（应用& 数据） | 从业务、信息系统和技术三个层面进行架构开发，在每一个层面分别完成以下活动： 开发目标架构描述 |
| 阶段E：机会和解决方案 | 进行初步实施规划，并确认在前面阶段中确定的各种构建块的交互物形式； 对项目分组并纳入过渡架构 评估优先顺序 |
| 阶段F：迁移规划 | 对阶段E 确定的项目进行绩效分析和风险评估，制定一个详细的实施和迁移计划 |
| 定义实施项目的架构限制； 发布实施项目的架构合同 | |
| 阶段H 架构变更管理 |
信息化内容与模式
- 信息化包括4个方面的内容：信息网络体系、信息产业基础、社会运行环境、效用积累过程
- 信息化具有6个要素：开发利用信息资源、建设国家信息网络、推进信息技术应用、发展信息技术和产业、培育信息化人才、制订和完善信息化政策
- 信息化平台：知识管理平台、日常办公平台、信息集成平台、信息发布平台、协同工作平台、公文流转平台、企业通信平台
- 信息化具有9个特征：易用性、健壮性、平台化、灵活性、拓展性、安全性、门户化、整合性
- 、移动性
信息化架构模式
- 数据导向架构：关注数据模型和数据质量
- 数据对象
- 主数据管理
- 流程导向架构：关注端到端流程整合及对流程变化的适应度
- 端到端流程整合服务
- SOA
信息化建设生命周期
信息化建设的生命周期包括：系统规划、系统分析、系统设计、系统实施、系统运行与维护
- 系统规划
- 初步调查
- 新系统的需求与约束
- 可研报告
- 系统设计任务书
- 系统分析
- 详细调查
- 新系统的逻辑模型
- 系统说明书
- 系统设计
- 新系统的物理模型
- 概要设计
- 详细设计
- 系统设计说明书
- 系统实施
- 购置设备
- 代码编写
- 人员培训
- 数据转换
- 系统调试
- 系统运行与维护
- 维护
- 评价
信息系统工程总体规划的方法论
- 关键成功因素法（CSF）
- 识别关键成功因素
- 确定系统开发的优先次序
- 战略目标集转化法（SST）
- 使命、目标、战略
- 分层
- 结构化
- 企业系统规划法（BSP）
- 自上而下识别目标、过程、数据
- 自下而上设计系统
大数据架构设计
架构特征
- 鲁棒性和容错性
- 低延迟读取和更新能力
- 横向扩容
- 通用性
- 延展性
- 即席查询能力
- 最少维护能力
- 可调试性
Lambda 架构
Lambda 架构是由 Nathan Marz 提出的一种大数据处理架构，它旨在提供一种可拓展、容错性强且能够处理大量数据的系统。Lambda 架构结合了批处理和流处理两种数据处理方式，以实现对大数据的实时和批量分析。
- 设计目的在于提供一个能满足大数据系统关键特性的架构
- 用于同时处理离线和实时数据的分布式系统
- 融合不可变性，读写分离和复杂性隔离等原则
- 整合离线计算与实时计算
- 高容错、低延迟、可拓展、强鲁棒性、持续更新
- 可集成Hadoop 、Kafka、Spark、Storm 等各类大数据组件
- 应用场景
- 机器学习
- 处理的各类数据为机器学习应用算法、检测模式提供数据
- 物联网
- 物联网感知层提供数据，作为架构输入
- 流处理
- 提供最新数据的低延迟实时视图
- 机器学习
架构分层
lambda 架构主要由三个层次组成：批处理层、加速层、服务层
- 批处理层（batch Layer）
- 存储数据集，预计算查询函数，构件批视图
- 离线处理，结果精确、全量，处理时延高
- 加速层（Speed Layer）
- 处理最近的增量数据流，不断更新实时视图
- 实时处理，结果可能不准，非全量，处理时延低
- 服务层（Serving Layer）
- 合并批处理和实时视图中的结果数据集到最终数据集
- 各层技术
- Hadoop（HDFS）用于存储主数据集；
- Spark（Storm）可构成速度层
- Hbase（或Cassandra）作为服务层，由Hive创建可查询的视图
架构优缺点
- 优点：容错性好、查询灵活度高、易伸缩、易拓展
- 容错性好：可以修复算法或从头开始重新计算视图进行容错
- 查询灵活度高：批处理允许针对任何数据进行临时查询
- 易伸缩：所有层都可以通过横向扩容轻松完成水平拓展
- 易扩展：添加视图容易，只需给主数据集添加几个新函数
- 缺点
- 全场景覆盖带来的编码开销
- 针对具体场景重新离线训练一遍益处不大
- 重新部署和迁移成本高
Kappa 架构
架构分层
Kappa架构分为实时层、服务层
- 实时层
- 处理输入数据，生成实时视图
- 服务层
- 使用实时视图中的结果数据集响应用户请求
架构优缺点
- 优点
- 离线和实时处理代码统一
- 方便维护
- 缺点
- 消息中间件有性能瓶颈
- 数据关联时处理开销大
- 抛弃了离线计算的可靠性
架构对比
| 对比内容 | Kappa 架构 | |||
| 维护两套系统（引擎），复杂度高，成本高 | ||||
| 计算开销 | 周期性批处理计算，持续实时计算，计算开销大 | |||
| 实时性 | 满足实时性 | |||
| 历史数据处理能力 | 批量全量处理，吞吐量大 批视图与实时视图存在冲突可能 | |||
| 设计考虑 | Kappa 架构 | |||
| 依赖Hadoop、Spark、Storm 技术 | ||||
| 复杂度 | 修改两套代码复杂度高 | |||
| 开发维护成本 | 成本预算充足 | |||
| 历史数据处理能力 | 频繁使用海量历史数据 | |||
安全架构设计
安全模型
- 状态机模型
- Bell-LaPadula 模型
- Biba 模型
- Clark-Wilson 模型
- Chinese Wall 模型
系统安全体系结构规划框架
WPDRRC 信息安全体系架构模型
- 信息安全模型 WPDRRC 包括6个环节：预警、保护、检测、响应、恢复、反击
- 三个要素：人员、策略、技术
-
信息安全体系架构设计
系统安全保障体系由安全服务、协议层次和系统单元三个层面组成，每个层面都涵盖了安全管理的内容。
网络安全体系架构设计
- 信息安全体系架构，具体可从以下5个方面展开安全体系的架构设计工作包括：物理安全、系统安全、网络安全、应用安全、安全管理
- 物理安全（前提）：包括环境安全、设备安全、媒体安全
- 系统安全（基础）：包括网络结构安全、操作系统安全、应用系统安全
- 网络安全（关键）：包括访问控制、通信保密、入侵检测、网络安全扫描、防病毒
- 应用安全：包括资源共享、信息存储
- 安全管理：包括健全的体制，管理平台，人员安全防范意识
OSI 安全体系架构：
OSI 定义了分层多点的安全技术体系架构，又叫深度防御安全架构，它通过以下三种方式将防御能力分布至整个信息系统中：多点技术防御、分层防御技术、支撑性基础设施。
- 多点技术防御：通过网络和基础设施，边界防御，计算环境等方式进行防御。
- 分层防御技术:外部和内部边界使用嵌套防火墙，配合入侵检测进行防御
- 支撑性基础设施：使用公钥基础设施以及检测和响应基础设施进行防御
认证框架
认证又叫鉴别，其目的是防止其他实体占用和独立操作被鉴别实体的身份。
鉴别的方式有：已知的（口令）、拥有的（IC卡，令牌等）、不可变特征（生物特征）、授信三方鉴别、环境（主机地址）
- 鉴别的服务阶段分为：
- 安装
- 修改鉴权信息
- 分发
- 获取
- 传送
- 验证
- 停活
- 重新激活
- 取消安装
访问控制框架
当发起者请求对目标进行特殊访问时，访问控制管理设备AEF 就通知访问决策设备 ADF ，ADF 可以根据上下文信息（包括发起者的位置、访问时间或使用中的特殊通信路径）以及可能还有以前判决中保留下来的访问控制决策信息ADI 信息做出允许或禁止发起者试图对目标进行访问的判决。
机密性框架
机密性服务目的是确保信息仅仅是对被授权者可用
机密性机制：
- 通过禁止访问提供机密性
- 通过加密提供机密性
完整性框架
- 完整性服务的目的是组织威胁或探测威胁，保护数据及其相关属性的完整性。
- 完整性服务分类有：未授权的数据创建、数据创建、数据删除、数据重放
- 完整性机制类型分为组织媒体访问与探测非授权修改两种
抗抵赖框架
- 抗抵赖服务的目的是提供特定事件或行为的证据。
- 抗抵赖服务分为
- 证据生成
- 证据传输
- 存储及回复
- 证据验证
- 解决纠纷
系统架构的脆弱性分析
MVC 架构
- 复杂性脆弱性：如一个简单的界面，如果严格遵循MVC 方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率
- 视图与控制器连接紧密脆弱性：视图与控制器是相互分离但确是联系紧密的部件，如果没有控制器的存在，视图应用是有限的。反之亦然，这就妨碍了它们的独立重用
- 视图对模型低效率访问脆弱性：依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。
分层架构
- 层间脆弱性：某个底层发生错误，整个程序将会无法正常运行
- 层间通信脆弱性：在面向对象方法中，将会存在大量对象成员方法的调用（消息交互），这种层层传递，势必造成性能的下降。
CS 架构
- 客户端脆弱性
- 网络开放性脆弱性
- 网络协议脆弱性
BS 架构
- 如果使用HTTP 协议，会更容易被病毒入侵
事件驱动架构
- 组件脆弱性
- 组件间交换数据的脆弱性
- 组件间逻辑关系的脆弱性
- 事件驱动容易死循环
- 高并发脆弱性
- 固定流程脆弱性
微内核架构
- 整体优化脆弱性：微内核系统的核心态只实现了最基本的系统操作，因此内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。
- 进程通信开销脆弱性：微内核系统的进程间通信开销也较单一内核系统要大得多
- 通信损失脆弱性：微内核把系统分为各个小的功能块，从而降低了设计难度，系统的维护与修改也容易，但带来的问题是通信效率的损失。
微服务架构
- 分布式结构复杂性脆弱性：开发人员需要处理分布式系统的复杂结构
- 服务间通信脆弱性：开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部失效问题。
- 服务管理复杂性脆弱性。在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。
