导图社区 系统集成项目管理工程师第3版 第4章 信息系统架构
- 111
- 2
- 0
- 举报
系统集成项目管理工程师第3版 第4章 信息系统架构
系统集成项目管理工程师第3版/第4章 信息系统架构，信息系统架构是指体现信息系统相关的组件、关系以及系统的设计和演化原则的基本概念或特性。
编辑于2024-03-17 11:39:10- 系统集成项目管理工程师第3版
- 信息系统架构
- 系统集成项目管理工程师第3版 第18章 职业道德规范
系统集成项目管理工程师第3版/第18章 职业道德规范，道德是由一定的社会经济关系所决定的特殊意识形态。社会存在决定社会意识，而社会经济关系是最根本的社会存在。
- 系统集成项目管理工程师第3版 第17章 法律法规与标准规范
系统集成项目管理工程师第3版/第17章 法律法规与标准规范，法是由国家制定、认可并保证实施，以权利义务为主要内容，由国家强制力保证实施的社会行为规范及其相应的规范性文件的总称。
- 系统集成项目管理工程师第3版 第16章 监理基础知识
系统集成项目管理工程师第3版/第16章 监理基础知识，信息系统监理通常直接面对业主单位和承建单位，在双方之间形成一种系统的工作关系，在保障工程质量、进度、投资控制和合同管理、信息管理，协调双方关系中处于重要的、不可替代的地位。
系统集成项目管理工程师第3版 第4章 信息系统架构
社区模板帮助中心，点此进入>>
- 系统集成项目管理工程师第3版 第18章 职业道德规范
系统集成项目管理工程师第3版/第18章 职业道德规范，道德是由一定的社会经济关系所决定的特殊意识形态。社会存在决定社会意识，而社会经济关系是最根本的社会存在。
- 系统集成项目管理工程师第3版 第17章 法律法规与标准规范
系统集成项目管理工程师第3版/第17章 法律法规与标准规范，法是由国家制定、认可并保证实施，以权利义务为主要内容，由国家强制力保证实施的社会行为规范及其相应的规范性文件的总称。
- 系统集成项目管理工程师第3版 第16章 监理基础知识
系统集成项目管理工程师第3版/第16章 监理基础知识，信息系统监理通常直接面对业主单位和承建单位，在双方之间形成一种系统的工作关系，在保障工程质量、进度、投资控制和合同管理、信息管理，协调双方关系中处于重要的、不可替代的地位。
- 相似推荐
- 大纲
信息系统架构
一、 架构基础
I. 概要
电气和电子工程师协会(Institute of Electrical and Electronics Engineers,IEEE)认为系统的架构是构成一个系统的基础组织结构，包括系统的组件构成、组件间的相互关系、系统和其所在环境的关系，以及指导架构设计和演进的相关准则。如果该系统范畴包括了整个组织的系统，架构就定义了组织级信息系统架构的方向、结构、关系、原则和标准等。
信息系统架构是指体现信息系统相关的组件、关系以及系统的设计和演化原则的基本概念或特性。
信息系统集成项目涉及的架构通常有系统架构、数据架构、技术架构、应用架构、网络架构、安全架构等类型，组织级的信息系统集成架构向上承载了组织的发展战略和业务架构，向下指导着信息系统具体方案的实现，发挥着承上启下的中坚作用。
该层级架构需要根据组织的战略目标、运营模式和信息化程度来确定，并且紧密支持业务价值的实现。
架构的本质是决策，是在权衡方向、结构、关系以及原则各方面因素后进行的决策。信息系统项目可基于项目建设的指导思想、设计原则和建设目标等展开各类架构的设计。
II. 指导思想
指导思想是开展某项工作所必须遵循的总体原则、要求和方针等，站在宏观的角度、总体的高度指示引导工作的进行，通过指导思想的贯彻实施，推动项目多元参与者能保持集成关键价值的一致性理解，从而减少不必要的矛盾与冲突。
举例：某城市社会保险智慧治理中心建设的指导思想，定义为：以***新时代中国特色社会主义思想为指导，全面贯彻党的二十大精神，坚持以人民为中心的发展思想，坚持一切为了人民、一切依靠人民，始终把人民放在心中最高位置、把人民对美好生活的向往作为奋斗目标，适应新时代社会保险事业改革发展需要，聚焦社会保险工作的重要领域和关键环节，统筹规划、创新驱动、数据赋能，全面开展某城市智慧人社治理中心建设，推动新时期智慧社会保险体系、创新体系和能力建设，不断提升社会保险治理能力和服务水平，为新时代社会保险事业高质量发展提供强有力的信息化支撑，推动实现某城市治理体系和治理能力的现代化。
III. 设计原则
设计原则为架构和规划决策、政策、程序和标准制定，以及矛盾局势的解决提供了坚实的基础。
原则不需要多，要面向未来，并得到相关方高级管理人员的认可、拥护和坚持。太多的原则会降低架构的灵活性，许多组织倾向于只界定更高级别原则，并通常将数目限制在4～10项。
某城市社会保险智慧治理中心建设的设计原则包括：
1. 坚持以人为本
坚持以人民为中心的发展思想，紧扣群众的服务需求和服务体验，以群众满不满意、答不答应、高不高兴作为工作的目标，通过某城市社会保险智慧治理中心建设，支撑构建群众满意的某城市社会保险公共服务体系。
2. 坚持创新引领
综合利用互联网+、大数据+、智能+、物联网+、5G+、AI+、GIS+等主流技术，以机制改革、模式创新、数据驱动、技术赋能为动力，建设社会保险智慧治理中心，推进某城市社会保险现代化治理体系和治理能力的现代化。
3. 坚持问题导向
将破解制约某城市社会保险事业发展的重点、难点、痛点问题作为建设某城市社会保险智慧治理中心的着力点，找准突破口、增强针对性、突出全局性，提高服务标准化、专业化、协同化水平和治理智能化、精准化、科学化水平。
4. 坚持整体协同
某城市社会保险智慧治理中心建设，必须围绕某城市社会保险系统的全局工作，从制度衔接、政策配套、部门联动、业务协同、数据共享多个维度着手，打造业务与技术、内部与外部、横向与纵向、线上与线下融合的社会保险智慧治理新体系，形成支撑新时期社会保险高质量发展新动力。
5. 坚持安全可控
某城市社会保险智慧治理中心建设，必须正确处理创新发展与保障安全的关系，强化信息安全和个人隐私保护，健全多层次的社会保险风险防控体系，夯实可靠、可用、可持续的信息化支撑能力。
6. 坚持科学实施
按照某城市社会保险智慧中心的总体规划和建设方案，厘清社会保险智慧治理中心建设与金保工程整体建设的边界、关系与侧重点，充分运用现有信息化基础设施和应用系统，统筹规划、精心实施，注重可落地、可操作、可考核，确保某城市社会保险智慧治理中心建设的效能得以充分释放。
IV. 建设目标
建设目标是指集成建设的最终目的，达到什么样的效果，为什么而服务，是一种概念性的方针，通常相关方高层领导提出的构想、愿景等便是建设目标。
某城市社会保险智慧治理中心的建设目标，定义为：基于新时期社会保险事业职能使命与发展方向，按照“放管服”改革要求，依据新公共管理理论，综合运用互联网+、大数据+、智能+、物联网+、5G+、AI+、GIS+等现代思维与主流技术，以业务治理、综合治理、大数据治理为抓手。到某年，初步建成泛连、开放、融合、联动、智能、在线、可视、安全的某城市社会保险智慧治理中心，全面提高某城市社会保险系统的经办服务能力、智能监管能力、风险防控能力、决策分析能力、全域联动能力，推动构建全国领先的社会保险智能治理体系、智控风险体系、智联业务体系、智惠群众体系，树立城市治理行业新标杆，创建社会保险治理全国新范式，为推进新时期某城市社会保险事业高质量发展提供新动能，助力提升某城市治理科学化、精细化、智能化水平。
V. 总体框架
框架是一个用于规划、开发、实施、管理和维持架构的概念性结构，框架对架构设计是至关重要的。框架是将组织业务内容的关注度进行了合理的分离，以角色为出发点从不同视角展示组织业务的内容。框架为架构设计提供了一张路线图，引导和帮助架构设计达到建设起一个先进、高效且适用架构的目标。
信息系统体系架构总体参考框架由四个部分组成：
1. 战略系统
战略系统是指组织中与战略制定、高层决策有关的管理活动和计算机辅助系统。
在信息系统架构(Information System Architecture,ISA)中战略系统由两个部分组成
1||| 其一是以信息技术为基础的高层决策支持系统
2||| 其二是组织的战略规划体系
在ISA中设立战略系统有两重含义：
1||| 一是它表示信息系统对组织高层管理者的决策支持能力；
2||| 二是它表示组织战略规划对信息系统建设的影响和要求。
通常组织战略规划分成长期规划和短期规划两种，长期规划相对来说比较稳定，如调整产品结构等；短期规划一般是根据长期规划的目的而制订，相对来说，容易根据环境、组织运作情况而改变，如决定新产品的类型等。
2. 业务系统
业务系统是指组织中完成一定业务功能的各部分(物质、能量、信息和人)组成的系统。
组织中有许多业务系统，如生产系统、销售系统、采购系统、人事系统、会计系统等，每个业务系统由一些业务过程来完成该业务系统的功能，例如会计系统常包括应付账款、应收账款、开发票、审计等业务过程。
业务过程可以分解成一系列逻辑上相互依赖的业务活动，业务活动的完成有先后次序，每个业务活动都有执行的角色，并处理相关数据。当组织调整发展战略为了更好地适应内外部发展环境(如部署使用信息系统)等的时候，往往会开展业务过程重组。业务过程重组是以业务流程为中心，打破组织的职能部门分工，对现有的业务过程进行改进或重新组织，以求在生产效率、成本、质量、交货期等方面取得明显改善，提高组织的竞争力。
业务系统在ISA中的作用是：
对组织现有业务系统、业务过程和业务活动进行建模，并在组织战略的指导下，采用业务流程重组(Business Process Reengineering,BPR)的原理和方法进行业务过程优化重组，并对重组后的业务领域、业务过程和业务活动进行建模，从而确定出相对稳定的数据，以此相对稳定的数据为基础，进行组织应用系统的开发和信息基础设施的建设。
3. 应用系统
应用系统即应用软件系统，指信息系统中的应用软件部分。
对于组织信息系统中的应用软件(应用系统),一般按完成的功能可包含：
（1） 务处理系统(Transaction Processing System,TPS)
（2） 管理信息系统(Management Information System,MIS)
1||| 销售管理子系统
2||| 采购管理子系统
3||| 库存管理子系统
4||| 运输管理子系统
5||| 财务管理子系统
6||| 人事管理子系统等
（3） 决策支持系统(DecisionSupport System,DSS)
（4） 专家系统(Expert System,ES)
（5） 办公自动化系统(Office AutomationSystem,OAS)
（6） 计算机辅助设计/计算机辅助工艺设计/计算机辅助制造、制造执行系统(Manufacturing Execution System,MES)等
无论哪个层次上的应用系统，从架构的角度来看，都包含两个基本组成部分：内部功能实现部分和外部界面部分。这两个基本部分由更为具体的组成成分及组成成分之间的关系构成。界面部分是应用系统中相对变化较多的部分，主要由用户对界面形式要求的变化引起。在功能实现部分中，相对来说，处理的数据变化较小，而程序的算法和控制结构的变化较多，主要由用户对应用系统功能需求的变化和对界面形式要求的变化引起。
4. 信息基础设施
组织信息基础设施是指根据组织当前业务和可预见的发展趋势及对信息采集、处理、存储和流通的要求，构筑由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。
组织信息基础设施分成三部分：
1||| 技术基础设施
由计算机设备、网络、系统软件、支持性软件、数据交换协议等组成，
2||| 信息资源设施
由数据与信息本身、数据交换的形式与标准、信息处理方法等组成。
3||| 管理基础设施
指组织中信息系统部门的组织架构、信息资源设施管理人员的分工、组织信息基础设施的管理方法与规章制度等。
技术基础设施由于技术的发展和组织系统需求的变化，在信息系统的设计、开发和维护中面临的变化因素较多，并且由于实现技术的多样性，完成同一功能有多种实现方式。信息资源设施在系统建设中的相对变化较小，无论组织完成何种功能，业务流程如何变化，都要对数据和信息进行处理，它们中的大部分不随业务改变而改变。管理基础设施相对变化较多，这是组织为了适应环境的变化和满足竞争的需要，尤其在我国向市场经济转型升级的阶段，经济政策的出台或改变、业务模式改革等，将在很大程度上造成组织规章制度、管理方法、人员分工以及组织架构的改变。 上面只是对信息基础设施中的三个基本组成部分的相对稳定与相对变化程度的总体说明，在技术基础设施、信息资源设施、管理基础设施中都有相对稳定的部分和相对易变的部分，不能一概而论。
5. 战略系统处在第一层，其功能与战略管理层次的功能相似，一方面向业务系统提出创新、重构与再造的要求，另一方面向应用系统提出集成的要求。业务系统和应用系统同在第二层，属于战术管理层，业务系统在业务处理流程的优化上对组织进行管理控制和业务控制，应用系统则为这种控制提供有效利用信息和数据实现的手段，并提高组织的运行效率。信息基础设施处在第三层，是组织实现信息化、数字化的基础部分，相当于运行管理层，它为应用系统和战略系统提供计算、传输、数据等支持。同时也为组织的业务系统实现重组提供一个有效的、灵活响应的技术与管理支持平台。
二、 系统架构
I. 架构定义
i. 常见的定义主要有：
①软件或计算机系统的信息系统架构是该系统的一个(或多个)结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
②信息系统架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式约束组成。
③信息系统架构是指一个系统的基础组织，它具体体现在系统的构件、构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。
前两个定义都是按“元素—结构—架构”这一抽象层次来描述的，它们的基本意义相同。该定义中的“软件元素”是指比“构件”更一般的抽象，元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征等。
ii. 可以从以下6个方面进行理解：
1. 架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性。
2. 架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型信息系统架构。
3. 任何软件都存在架构，但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。
4. 元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能(外部可见),以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度(宏观)总体结构(如分层);在动态方面，关注系统内关键行为的共同特征。
5. 架构具有“基础”性：它通常涉及解决各类关键重复问题的通用方案(复用性),以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻，更改的代价昂贵)。
6. 架构隐含有“决策”,即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。
iii. 信息系统架构对组织非常重要，主要体现在：
①影响架构的因素。
软件系统的项目干系人(客户、用户、项目经理、程序员、测试人员、市场人员等)对软件系统有不同的要求、开发组织(项目组)有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。
②架构对上述诸因素具有反作用，例如，影响开发组织的结构。
架构描述了系统的大粒度(宏观)总体结构，因此可以按架构进行分工，将项目组分为几个工作组，从而使开发有序；影响开发组织的目标，即成功的架构为开发组织提供了新的商机，这归功于系统的示范性、架构的可复用性及团队开发经验的提升，同时，成功的系统将影响客户对下一个系统的要求等。
II. 架构分类
i. 分类
1. 物理架构
物理架构是指不考虑系统各部分的实际工作与功能架构，只抽象地考察其硬件系统的空间分布情况。
按照信息系统在空间上的拓扑关系一般分为
（1） 集中式架构
集中式架构是指物理资源在空间上集中配置。
早期的单机系统是最典型的集中式架构，它将软件、数据与主要外部设备集中在一套计算机系统之中。由分布在不同地点的多个用户通过终端共享资源组成的多用户系统，也属于集中式架构。集中式架构的优点是资源集中，便于管理，资源利用率较高。但是随着系统规模的扩大，以及系统的日趋复杂，集中式架构的维护与管理越来越困难，常常也不利于调动用户在信息系统建设过程中的积极性、主动性和参与感。此外，资源过于集中会造成系统的脆弱，一旦核心资源出现异常，容易使整个系统瘫痪。
（2） 分布式架构
分布式系统是指通过计算机网络把不同地点的计算机硬件、软件、数据等资源联系在一起，实现不同地点的资源共享。
分布式架构的主要特征是：可以根据应用需求来配置资源，提高信息系统对用户需求与外部环境变化的应变能力，系统扩展方便，安全性好，某个节点所出现的故障不会导致整个系统停止运作。然而由于资源分散，且又分属于各个子系统，系统管理的标准不易统一，协调困难，不利于对整个资源的规划与管理。
分布式架构又可分为
1||| 一般分布式系统
服务器只提供软件、计算与数据等服务，各计算机系统根据规定的权限存取服务器上的数据与程序文件。
2||| 客户端/服务器架构
分为客户端和服务器两大类。服务器包括文件服务器、数据库服务器、打印服务器等；网络节点上的其他计算机系统则称为客户端。用户通过客户端向服务器提出服务请求，服务器根据请求向用户提供经过加工的信息。
2. 逻辑架构
逻辑架构是指信息系统各种功能子系统的综合体。
信息系统的逻辑架构是其功能综合体和概念性框架。
对于一个生产组织的管理信息系统，从管理职能角度划分，包括采购、生产、销售、人力资源、财务等主要功能的信息管理子系统。一个完整的信息系统支持组织的各种功能子系统，使得每个子系统可以完成事务处理、操作管理、管理控制与战略规划等各个层次的功能。在每个子系统中可以有自己的专用文件，同时可以共享信息系统中各类数据，通过网络与数据等规范接口实现子系统之间的联系。与之相类似，每个子系统有各自的应用程序，也可以调用服务于各种功能的公共程序以及系统模型库中的模型等。
ii. 系统融合
1. 横向融合
横向融合是指将同一层次的各种职能与需求融合在一起，例如，将运行控制层的人事和工资子系统综合在一起，使基层业务处理一体化。
2. 纵向融合
纵向融合是指把某种职能和需求的各个层次的业务组织在一起，这种融合沟通了上下级之间的联系，如组织分支机构会计系统和整体组织会计系统融合在一起，它们都有共同之处，能形成一体化的处理过程。
3. 纵横融合
纵横融合是指主要是从信息模型和处理模型两个方面来进行综合，做到信息集中共享，程序尽量模块化，注意提取通用部分，建立系统公用数据体系和一体化的信息处理系统。
III. 一般原理
信息系统架构指的是在全面考虑组织的战略、业务、组织、管理和技术的基础上，着重研究组织信息系统的组成成分及成分之间的关系，建立起多维度分层次的、集成的开放式体系架构，并为组织提供具有一定柔性的信息系统及灵活有效的实现方法。
架构包含两个基本部分：组成成分和组成成分之间的关系。
在信息系统中，析出相对稳定的组成成分与关系，并在相对稳定部分的支持下，对相对变化较多的部分进行重新组织，以满足变化的要求，就能够使得信息系统对环境的变化具有一定的适应能力，即具有一定的柔性，这就是信息系统架构的基本原理。
IV. 常用架构模型
i. 单机应用模式
单机应用(Standalone)系统是最简单的软件结构，是指运行在一台物理机器上 的独立应用程序。当然，该应用可以是多进程或多线程的。
大型的软件系统，要有许多个子系统集成在一个图形界面上执行，并可在多种平台下运行，如 Linux、UNIX、Windows等。专业领域的产品，如计算机辅助设计领域的CATIA、Pro/Engineer、AutoCAD,还有在图片处理与编辑领域大家熟悉的 Photoshop、CorelDRAW 等。
软件架构设计较为重要的应用领域就是信息系统领域，即以数据处理(数据存储、传输、安全、查询、展示等)为核心的软件系统。
ii. 客户端/服务器模式
客户端/服务器模式(Client/Server)是信息系统中最常见的一种。可理解为基于TCP/IP 协议的进程间通信IPC编程的“发送”与“反射”程序结构，即Client方向 Server方发送一个TCP或UDP包，然后Server方根据接收到的请求向Client方回送TCP或UDP数据包
四种常见架构
1. 两层C/S
两层C/S,其实质就是IPC客户端/服务器结构的应用系统体现。即“胖客户端”模式。在实际的系统设计中，该类结构主要是指前台客户端十后台数据库管理系统。
前台界面+后台数据库服务的模式最为典型，数据库前端开发工具(如 PowerBuilder、Delphi、VB)等都是用来专门制作这种结构的软件工具。
2. 三层C/S与 B/S 结构
其前台界面送往后台的请求中，除了数据库存取操作以外，还有很多其他业务逻辑需要处理。三层C/S的前台界面与后台服务之间必须通过一种协议(自开发或采用标准协议)来通信(包括请求、回复、远程函数调用等)
通常包括以下几种：
1||| 基于TCP/IP协议，直接在底层Socket API基础上自行开发。这样做一般只适合需求与功能简单的小型系统。
2||| 首先建立自定义的消息机制(封装TCP/IP与Socket编程),然后前台与后台之间的通信通过该消息机制来实现。消息机制可以基于XML,也可以基于字节流(Stream)定义。虽然是属于自定义通信，但是它可以基于此构建大型分布式系统。
3||| 基于RPC编程。
4||| 基于CORBA/IOP协议。
5||| 基于Java RMI。
6||| 基于J2EE JMS。
7||| 基于HTTP协议，比如浏览器与Web服务器之间的信息交换。这里需要指出的是HTTP不是面向对象的结构，面向对象的应用数据会被首先平面化后进行传输。
最典型的基于三层C/S结构的应用模式是B/S(Brower/Server,浏览器/服务器)模式。
Web 浏览器是一个用于文档检索和显示的客户应用程序，并通过超文本传输协议HTTP(Hyper Text Transfer Protocol)与 Web 服务器相连。该模式下，通用的、低成本的浏览器节省了两层结构的C/S模式客户端软件的开发和维护费用。这些浏览器大家都很熟悉，包括 MSInternet Explorer、Mozilla FireFox 等。
Web服务器是指驻留于因特网上某种类型计算机的程序。当Web 浏览器(客户端)连到服务器上并请求文件或数据时，服务器将处理该请求并将文件或数据发送到该浏览器上，附带的信息会告诉浏览器如何查看该文件(即文件类型)。服务器使用HTTP进行信息交流，可称为HTTP 服务器。
人们每天都在 Web 浏览器上进行各种操作，这些操作中绝大多数其实都是在Web服务器上执行的，Web浏览器只是将人们的请求以HTTP协议格式发送到Web服务器端或将返回的查询结果显示而已。当然，驻留Web浏览器与服务器的硬件设备可以是位于Web 网络上的两台相距千里的计算机。
应该强调的是B/S模式的浏览器与Web服务器之间的通信仍然是TCP/IP,只是将协议格式在应用层进行了标准化。实际上B/S是采用了通用客户端界面的三层C/S结构。
3. 多层C/S结构
多层C/S结构一般是指三层以上的结构，在实践中主要是四层，即前台界面(如浏览器)、Web 服务器、中间件(或应用服务器)及数据库服务器。
其中中间件一层主要完成以下几个方面的工作
1||| 提高系统可伸缩性，增加并发性能。
2||| 中间件/应用层专门完成请求转发或一些与应用逻辑相关的处理，具有这种作用的中间件一般可以作为请求代理，也可作为应用服务器。中间件的这种作用在J2EE的多层结构中比较常用，如BEA WebLogic、IBM WebSphere等提供的EJB容器，就是专门用以处理复杂组织逻辑的中间件技术组成部分。
3||| 增加数据安全性。
4. 模型-视图 -控制器模式
模型-视图-控制器(Model-View-Controller,MVC)实际上是上述多层C/S结构的一种常用的标准化模式
在J2EE架构中，View表示层指浏览器层，用于图形化展示请求结果；Controller 控制器指Web服务器层，Model模型层指应用逻辑实现及数据持久化的部分。目前流行的J2EE开发框架，如JSF、Struts、Spring、Hibernate 等及它们之间的组合，如 Struts+Spring+Hibernate(SSH)、JSP+Spring+Hibernate 等都是面向MVC架构的。另外，PHP、Perl、MFC等语言都有MVC的实现模式。
MVC主要是要求表示层(视图)与数据层(模型)的代码分开，而控制器则可以用于连接 不同的模型和视图来完成用户的需求。从分层体系的角度来讲，MVC的层次结构，其控制器与视图通常处于Web服务器一层，而根据“模型”有没有将业务逻辑处理分离成单独服务处理，MVC可以分为三层或四层体系。
iii. 面向服务架构(SOA)模式
1. 面向服务架构
如果两个多层C/S结构的应用系统之间需要相互进行通信，那么就产生了面向服务架构 (Service Oriented Architecture,SOA)
独立应用系统是指无论该应用系统由多少层服务组成，去掉任何一层，它都将不能正常工作，对外可以是一个提供完整功能的独立应用。
借助中间件来实现SOA的需求，如消息中间件、交易中间件等。
面向服务架构在实践中又可以具体分为异构系统集成、同构系统聚合、联邦体系结构等。
2. Web Service
面向服务架构体现在 Web应用之间，就成为了 Web Service,即两个互联网应用之间可以相互向对方开放一些内部“服务”(这种服务可以理解为功能模块、函数、过程等)。目前，Web应用对外开放其内部服务的协议主要有 SOAP与 WSDL,具体资料可以查阅相关标准。
Web Service 是面向服务架构的一个最典型、最流行的应用模式。
3. 面向服务架构的本质
本质是消息机制或远程过程调用(RPC)。
iv. 组织级数据交换总线
即不同的组织应用之间进行信息交换的公共通道。
这种架构在大型组织不同应用系统进行信息交换时使用较普遍，在国内，主要是信息化、数字化程度较高的组织采用此种结构
关于数据总线本身，其实质应该是一个称之为连接器的软件系统(Connector),它可以基于中间件(如：消息中间件或交易中间件)构建，也可以基于CORBA/IOP 协议开发，主要功能是按照预定义的配置或消息头定义，进行数据(data)、请求(request)或回复(response)的接收与分发。
组织级数据交换总线可以同时具有实时交易与大数据量传输的功能，但在实践中，成熟的企业数据交换总线主要是为实时交易而设计的，而对可靠的大数据量级传输需求往往要单独设计。如果采用CORBA为通信协议，交换总线就是对象请求代理(ORB),也被称为“代理(Agent)体系”。
V. 规划与设计
i. 集成架构演进
1. 以应用功能为主线架构
对于中小型工业企业或者处于信息化、数字化发展初级阶段的工业企业来说，其信息系统集成建设的主要目标是提高工作效能、降低业务风险。同时，受制于自身信息化队伍和人才的不足，以及业务体系对信息化、数字化理解得不深入等，企业往往采用“拿来主义”来构建其信息系统，即直接采购成套且成熟的应用软件，并基于应用软件的运行需求，建设相关的基础设施。
企业发展在该阶段重点关注的是组织职能的细化分工以及行业最佳实践的导入。因此组织的信息化建设往往以部门或职能为单元，核心关注点是信息系统的软件功能，如财务管理、设备管理、资产管理等，从而进行信息系统规划、设计、部署和运行等。同时，通过成套软件的部署，强化自身的管理或工艺水平等。应用软件或模块间的集成融合，主要通过系统的软件接口来完成。企业往往采用统一规划、分步实施的方式进行，即需要什么功能，部署上线什么功能
2. 以平台能力为主线架构
以平台能力为主线的系统集成架构起源于云计算技术的发展和云服务的逐步成熟。其核心理念是将“竖井式”信息系统各个组成部分，转化为“平层化”建设方法，包括数据采集平层化、网络传输平层化、应用中间件平层化、应用开发平层化等，并通过标准化接口和新型信息技术，实现信息系统的弹性、敏捷等能力建设。通过平台化架构支撑的信息系统应用，可以结合专题建设或独立配置(或少量开发),快速得到企业需求的应用系统功能，从而突破成套软件商在个性化软件定制方面的不足。
在具体实践中，企业的架构转型是一个持续的过程。企业会将成熟度高、少变化的应用继续使用成套软件部署模式，对新型的、多变化的应用采用平台化架构，最终保持两种架构并存(也称双态 IT,即敏态与稳态融合)或全部转换到平台化架构中。
3. 互联网为主线架构
当企业发展到产业链或生态链阶段，或者成为复杂多元的集团化企业，企业开始寻求向以互联网为主线的系统集成架构方向转移或过渡。
以互联网为主线的系统集成架构，强调将各信息系统功能最大限度地App化(微服务)
以互联网为主线的系统集成架构，整合应用了更多的新一代信息技术及其应用创新
4. 采用不同的主线架构，本质上取决于企业业务发展的程度，表现为企业数字化转型的成熟度。
ii. TOGAF 架构开发方法
TOGAF(The Open Group Architecture Framework)是一种开放式企业架构框架标准，它为标准、方法论和企业架构专业人员之间的沟通提供一致性保障。
TOGAF基础
TOGAF由国际组织 The Open Group 制定。
该组织于1993年开始应客户要求制定系统架构标准，在1995年发表 TOGAF架构框架。TOGAF的基础是美国国防部的信息管理技术架构(Technical Architecture For Information Management,TAFIM)。它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可用于设计、评估并建立适合的企业架构。在国际上，TOGAF 已经被验证，可以灵活、高效地构建企业 IT架构。
该框架旨在通过以下四个目标帮助企业组织和解决所有关键业务需求：
1||| 确保从关键利益相关方到团队成员的所有用户都使用相同语言。这有助于每个人以相同的方式理解框架、内容和目标，并让整个企业在同一页面上打破任何沟通障碍。
2||| 避免被“锁定”到企业架构的专有解决方案。只要该企业在内部使用TOGAF而不是用于商业目的，该框架就是免费的。
3||| 节省时间和金钱，可以更有效地利用资源。
4||| 实现可观的投资回报(ROI)。
TOGAF反映了企业内部架构能力的结构和内容，TOGAF9版本包括六个组件：
1||| 架构开发方法
这部分是TOGAF的核心，它描述了TOGAF架构开发方法(Architecture Development Method,ADM),ADM是一种开发企业架构的分步方法。
2||| ADM指南和技术
这部分包含一系列可用于应用ADM的指南和技术。
3||| 架构内容框架
这部分描述了TOGAF内容框架，包括架构工件的结构化元模型、可重用架构构建块(ABB)的使用以及典型架构可交付成果的概述。
4||| 企业连续体和工具
这部分讨论分类法和工具，用于对企业内部架构活动的输出进行分类和存储。
5||| TOGAF参考模型
这部分提供了两个架构参考模型，即TOGAF技术参考模型(TRM)和集成信息基础设施参考模型(II-RM)。
6||| 架构能力框架
这部分讨论在企业内建立和运营架构实践所需的组织、流程、技能、角色和职责。
TOGAF 框架的核心思想是：
1||| 模块化架构
TOGAF标准采用模块化结构。
2||| 内容框架
TOGAF标准包括了一个遵循架构开发方法(ADM)所产出的结果更加一致的内容框架。TOGAF内容框架为架构产品提供了详细的模型。
3||| 扩展指南
TOGAF标准的一系列扩展概念和规范为大型组织的内部团队开发多层级集成架构提供支持，这些架构均在一个总体架构治理模式内运行。
4||| 架构风格
TOGAF标准在设计上注重灵活性，可用于不同的架构风格。
5||| TOGAF的关键是架构开发方法，它是一个可靠的、行之有效的方法，能够满足商务需求的组织架构。
ADM方法
架构开发方法(ADM)为开发企业架构所需要执行的各个步骤以及它们之间的关系进行了 详细的定义，同时它也是TOGAF规范中最为核心的内容。
ADM方法是由一组按照架构领域的架构开发顺序排列成一个环的多个阶段构成。
此模型将ADM全生命周期划分为预备阶段、需求管理、架构愿景、业务架构、信息系统架构(应用和数据)、技术架构、机会和解决方案、迁移规划、实施治理、架构变更治理等十个阶段，这十个阶段是反复迭代的过程。
ADM方法被迭代式应用在架构开发的整个过程中、阶段之间和每个阶段内部。在ADM的全生命周期中，每个阶段都需要根据原始业务需求对设计结果进行确认，这也包括业务流程中特有的一些阶段。确认工作需要对企业的覆盖范围、时间范围、详细程度、计划和里程碑进行重新审议。每个阶段都应该考虑到架构资产的重用。
ADM便形成了3个级别的迭代概念：
1||| 基于ADM整体的迭代
用一种环形的方式来应用ADM方法，表明了在一个架构开发工作阶段完成后会直接进入随后的下一个阶段。
2||| 多个开发阶段间的迭代
在完成了技术架构阶段的开发工作后又重新回到业务架构开发阶段。
3||| 在一个阶段内部的迭代
TOGAF支持基于一个阶段内部的多个开发活动，对复杂的架构内容进行迭代开发。
ADM各个开发阶段的主要活动
VI. 价值驱动的体系结构
i. 模型概述
系统目的是为其利益相关者创造价值。
价值模型核心的特征：
（1） 价值期望值
价值期望值表示对某一特定功能的需求，包括内容(功能)、满意度(质量)和不同级别质量的实用性。
例如，汽车驾驶员对汽车以60公里每小时的速度进行急刹车的快慢和安全性有一种价值期望值。
（2） 反作用力
系统部署实际环境中，实现某种价值期望值的难度，通常期望越高难度越大，即反作用力。
例如，汽车以60公里每小时的速度进行紧急刹车的结果如何取决于路面类型、路面坡度和汽车重量等。
（3） 变革催化剂
变革催化剂表示环境中导致价值期望值发生变化的某种事件，或者是导致不同结果的限制因素。
反作用力和变革催化剂称为限制因素，这三个统称为价值驱动因素。如果系统旨在有效满足其利益相关者的价值模型要求，那么它就需要能够识别和分析价值模型。
一般方法，如用例方案和业务/营销需求，都是通过聚焦于与系统进行交互的参与者的类型开始的，这种方法有如下4个突出的局限性。
（1） 对参与者的行为模型关注较多，而对其中目标关注较少。
（2） 往往将参与者固化地分成几种角色，其中每个角色所在的个体在本质上都是相同的(例如，商人、投资经理或系统管理员)。
（3） 往往忽略限制因素之间的差别(例如，纽约的证券交易员和伦敦的证券交易员是否相同，市场开放交易与每天交易是否相同)。
（4） 结果简单。要求得到满足或未得到满足，用例成功完成或未成功完成。
这种方法有一个非常合乎逻辑的实际原因，它使用顺序推理和分类逻辑，因此易于教授和讲解，并能生成一组易于验证的结果。
ii. 结构挑战
体系结构挑战是因为一个或多个限制因素，使得满足一个或多个期望值变得更困难。
在任何环境中，识别体系结构挑战都涉及评估。
（1） 哪些限制因素影响一个或多个期望值。
（2） 如果知道了影响，它们满足期望值更容易(积极影响)还是更难(消极影响)。
（3） 各种影响的影响程度如何，在这种情况下，简单的低、中和高三个等级通常就已经够用了。
评估必须在体系结构挑战自己的背景中对其加以考虑。虽然跨背景平均效用曲线是可能的，但对于限制因素对期望值的影响不能采用同样的处理方法。例如，假设Web服务器在两种情况下提供页面：一种情况是访问静态信息，如参考文献，它们要求响应时间为1～3s;另一种情况是访问动态信息，如正在进行的体育项目的个人得分表，其响应时间为3～6s。
两种情况都有 CPU、内存、磁盘和网络局限性。不过，当请求量增加10或100倍时，这两种情况可能遇到大不相同的可伸缩性障碍。对于动态内容，更新和访问的同步成为重负载下的一个限制因素。对于静态内容，重负载可以通过频繁缓存读页来克服。
制定系统的体系结构策略始于：
（1） 识别合适的价值背景并对其进行优先化。
（2） 在每一背景中定义效用曲线和优先化期望值。
（3） 识别和分析每一背景中的反作用力和变革催化剂。
（4） 检测限制因素使其满足期望值变难的领域。
最早的体系结构决策产生最大价值才有意义。有几个标准可用于优先化体系结构，建议对重要性、程度、后果和隔离等进行权衡。
（1） 重要性
受挑战影响的期望值的优先级有多高，如果这些期望值是特定于不多的几个背景，那么这些背景的相对优先级如何。
（2） 程度
限制因素对期望值产生了多大影响。
（3） 后果
大概多少种方案可供选择，这些方案的难度或有效性是否有很大差异。
（4） 隔离
对最现实的方案的隔离情况如何。
体系结构策略的指导规则
（1） 组织
如何系统性地组织子系统和组件?它们的组成和职责是什么?系统如何部署在网络上?都有哪些类型的用户和外部系统?它们位于何处，是如何连接的?
（2） 操作
组件如何交互?在哪些情况下通信是同步的，在哪些情况下是异步的?组件的各种操作是如何协调的?何时可以配置组件或在其上运行诊断?如何检测、诊断和纠正错误条件?
（3） 可变性
系统的哪些重要功能可以随部署环境的变化而变化?对于每一功能，哪些方案得到支持?何时可以做出选择(例如，编译、链接、安装、启动或在运行时)?各个分歧点之间有什么相关性?
（4） 演变
为了支持变更同时保持其稳定性，系统是如何设计的?哪些特定类型的重大变革已在预料之中?应对这些变更有哪些可取的方法?
体系结构策略就像帆船的舵和龙骨，可以确定方向和稳定性。它应该是简短的、高标准的方向陈述，必须能够被所有利益相关者所理解，并应在系统的整个生命周期内保持相对稳定。
iii. 模型与结构的联系
价值模型和软件体系结构的联系是明确而又合乎逻辑的，可以用以下9点来表述。
（1） 软件密集型产品和系统的存在是为了提供价值。
（2） 价值是一个标量，它融合了对边际效用的理解和诸多不同目标之间的相对重要性，目标折中是一个极其重要的问题。
（3） 价值存在于多个层面，其中某些层面包含了目标系统，并将其作为一个价值提供者。用于这些领域的价值模型包含了软件体系结构的主要驱动因素。
（4） 该层次结构中高于上述层面的价值模型可以导致其下层价值模型发生变化。这是制定系统演化原则的一个重要依据。
（5） 对于每一个价值群，价值模型都是同类的。暴露于不同环境条件的价值背景具有不同的期望值。
（6） 对于满足不同价值背景需要，系统的开发赞助商有着不同的优先级。
（7） 体系结构挑战是由环境因素在某一背景中对期望的影响引起的。
（8） 体系结构方法试图通过首先克服最高优先级体系结构挑战来实现价值的最大化。
（9） 体系结构策略是通过总结共同规则、政策和组织原则、操作、变化和演变从最高优先级体系结构方法综合得出的。
三、 应用架构
I. 概要
应用架构的主要内容是规划出目标应用分层分域架构，根据业务架构规划目标应用域、应用组和目标应用组件，形成目标应用架构逻辑视图和系统视图。
从功能视角出发，阐述应用组件各自及应用架构整体上，如何实现组织的高阶IT 需求，并描述主要目标应用组件之间的交互关系。
II. 基本原则
1. 业务适配性原则
应用架构应服务和提升业务能力，能够支撑组织的业务或技术发展战略目标，同时应用架构要具备一定的灵活性和可扩展性，以适应未来业务架构发展所带来的变化。
2. 应用聚合化原则
基于现有系统功能，通过整合部门级应用，解决应用系统多、功能分散、重叠、界限不清晰等问题，推动组织集中的“组织级”应用系统建设。
3. 功能专业化原则
按照业务功能聚合性进行应用规划，建设与应用组件对应的应用系 统，满足不同业务条线的需求，实现专业化发展。
4. 风险最小化原则
降低系统间的耦合度，提高单个应用系统的独立性，减少应用系统间的相互依赖，保持系统层级、系统群组之间的松耦合，规避单点风险，降低系统运行风险，保证应用系统的安全稳定。
5. 资产复用化原则
鼓励和推行架构资产的提炼和重用，满足快速开发和降低开发与维护成本的要求。规划组织级共享应用成为基础服务，建立标准化体系，在组织内复用共享。同时，通过复用服务或者组合服务，使架构具有足够的弹性以满足不同业务条线的差异化业务需求，支持组织业务持续发展
III. 分层分组
对应用架构进行分层的目的是要实现业务与技术分离，降低各层级之间的耦合性，提高各层的灵活性，有利于进行故障隔离，实现架构松耦合。
应用分层可以体现以客户为中心的系统服务和交互模式，提供面向客户服务的应用架构视图。
对应用分组的目的是要体现业务功能的分类和聚合，把具有紧密关联的应用或功能内聚为一个组，可以指导应用系统建设，实现系统内高内聚，系统间低耦合，减少重复建设。
某城市社会保险智慧治理中心的应用架构示意
规划为四大类
（1） 治理渠道
1||| 移动版应用
主要为各级管理者提供各类重要主题、热门主题、业务主题及大数据主题的可视化视图、重要指标监控、指数分析、绩效评价、趋势分析、指挥调度等应用功能，实现治理中心不同应用场景下社会保障发展事业数据、营商环境指数和相关报告的同步查阅。
2||| 桌面版应用
面向某城市社会保险各业务领域及信息部门管理人员，提供社会保险领域的综合主题、各业务领域的业务主题及大数据主题的人本化服务、可视化监管、智能化监督、科学化决策、在线化指挥等应用功能，实现指挥调度、会议会商、任务分发、协查协办、专项整治等不同应用场景的智慧治理。
3||| 大屏应用
面向某城市社会保险各级领导及部门管理人员，提供各类重要主题、热门主题、业务主题及大数据主题的重要指标监控、决策分析、绩效评价、趋势分析等可视化呈现。
（2） 治理中心系统
主要集中展示交互三大类主题
1||| 业务主题
包括就业创业、社会保险、劳动维权、人事管理、人才服务、人事和职业考试、行政审批、电话咨询服务、社会保障卡等。
2||| 综合主题
包括宏观决策、指挥调度、廉政风控、基金管理、事业发展、营商环境、扶贫追踪、服务监控、舆情监控、行风监督、效能评价、事件管理、电子证照、标准管理、惠民惠农等。
3||| 大数据主题
包括社保画像、社保档案袋、社保信用分、社保地图、社保图谱、社保基金精算、社保指数评价、社保全景分析等。
（3） 治理配套系统
为本项目智慧治理中心提供四大类应用
1||| 数据支撑类应用
包括数据汇聚系统、数据治理系统、数据应用系统。
2||| 联动服务类应用
包括指挥调度管理系统、精准扶贫管理系统、劳动维权预警管理系统、电子证照系统、用户画像系统。
3||| 治理监管类应用
包括标准管理系统、行风监督系统、信用管理系统、基金精算分析系统、服务效能评价系统。
4||| 展示交互类应用
包括移动治理 App。
（4） 相关系统改造
主要涉及与本次智慧治理中心相关主题的数据汇聚、展现、交互等关联的劳动就业系统、社会保险系统、劳动关系系统、人事人才系统、公共服务系统、风险防控系统等的改造。
四、 数据架构
I. 概要
数据架构描述了组织的逻辑和物理数据资产以及相关数据管理资源的结构。
数据架构的主要内容涉及数据全生命周期之下的架构规划，包括数据的产生、流转、整合、应用、归档和消亡。
数据架构关注数据所处的生命周期环节中数据被操作的特征和数据类型、数据量、数据技术处理的发展、数据的管控策略等数据领域的概念相关。
II. 发展演进
1. 单体应用架构时代
在信息化早期(20世纪80年代),信息化初步建设，信息系统以单体应用为主，例如：早 期的财务软件、OA办公软件等。这个时期数据管理的概念还在萌芽期，数据架构比较简单，主要就是数据模型、数据库设计，满足系统业务使用即可。
2. 数据仓库时代
随着信息系统的使用，系统的数据也逐步积累起来。这时候，人们发现数据对组织是有价值的，但是割裂的系统导致了大量信息孤岛的产生，严重影响了组织对数据的利用。于是，一种面向主题的、集成的、用于数据分析的全新架构诞生了，它就是数据仓库。
与传统关系数据库不同，数据仓库系统的主要应用是OLAP,支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。这个阶段，数据架构不仅关注数据模型，还关注数据的分布和流向。
3. 大数据时代
大数据技术的兴起，让组织能够更加灵活高效地使用自己的数据，从数据中提取出更多重要的价值。与此同时，在大数据应用需求的驱动下，各类大数据架构也在不断发展和演进着，从批处理到流处理，从大集中到分布式，从批流一体到全量实时。
III. 基本原则
数据架构的设计原则是在遵循架构设计通用原则的情况下，有数据架构自身的特殊考虑。
合理的数据架构设计应该是解决以下问题：功能定位合理性问题，面向未来发展的可扩展性问题，处理效率高效或者说高性价比的问题；数据合理分布和数据一致性问题。
基本原则包括
1. 数据分层原则
2. 数据处理效率原则
3. 数据一致性原则
4. 数据架构可扩展性原则
（1） 基于分层定位的合理性原则之上。
（2） 架构的可扩展性需要对数据存储模型和数据存储技术也进行考虑。
5. 服务于业务原则
IV. 架构举例
某城市社会保险智慧治理中心的数据架构示意。
主要数据资源库包括
（1） 源数据库
源数据库是某城市社会保险智慧治理中心所需数据的源端
（2） 交换库
利用OGG等同步工具或通过数据同步、服务调用等方式将源端的数据库同 步到交换数据库中，采用数据同步或者镜像的方式，降低对源数据库的影响。
（3） 过渡库
过OGG For Bigdata 抽取变量数据、Sqoop 抽取、推送、导入等方式抽取交换库中的数据，存储于Hadoop平台中的过渡库中，以便提高大批量数据处理性能。
（4） 整合库
对过渡库的数据进行对照、转换、清洗、聚集，按照统一的库表结构存储在 整合库中，为各主题库提供增量数据源和全量数据源。
（5） 主题库
即服务库，根据治理主题应用需求，从整合库中提取所需数据，为治 理应用和可视化展现提供支撑。
五、 技术架构
I. 概要
技术架构是承载组织应用架构和数据架构的基础，它是一个由多个功能模块组成的整体，描述组织业务应用实现所采用的技术体系或组合，以及支持应用系统部署所需的基础设施和环境等。
技术架构需要统筹考虑和统一规划，缺乏总体策略和思路的IT技术架构会导致投资的严重浪费和建设的时间延误等，总体功能败于最弱的环节，使IT成为业务发展的瓶颈。
II. 基本原则
1. 成熟度控制原则
2. 技术一致性原则
3. 局部可替换原则
4. 人才技能覆盖原则
5. 创新驱动原则
III. 架构举例
某城市社会保险智慧治理中心的技术架构示意。
本项目采用当今先进成熟的技术架构和路线，保障某城市社会保险智慧治理中心的先进性、高效性、可靠性和可扩展性。
技术架构按照分类分层法进行设计，包括
（1） 技术标准
遵循J2EE、HTML5、CSS3、SQL、Shell、XML/JSON、HTTP、FTP、SM2、SM3、JavaScript 等国际和国内通用标准。
（2） 基础支撑
1||| 依托5G网络、物联网为本项目提供基础网络支撑；
2||| 依托应用中间件为本项目提供应用部署支撑；
3||| 依托分布式缓存、内存数据库、MPP数据库、事务数据库为本项目提供基础数据存储支撑；
4||| 依托 Hadoop平台为本项目提供分布式存储和计算环境支撑；
5||| 依托搜索引擎、规则引擎组件为治理应用提供技术组件支撑。
（3） 应用框架技术
是应用系统开发需要严格遵循并采用的技术。
应用框架采用分层设计，包括访问接入层、交互控制层、业务组件层、资源访问层。
（4） 应用集成技术
包括单点登录、服务总线(ESB)、流程引擎、消息队列等技术，支撑各应用系统之间的整合集成。
（5） 数据集成技术
包括 ETL工具、数据同步复制工具、数据标引、SQL/存储过程、MapReduce/Spark 计算引擎等技术，为某城市社会保险智慧治理中心的数据采集、数据清洗、数据转换、数据加工、数据挖掘等工作提供技术支撑。
（6） 数据分析技术
包括BI引擎、报表引擎、GIS引擎、图表组件、3D引擎、多维建模引擎以及AI算法包、数据挖掘算法包等大数据技术，为社保地图、远程指挥调度、全景分析、宏观决策、监控监督等应用的可视化提供技术支撑。
（7） 运维技术
包括操作留痕、故障预警、能效监测、日志采集、漏洞扫描、应 用监控、网络分析等技术，支撑应用系统的规范化运维。
六、 网络架构
I. 网络是信息技术架构中的基础，不仅是用户请求和获取IT信息资源服务的通道，同时也是信息系统架构中各类资源融合和调度的枢纽。
II. 基本原则
1. 高可靠性
网络作为底层资源调度和服务传输的枢纽和通道，其对高可靠性的要求自 然不言而喻。
2. 高安全性
信息系统的安全性不能仅靠应用级的安全保障，网络也必须能够提供基础的安全防护，底层的身份鉴别、访问控制、入侵检测能力等需要能够为应用提供重要的安全保障。
3. 高性能
网络不仅仅是服务传递的通道，更是提供服务所需资源调度的枢纽，因此网络性能和效率是提供更优服务质量的保证。
4. 可管理性
不仅是指网络自身管理，更指基于业务部署策略的网络快速调整和管控。
5. 平台化和架构化
作为底层基础资源的网络需要以开阔的视野，适应未来应用架构的 变化，网络自身能够更加弹性，做到按需扩展，以适应未来不同业务规模的变化和发展。
III. 局域网架构
局域网指计算机局部区域网络，是一种为单一组织所拥有的专用计算机网络。
其特点包括：
①覆盖地理范围小，通常限定在相对独立的范围内，如一座建筑或集中建筑群内(通常在2.5km内);
②数据传输速率高(一般在10Mb/s以上，典型1Gb/s,甚至10Gb/s);
③低误码率(通常在10°以下),可靠性高；
④支持多种传输介质，支持实时应用。就网络拓扑而言，有总线、环形、星形、树状等类型。
从传输介质来说，包含有线局域网和无线局域网等。
局域网通常由计算机、交换机、路由器等设备组成。
局域网不仅提供二层交换功能，还提供三层路由功能的复杂网络。
架构类型
1. 单核心架构
单核心局域网通常由一台核心二层或三层交换设备充当网络的核心设备，通过若干台接入交换设备将用户设备(如用户计算机、智能设备等)连接到网络中
此类局域网可通过连接核心网交换设备与广域网之间的互联路由设备(边界路由器或防火墙)接入广域网，实现业务跨局域网的访问。
单核心网具有如下特点：
1||| 核心交换设备通常采用二层、三层及以上交换机；如采用三层以上交换机可划分成VLAN,VLAN内采用二层数据链路转发，VLAN之间采用三层路由转发；
2||| 接入交换设备采用二层交换机，仅实现二层数据链路转发；
3||| 核心交换设备和接入设备之间可采用100M/GE/10GE(1GE=1Gb/s)等以太网连接。
用单核心构建网络，其优点是网络结构简单，可节省设备投资。需要使用局域网的分项组织接入较为方便，直接通过接入交换设备连接至核心交换设备空闲接口即可。其不足是网络地理范围受限，要求使用局域网的分项组织分布较为紧凑；核心网交换设备存在单点故障，容易导致网络整体或局部失效；网络扩展能力有限；在局域网接入交换设备较多的情况下，对核心交换设备的端口密度要求高。
作为一种变通，对于较小规模的网络，采用此网络架构的用户设备也可直接与核心交换设备互联，进一步减少投资成本。
2. 双核心架构
双核心架构通常是指核心交换设备采用三层及以上交换机。
核心交换设备和接入设备之间可采用100M/GE/10GE等以太网连接网络内划分VLAN时，各 VLAN之间访问需通过两台核心交换设备来完成。网络中仅核心交换设备具备路由功能，接入设备仅提供二层转发功能。
核心交换设备之间互联，实现网关保护或负载均衡。核心交换设备具备保护能力，网络拓扑结构可靠。在业务路由转发上可实现热切换。接入网络的各部门局域网之间互访，或访问核心业务服务器，有一条以上条路径可选择，可靠性更高。
需要使用局域网的专项组织接入较为方便，直接通过接入交换设备连接至核心交换设备空闲接口即可。设备投资相比单核心局域网高。对核心交换设备的端口密度要求较高。所有业务服务器同时连接至两台核心交换设备，通过网关保护协议进行保护，为用户设备提供高速访问。
3. 环形架构
环形局域网是由多台核心交换设备连接成双RPR(Resilient Packet Ring)动态弹性分组环，构建网络的核心。
核心交换设备通常采用三层或以上交换机提供业务转发功能
典型环形局域网网络内各VLAN之间通过RPR环实现互访。RPR具备自愈保护功能，节省光纤资源；具备MAC层50ms自愈时间的能力，提供多等级、可靠的QoS服务、带宽公平机制和拥塞控制机制等。RPR环双向可用。网络通过两根反向光纤组成环形拓扑结构，节点在环上可从两个方向到达另一节点。每根光纤可同时传输数据和控制信号。RPR利用空间重用技术，使得环上的带宽得以有效利用。
通过RPR组建大规模局域网时，多环之间只能通过业务接口互通，不能实现网络直接互通。环形局域网设备投资比单核心局域网的高。核心路由冗余设计实施难度较高，且容易形成环路。此网络通过与环上的交换设备互联的边界路由设备接入广域网。
4. 层次局域网架构
层次局域网(或多层局域网)由核心层交换设备、汇聚层交换设备和接入层交换设备以及 用户设备等组成
层次局域网模型中的核心层设备提供高速数据转发功能；汇聚层设备提供的充足接口实现了与接入层之间的互访控制，汇聚层可提供所辖的不同接入设备(部门局域网内)业务的交换功能，减轻对核心交换设备的转发压力；接入层设备实现用户设备的接入。层次局域网网络拓扑易于扩展。网络故障可分级排查，便于维护。通常，层次局域网通过与广域网的边界路由设备接入广域网，实现局域网和广域网业务的互访。
IV. 广域网架构
广域网是将分布于相比局域网络更广区域的计算机设备连接起来的网络。
广域网由通信子网与资源子网组成。通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网来构建，将分布在不同地区的局域网或计算机系统互连起来，实现资源子网的共享。
广域网属于多级网络，通常由骨干网、分布网、接入网组成。在网络规模较小时，可仅由骨干网和接入网组成。在广域网规划时，需要根据业务场景及网络规模来进行三级网络功能的选择。例如规划某省银行广域网，设计骨干网，如支持数据、语音、图像等信息共享，为全银行系统提供高速、可靠的通信服务；设计分布网，提供数据中心与各分行、支行的数据交换，提供长途线路复用和主干访问；设计接入网，提供各分支行与各营业网点的数据交换时采用访问路由方式，实现网点线路复用和终端访问。
架构类型
1. 单核心广域网
单核心广域网通常由一台核心路由设备和各局域网组成，如图4-13所示。核心路由设备采用三层及以上交换机。网络内各局域网之间访问需要通过核心路由设备。
网络中各局域网之间不设立其他路由设备。各局域网至核心路由设备之间采用广播线 路，路由设备与各局域网互联接口属于对应局域网子网。核心路由设备与各局域网可采用10M/100M/GE 以太接口连接。该类型网络结构简单，节省设备投资。各局域网访问核心局域网以及相互访问的效率高。新的部门局域网接入广域网较为方便，只要核心路由设备留有端口即可。不过，核心路由设备存在单点故障容易导致整网失效的风险。网络扩展能力欠佳，对核心路由设备端口密度要求较高。
2. 双核心广域网
双核心广域网通常由两台核心路由设备和各局域网组成，如图4-14所示。
双核心广域网模型，其主要特征是核心路由设备通常采用三层及以上交换机。核心路由 设备与各局域网之间通常采用10M/100M/GE等以太网接口连接。网络内各局域网之间访问需经过两台核心路由设备，各局域网之间不存在其他路由设备用于业务互访。核心路由设备之间实现网关保护或负载均衡。各局域网访问核心局域网以及它们相互访问可有多条路径选择，可靠性更高，路由层面可实现热切换，提供业务连续性访问能力。在核心路由设备接口有预留情况下，新的局域网可方便接入。不过，设备投资较单核心广域网高。核心路由设备的路由冗余设计实施难度较高，容易形成路由环路。网络对核心路由设备端口密度要求较高。
3. 环形广域网
环形广域网通常是采用三台以上核心路由器设备构成路由环路，用以连接各局域网，实现广域网业务互访
环形广域网的主要特征是核心路由设备通常采用三层或以上交换机。核心路由设备与各局域网之间通常采用10M/100M/GE等以太网接口连接。网络内各局域网之间访问需要经过核心路由设备构成的环。各局域网之间不存在其他路由设备进行互访。核心路由设备之间具备网关保护或负载均衡机制，同时具备环路控制功能。各局域网访问核心局域网或互相访问有多条路径可选择，可靠性更高，路由层面可实现无缝热切换，保证业务访问连续性。
在核心路由设备接口有预留情况下，新的部门局域网可方便接入。不过，设备投资比双核心广域网高，核心路由设备的路由冗余设计实施难度较高，容易形成路由环路。环形拓扑结构需要占用较多端口，网络对核心路由设备端口密度要求较高。
4. 半冗余广域网
半冗余广域网是由多台核心路由设备连接各局域网而形成的，如图4-16所示。其中，任意核心路由设备至少存在两条以上连接至其他路由设备的链路。如果任何两个核心路由设备之间均存在链接，则属于半冗余广域网特例，即全冗余广域网。
半冗余广域网的主要特征是结构灵活、扩展方便。部分网络核心路由设备可采用网关保护或负载均衡机制或具备环路控制功能。网络结构呈网状，各局域网访问核心局域网以及相互访问存在多条路径，可靠性高。路由层面的路由选择较为灵活。网络结构适合于部署OSPF等链路状态路由协议。不过，网络结构零散，不便于管理和排障。
5. 对等子域广域网
对等子域网络是通过将广域网的路由设备划分成两个独立的子域，每个子域路由设备采用半冗余方式互连。两个子域之间通过一条或多条链路互连，对等子域中任何路由设备都可接入局域网络，如图4-17 所示。
对等子域广域网的主要特征是对等子域之间的互访以对等子域之间互连链路为主。对等子域之间可做到路由汇总或明细路由条目匹配，路由控制灵活。通常，子域之间链路带宽应高于子域内链路带宽。域间路由冗余设计实施难度较高，容易形成路由环路，或存在发布非法路由风险。对域边界路由设备的路由性能要求较高。网络中路由协议主要以动态路由为主。对等子域适合于广域网可以明显划分为两个区域且区域内部访问较为独立的场景。
6. 层次子域广域网
层次子域广域网结构是将大型广域网路由设备划分成多个较为独立的子域，每个子域内路由设备采用半冗余方式互连，多个子域之间存在层次关系，高层次子域连接多个低层次子域。层次子域中任何路由设备都可以接入局域网，如图4-18所示。
层次子域的主要特征是层次子域结构具有较好扩展性。低层次子域之间互访需要通过高层次子域完成。域间路由冗余设计实施难度较高，容易形成路由环路，存在发布非法路由的风险。子域之间链路带宽须高于子域内链路带宽。对用于域互访的域边界路由设备的路由转发性能要求较高。路由设备路由协议主要以动态路由为主，如OSPF协议。层次子域与上层外网互连，主要借助高层子域完成；与下层外网互连，主要借助低层子域完成。
V. 移动通信网架构
移动通信网为移动互联网提供了强有力的支持，尤其是5G网络为个人用户、垂直行业等提供了多样化的服务。
5G常用业务应用方式包括：
1. 5GS(5G System)与 DN(Data Network数据网络)互联
5GS在为移动终端用户(User Equipment,UE)提供服务时，通常需要DN网络，如Internet、IMS(IP Media Subsystem)、专用网络等互连来为 UE 提供所需的业务。各式各样的上网、语音、AR/VR、工业控制和无人驾驶等5GS中UPF网元作为DN的接入点。5GS和 DN之间通过5GS定义的N6接口互连，如图4-19所示。
5G Network属于5G范畴，包括若干网络功能实体，如AMF/SMF/PCF/NRF/NSSF等。简洁起见，图中仅标示出了与用户会话密切相关的网络功能实体。
在5GS和 DN基于IPv4/IPv6互连时，从DN来看，UPF可看作是普通路由器。相反从5GS 来看，与UPF通过N6接口互连的设备，通常也是路由器。换言之，5GS和DN之间是一种路由关系。UE访问DN的业务流在它们之间通过双向路由配置实现转发。就5G网络而言，把从UE流向DN的业务流称之为上行(UL,UpLink)业务流；把从DN 流向UE的业务流称为下行(DL,DownLink)业务流。UL业务流通过 UPF上配置的路由转发至 DN;DL业务流通过与 UPF邻近的路由器上配置的路由转发至UPF。
此外，从UE通过5GS接入DN的方式来说，存在两种模式：
（1） 透明模式
在透明模式下，5GS通过UPF的N6接口直接连至运营商特定的IP网络，然后通过防火墙(Firewall)或代理服务器连至DN(即外部IP网络),如Intenet等。UE分配由运营商规划的 网络地址空间的IP地址。UE在向5GS发起会话建立请求时，通常5GS不触发向外部 DN-AAA服务器发起认证过程，如图4-20 所示。
在此模式下，5GS至少为UE提供一个基本ISP服务。对于5GS而言，它只需提供基本的 隧道QoS流服务即可。UE访问某个 Intranet网络时，UE级别的配置仅在UE和 Intranet 网络之间独立完成，这对 5GS 而言是透明的。
（2） 非透明模式
在非透明模式下，5GS可直接接入Intranet/ISP或通过其他IP网络(如Internet)接入 Intranet/ISP。如5GS通过Intemet方式接入Intranet/ISP,通常需要在UPF和 Intranet/ISP之间建立专用隧道来转发UE访问Intranet/ISP的业务。UE被指派属于Intranet/ISP地址空间的IP地址。此地址用于UE业务在UPF、Intranet/ISP 中转发，如图4-21所示。
综上所述，UE通过5GS访问Intranet/ISP的业务服务器，可基于任何网络如 Internet 等来进行，即使不安全也无妨，在UPF和Intranet/ISP之间可基于某种安全协议进行数据通信保护。至于采用何种安全协议，由移动运营商和 Intranet/ISP 提供商之间协商确定。
作为UE会话建立的一部分，5GS中SMF通常通过向外部DN-AAA服务器(如Radius,Diameter服务器)发起对UE进行认证。在对UE认证成功后，方可完成UE会话的建立，之后UE才可访问Intemet/ISP的服务。
2. 5G 网络边缘计算
5G 网络改变以往以设备、业务为中心的导向，倡导以用户为中心的理念。5G网络在为用户提供服务的同时，更注重用户的服务体验QoE(Quality of Experience)。其中 5G 网络边缘计算能力的提供正是为垂直行业赋能、提升用户 QoE的重要举措之一。
5G网络的边缘计算(Mobile Edge Computing,MEC)架构如图4-22所示，支持在靠近终端用户UE的移动网络边缘部署5G UPF网元，结合在移动网络边缘部署边缘计算平台(Mobile Edge Platform,MEP),为垂直行业提供诸如以时间敏感、高带宽为特征的业务就近分流服务。于是，一来为用户提供极佳服务体验，二来降低了移动网络后端处理的压力。
运营商自有应用或第三方应用AF(Application Function)通过5GS 提供的能力开放功能网元NEF(Network Exposure Function),触发 5G 网络为边缘应用动态地生成本地分流策略，由PCF(Policy Charging Function)将这些策略配置给相关SMF,SMF根据终端用户位置信息或用户移动后发生的位置变化信息动态实现UPF(即移动边缘云中部署的UPF)在用户会话中插入或移除，以及对这些 UPF分流规则的动态配置，达到用户访问所需业务的极佳效果。
另外，从业务连续性来说，5G网络可提供SSC模式1(在用户移动过程中用户会话的IP接入点始终保持不变),SSC模式2(用户移动过程中网络触发用户现有会话释放并立即触发新会话建立),SSC模式3(用户移动过程中在释放用户现有会话之前先建立一个新的会话)供业务提供者 ASP(Application Service Provider)或运营商选择。
VI. 软件定义网络
见本书第2章 2.1.2 节的第5小节。
七、 安全架构
I. 安全威胁
目前，组织将更多的业务托管于混合云之上，保护用户数据和业务变得更加困难，本地基础设施和多种公、私有云共同构成的复杂环境，使得用户对混合云安全有了更高的要求。这种普及和应用将会产生两方面的效应：
①各行各业的业务运转几乎完全依赖于计算机、网络和云存储，各种重要数据如政府文件、档案、银行账目、企业业务和个人信息等将全部依托计算机、网络的存储、传输；
②人们对计算机的了解更加全面，有更多的计算机技术被较高层的人非法利用，他们采用种种手段对信息资源进行窃取或攻击。
目前，信息系统可能遭受到的威胁可总 结为以下4个方面
1. 对于信息系统来说，威胁可以是针对物理环境、通信链路、网络系统、操作系统、应用系统以及管理系统等方面。
2. 物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、操作系统引导失败或数据库信息丢失、设备被盗/被毁造成数据丢失或信息泄露；
3. 通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰；
4. 网络安全威胁是指由于互联网的开放性、国际化的特点，人们很容易通过技术手段窃取互联网信息，对网络形成严重的安全威胁；
5. 操作系统安全威胁是指对系统平台中的软件或硬件芯片中植入威胁，如“木马”和“陷阱门”、BIOS的万能密码；
6. 应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，也受到“木马”和“陷阱门”的威胁；
7. 管理系统安全威胁是指由于人员管理上疏忽而引发人为的安全漏洞，如通过人为地拷贝、拍照、抄录等手段盗取计算机信息。
常见的安全威胁有：
（1） 信息泄露
息被泄露或透露给某个非授权的实体。
（2） 破坏信息的完整性
数据被非授权地进行增删、修改或破坏而受到损失。
（3） 拒绝服务
对信息或其他资源的合法访问被无条件地阻止。
（4） 非法访问（非授权访问)
某一资源被某个非授权的人或非授权的方式使用。
（5） 窃听
用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息。例如对通信线路中传输的信号进行搭线监听，或者利用通信设备在工作过程中产生的电磁泄漏截取有用信息等。
（6） 业务流分析
通过对系统进行长期监听，利用统计分析方法对诸如通信频度、通信的 信息流向、通信总量的变化等态势进行研究，从而发现有价值的信息和规律。
（7） 假冒
通过欺骗通信系统(或用户)达到非法用户冒充成为合法用户，或者特权小的用户冒充成为特权大的用户的目的。黑客大多是采用假冒进行攻击。
（8） 旁路控制
攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。例如，攻击者通过各种攻击手段，发现原本应保密但是却又暴露出来的一些系统“特性”。利用这些“特性”,攻击者可以绕过防线守卫者侵入系统的内部。
（9） 授权侵犯
被授权以某一目的使用某一系统或资源的某个人，却将此权限用于其他非授权的目的，也称作“内部攻击”。
（10） 特洛伊木马
软件中含有一个察觉不出的或者无害的程序段，当它被执行时，会破坏 用户的安全。这种应用程序称为特洛伊木马(Trojan Horse)。
（11） 陷阱门
在某个系统或某个部件中设置了“机关”,使得当提供特定的输入数据时，允许违反安全策略。
（12） 抵赖
这是一种来自用户的攻击，例如，否认自己曾经发布过的某条消息或伪造一份对方来信等。
（13） 重放
所截获的某次合法的通信数据备份，出于非法的目的而被重新发送。
（14） 计算机病毒
所谓计算机病毒，是一种在计算机系统运行过程中能够实现传染和侵害的功能程序。一种病毒通常含有两个功能：一种功能是对其他程序产生“感染”;另外一种是引发损坏功能或者是一种植入攻击的能力。
（15） 人员渎职
一个授权人为了钱或利益、或由于粗心而将信息泄露给一个非授权的人。
（16） 媒体废弃
信息被从废弃的磁盘或打印过的存储介质中获得。
（17） 物理侵入
侵入者通过绕过物理控制而获得对系统的访问。
（18） 窃取
重要的安全物品，如令牌或身份卡被盗。
（19） 业务欺骗
某一伪系统或系统部件欺骗合法用户或系统自愿地放弃敏感信息。
II. 定义和范围
安全架构是在架构层面聚焦信息系统安全方向上的一种细分。
安全性体现在信息系统上，通常的系统安全架构、安全技术体系架构和审计架构可组成三道安全防线。
1. 系统安全架构
系统安全架构指构建信息系统安全质量属性的主要组成部分以及它们之间的关系。
系统安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身的安全。
2. 安全技术体系架构
安全技术体系架构指构建安全技术体系的主要组成部分以及它们之间的关系。
安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各部分的安全防御能力。
3. 审计架构
审计架构指独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险。
人们在系统设计时，通常要识别系统可能会遇到的安全威胁，通过对系统面临的安全威胁和实施相应控制措施进行合理的评价，提出有效合理的安全技术，形成提升信息系统安全性的安全方案，是安全架构设计的根本目标。在实际应用中，安全架构设计可以从安全技术的角度考虑，如加密解密、网络安全技术等。
III. 整体架构设计
一、 构建信息安全保障体系框架应包括技术体系、组织机构体系和管理体系等三部分。也就是说，人、管理和技术手段是信息安全架构设计的三大要素，而构建动态的信息与网络安全保障体系框架是实现系统安全的保障。
二、 针对网络安全防护问题，各个国家曾提出了多个网络安全体系模型和架构，比如 PDRR (Protection/Detection/Reaction/Recovery,防护/检测/响应/恢复)模型、P2DR模型(Policy/Protection/Detection/Response,安全策略/防护/检测/响应)。
三、 WPDRRC 模型
WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack)是我国信息安全专家组提出的信息系统安全保障体系建设模型。
WPDRRC 是在 PDRR信息安全体系模型的基础上前后增加了预警和反击功能。
在 PDRR模型中，安全的概念已经从信息安全扩展到了信息保障，信息保障内涵已超出传统的信息安全保密，它是保护(Protect)、检测(Detect)、反应(React)、恢复(Restore)的有机结合。PDRR模型把信息的安全保护作为基础，将保护视为活动过程，用检测手段来发现安全漏洞，及时更正。同时采用应急响应措施对付各种入侵，在系统被入侵后，要采取相应的措施将系统恢复到正常状态，这样才能使信息的安全得到全方位的保障，该模型强调的是自动故障恢复能力。
六个环节包括：预警(W)、保护(P)、检测(D)、响应(R)、恢复(R)和反击(C),它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。
（1） 预警(W)
主要是指利用远程安全评估系统提供的模拟攻击技术，来检查系统可能存在的被利用的薄弱环节，收集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议。
（2） 保护(P)
护通常是通过采用成熟的信息安全技术及方法，来实现网络与信息的安全。
主要内容有加密机制、数字签名机制、访问控制机制、认证机制、信息隐藏和防火墙技术等。
（3） 检测(D)
测是通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。
在这个过程中采用入侵检测、恶意代码过滤等技术，形成动态检测的制度、奖励报告协调机制，提高检测的实时性。
主要内容有入侵检测、系统脆弱性检测、数据完整性检测和攻击性检测等。
（4） 响应(R)
应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。为此需要相应的报警、跟踪和处理系统，其中处理包括了封堵、隔离、报告等能力。
主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。
（5） 恢复(R)
是指当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。
主要内容有容错、冗余、备份、替换、修复和恢复等。
（6） 反击(C)
是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。
三大要素包括：人员、策略和技术。人员是核心，策略是桥梁，技术是保证。
网络安全体系模型经过多年发展，形成了PDP、PPDR、PDRR、MPDRR 和 WPDRRC 等模型，这些模型在信息安全防范方面的功能更加完善
四、 架构设计
信息系统的安全需求是任何单一安全技术都无法解决的，要设计一个信息安全体系架构，应当选择合适的安全体系结构模型。
信息系统安全设计重点考虑两个方面：
1. 系统安全保障体系
安全保障体系是由安全服务、协议层次和系统单元三个层面组成，且每层都涵盖了安全管理的内容。
系统安全保障体系设计工作主要考虑以下几点：
（1） 安全区域策略的确定
根据安全区域的划分，主管部门应制定针对性的安全策略。如定时审计评估、安装入侵检测系统、统一授权、认证等。
（2） 统一配置和管理防病毒系统
主管部门应当建立整体防御策略，以实现统一的配置和管理。网络防病毒的策略应满足全面性、易用性、实时性和可扩展性等方面要求。
（3） 网络与信息安全管理
在网络安全中，除了采用一些技术措施之外，还需加强网络与信息安全管理，制定有关规章制度。在相关管理中，任何的安全保障措施，最终要落实到具体的管理规章制度以及具体的管理人员职责上，并通过管理人员的工作得到实现。
2. 信息安全体系架构
通过对信息系统应用的全面了解，按照安全风险、需求分析结果、安全策略以及网络与信息的安全目标等方面开展安全体系架构的设计工作。
具体在安全控制系统，可以从5个方面开展分析和设计工作
（1） 物理安全
保证计算机信息系统各种设备的物理安全是保障整个网络系统安全的前提。
物理安全是保护计算机网络设备、设施以及其他媒体免受地震、水灾、火灾等环境事故以及人为操作失误或错误及各种计算机犯罪行为导致的破坏过程。
物理安全主要包括：环境安全、设备安全、媒体安全等。
（2） 系统安全
系统安全主要是指对信息系统组成中各个部件的安全要求。
系统安全是系统整体安全的基础。
它主要包括网络结构安全、操作系统安全和应用系统安全等。
（3） 网络安全
网络安全是整个安全解决方案的关键。
它主要包括访问控制、通信保密、入侵检测、网络安全扫描和防病毒等。
（4） 应用安全
应用安全主要是指多个用户使用网络系统时，对共享资源和信息存储操作所带来的安全问题。
它主要包括资源共享和信息存储两个方面。
（5） 安全管理
主要体现在三个方面：制定健全的安全管理体制，构建安全管理平 台，增强人员的安全防范意识。
五、 设计要点
I. 系统安全设计要点
网络结构安全领域重点关注网络拓扑结构是否合理，线路是否冗余，路由是否冗余和防止单点失败等。
操作系统安全重点关注两个方面：①操作系统的安全防范可以采取的措施，如：尽量采用安全性较高的网络操作系统并进行必要的安全配置，关闭一些不常用但存在安全隐患的应用，使用权限进行限制或加强口令的使用等。②通过配备操作系统安全扫描系统对操作系统进行安全性扫描，发现漏洞，及时升级等。
应用系统安全方面重点关注应用服务器，尽量不要开放一些不经常使用的协议及协议端口，如文件服务、电子邮件服务器等。可以关闭服务器上的如HTTP、FTP、Telnet等服务。可以加强登录身份认证，确保用户使用的合法性。
II. 网络安全设计要点
隔离与访问控制要有严格的管制制度，可制定比如《用户授权实施细则》《口令及账户管理规范》《权限管理制定》等一系列管理办法。
通过配备防火墙实现网络安全中最基本、最经济、最有效的安全措施。通过防火墙严格的安全策略实现内外网络或内部网络不同信任域之间的隔离与访问控制，防火墙可以实现单向或双向控制，并对一些高层协议实现较细粒度的访问控制。
入侵检测需要根据已有的、最新的攻击手段的信息代码对进出网段的所有操作行为进行实时监控、记录，并按制定的策略实施响应(阻断、报警、发送E-mail)。从而防止针对网络的攻击与犯罪行为。入侵检测系统一般包括控制台和探测器(网络引擎),控制台用作制定及管理所有探测器(网络引擎),网络引擎用作监听进出网络的访问行为，根据控制台的指令执行相应行为。
病毒防护是网络安全的必要手段，由于在网络环境下，计算机病毒有不可估量的威胁性和破坏力。网络系统中使用的操作系统(如Windows系统),容易感染病毒，因此计算机病毒的防范也是网络安全建设中应该考虑的重要环节之一，反病毒技术包括预防病毒、检测病毒和杀毒三种。
III. 应用安全设计要点
资源共享要严格控制内部员工对网络共享资源的使用，在内部子网中一般不要轻易开放共享目录，否则会因为疏忽而在员工间交换信息时泄露重要信息。对有经常交换信息需求的用户，在共享时也必须加上必要的口令认证机制，即只有通过口令的认证才能允许访问数据。
信息存储是指对于涉及秘密信息的用户主机，使用者在应用过程中应该做到尽量少开放一些不常用的网络服务。对数据服务器中的数据库做安全备份。通过网络备份系统可以对数据库进行远程备份存储。
IV. 安全管理设计要点
制定健全安全管理体制将是网络安全得以实现的重要保证，可以根据自身的实际情况制定如安全操作流程、安全事故的奖罚制度以及任命安全管理人员全权负责监督和指导。
构建安全管理平台将会降低许多因为无意的人为因素而造成的风险。构建安全管理平台可从技术上进行防护，如组成安全管理子网、安装集中统一的安全管理软件、网络设备管理系统以及网络安全设备统一管理软件等，通过安全管理平台实现全网的安全管理。
应该经常对单位员工进行网络安全防范意识的培训，全面提高员工的整体安全方法意识。
六、 架构示例
这里的安全控制系统是指能提供一种高度可靠的安全保护手段的系统，可以最大限度地避免相关设备的不安全状态，防止恶性事故的发生或在事故发生后尽可能地减少损失，保护生产装置及最重要的人身安全。
该架构采用了传统的层次化结构，分为数据层、功能层和展现层。数据层主要对组织数据进行统一管理，按数据的不同安全特性进行存储、隔离与保护等。功能层是系统安全防范的主要核心功能，包括可用性监控、服务支持和安全性监控。可用性监控主要实现网络安全、系统安全和应用安全中的监控能力；服务支持中的业务过程包含了安全管理设计，实现安全管理环境下的运维管理的大多数功能；安全性监控主要针对系统中发现的任何不安全现象进行相关处理，涵盖了威胁追溯、安全域审计评估、授权、认证等，以及风险分析与评估等。展现层主要完成包含安全架构的使用、维护、决策等在内的用户各种类型应用功能实现。
IV. 网络安全架构设计
i. 建立信息系统安全体系的目的，就是将普遍性安全原理与信息系统的实际相结合，形成满足信息系统安全需求的安全体系结构，网络安全体系是信息系统体系的核心之一。
ii. 系统安全体系
1. OSI 安全架构
OSI(Open System Interconnection/Reference Mode,OSI/RM)是由国际化标准组织制定的开放式通信系统互联模型(ISO 7498-2),国家标准GB/T9387.2《信息处理系统 开放系统互联基本参考模型 第2部分：安全体系结构》等同于ISO 7498-2。
OSI目的在于保证开放系统进程与进程之间远距离安全交换信息。这些标准在参考模型的框架内建立起一些指导原则与约束条件，从而提供了解决开放互联系统中安全问题的一致性方法。
OSI定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。
最适合配置安全服务的是在物理层、网络层、传输层及应用层上，其他层都不宜配置安全服务。
OSI开放系统互联安全体系的5类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。
OSI定义分层多点安全技术体系架构，也称为深度防御安全技术体系架构，它通过以下三种方式将防御能力分布至整个信息系统中。
（1） 多点技术防御
1||| 网络和基础设施：
为了确保可用性，局域网和广域网需要进行保护以抵抗各种攻击，如拒绝服务攻击等。为了确保机密性和完整性，需要保护在这些网络上传送的信息以及流量的特征以防止非故意的泄露。
2||| 边界：
为了抵御主动的网络攻击，边界需要提供更强的边界防御，例如流量过滤和控制以及入侵检测。
3||| 计算环境：
为了抵御内部、近距离的分布攻击，主机和工作站需要提供足够的访问控制。
（2） 分层技术防御
为了减少这些攻击成功的可能性和对成功攻击的可承担性，每种机制应代表一种唯一的障碍，并同时包括保护和检测方法。
例如，在外部和内部边界同时使用嵌套的防火墙并配合以入侵检测就是分层技术防御的一个实例。
（3） 支撑性基础设施
1||| 公钥基础设施
提供一种通用的联合处理方式，以便安全地创建、分发和管理公钥证书和传统的对称密钥，使它们能够为网络、边界和计算环境提供安全服务。这些服务能够对发送者和接收者的完整性进行可靠验证，并可以避免在未获授权的情况下泄露和更改信息。公钥基础设施必须支持受控的互操作性，并与各用户团体所建立的安全策略保持一致。
2||| 检测和响应基础设施
能够迅速检测并响应入侵行为。它也提供便于结合其他相关事件观察某个事件的“汇总”功能。另外，它也允许分析员识别潜在的行为模式或新的发展趋势。
信息系统的安全保障不仅仅依赖于技术，还需要非技术防御手段。一个可接受级别的信息保障依赖于人员、管理、技术和过程的综合。
2. 认证框架
鉴别(Authentication)的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。
鉴别提供了实体声称其身份的保证，只有在主体和验证者的关系背景下，鉴别才是有意义的。
鉴别有两个重要的关系背景：
①实体由申请者来代表，申请者与验证者之间存在着特定的通信关系(如实体鉴别);
②实体为验证者提供数据项来源。
鉴别的方式主要基于以下5种
1||| 已知的，如一个秘密的口令。
2||| 拥有的，如IC卡、令牌等。
3||| 不改变的特性，如生物特征。
4||| 相信可靠的第三方建立的鉴别(递推)。
5||| 环境(如主机地址等)。
鉴别信息是指申请者要求鉴别到鉴别过程结束所生成、使用和交换的信息。
鉴别信息的类型有交换鉴别信息、申请鉴别信息和验证鉴别信息。
在某些情况下，为了产生交换鉴别信息，申请者需要与可信第三方进行交互。类似地，为了验证交换鉴别信息，验证者也需要同可信第三方进行交互。在这种情况下，可信第三方持有相关实体的验证 AI,也可能使用可信第三方来传递交换鉴别信息，实体也可能需要持有鉴别可信第三方中所使用的鉴别信息。
鉴别服务分为以下阶段：
1||| 安装阶段
定义申请鉴别信息和验证鉴别信息。
2||| 修改鉴别信息阶段
实体或管理者申请鉴别信息和验证鉴别信息变更(如修改口令)。
3||| 分发阶段
为了验证交换鉴别信息，把验证鉴别信息分发到各实体(如申请者或验 证者)以供使用。
4||| 获取阶段
申请者或验证者可得到为鉴别实例生成特定交换鉴别信息所需的信息， 通过与可信第三方进行交互或鉴别实体间的信息交换可得到交换鉴别信息。
5||| 传送阶段
在申请者与验证者之间传送交换鉴别信息。
6||| 验证阶段
用验证鉴别信息核对交换鉴别信息。
7||| 停活阶段
将建立一种状态，使得以前能被鉴别的实体暂时不能被鉴别。
8||| 重新激活阶段
使在停活阶段建立的状态将被终止。
9||| 取消安装阶段
实体从实体集合中被拆除。
3. 访问控制框架
访问控制(Access Control)决定开放系统环境中允许使用哪些资源，在什么地方适合阻止未授权访问的过程。
在访问控制实例中，访问可以是对一个系统(即对一个系统通信部分的一个实体)或对一个系统内部进行的。
图4-25和图4-26 说明了访问控制的基本功能。
ACI(访问控制信息)是用于访问控制目的的任何信息，其中包括上下文信息。ADI(访问控制判决信息)是在做出一个特定的访问控制判决时可供ADF使用的部分(或全部)ACI。
ADF(访问控制判决功能)是一种特定功能，它通过对访问请求、ADI以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。AEF(访问控制实施功能)确保只有对目标允许的访问才由发起者执行。
涉及访问控制的有发起者、AEF、ADF和目标。发起者代表访问或试图访问目标的人和基于计算机的实体。目标代表被试图访问或由发起者访问的，基于计算机或通信的实体。例如，目标可能是OSI实体、文件或者系统。访问请求代表构成试图访问部分的操作和操作数。
当发起者请求对目标进行特殊访问时，AEF就通知ADF需要一个判决来做出决定。为了作出判决，给ADF提供了访问请求(作为判决请求的一部分)和下列几种访问控制判决信息(ADI)。
（1） 发起者ADI(ADI由绑定到发起者的ACI导出);
（2） 目标ADI(ADI由绑定到目标的ACI导出);
（3） 访问请求ADI(ADI由绑定到访问请求的ACI导出)。
ADF的其他输入是访问控制策略规则(来自ADF的安全域权威机构)和用于解释ADI或策略的必要上下文信息。上下文信息包括发起者的位置、访问时间或使用中的特殊通信路径等。基于这些输入，以及可能还有以前判决中保留下来的ADI信息，ADF可以做出允许或禁止发起者试图对目标进行访问的判决。该判决传递给AEF,然后AEF允许将访问请求传给目标或采取其他合适的行动。
在许多情况下，由发起者对目标的逐次访问请求是相关的。应用中的一个典型例子是在打开与同层目标的连接应用进程后，试图用相同(保留)的ADI执行几个访问，对一些随后通过连接进行通信的访问请求，可能需要给 ADF提供附加的ADI以允许访问请求，在另一些情况下，安全策略可能要求对一个或多个发起者与一个或多个目标之间的某种相关访问请求进行限制，这时，ADF可能使用与多个发起者和目标有关的先前判决中所保留的ADI来对特殊访问请求作出判决。
如果得到AEF的允许，访问请求只涉及发起者与目标的单一交互。尽管发起者和目标之间的一些访问请求是完全与其他访问请求无关的，但常常是两个实体进入一个相关的访问请求集合中，如质询应答模式。在这种情况下，实体根据需要同时或交替地变更发起者和目标角色，可以由分离的AEF组件、ADF组件和访问控制策略对每一个访问请求执行访问控制功能。
4. 机密性框架
机密性(Confidentiality)服务的目的是确保信息仅仅是对被授权者可用。由于信息是通过数据表示的，而数据可能导致关系的变化(如文件操作可能导致目录改变或可用存储区域的改变),因此信息能通过许多不同的方式从数据中导出。例如，通过理解数据的含义(如数据的值)导出；通过使用数据相关的属性(如存在性、创建的数据、数据大小、最后一次更新的日期等)进行导出：通过研究数据的上下文关系，即通过那些与之相关的其他数据实体导出；通过观察数据表达式的动态变化导出。
信息的保护是确保数据被限制于授权者获得，或通过特定方式表示数据来获得，这种保护方式的语义是，数据只对那些拥有某种关键信息的人才是可访问的。有效的机密性保护，要求必要的控制信息(如密钥和RCI等)是受到保护的，这种保护机制和用来保护数据的机制是不同的(如密钥可以通过物理手段保护等)。
在机密性框架中用到被保护的环境和被交叠保护的环境两个概念。在被保护环境中的数据，可通过使用特别的安全机制(或多个机制)保护，在一个被保护环境中的所有数据以类似方法受到保护。当两个或更多的环境交叠的时候，交叠中的数据能被多重保护。可以推断，从一个环境移到另一个环境的数据的连续保护必然涉及交叠保护环境。
数据的机密性可以依赖于所驻留和传输的媒体，因此，存储数据的机密性能通过使用隐藏数据语义(如加密)或将数据分片的机制来保证。数据在传输中的机密性能通过禁止访问的机制，通过隐藏数据语义的机制或通过分散数据的机制得以保证(如跳频等)。这些机制类型能被单独使用或者组合使用。
机制类型
（1） 通过禁止访问提供机密性
（2） 通过加密提供机密性
加密机制分为基于对称的加密机制和 基于非对称加密的机密机制。
5. 完整性框架
完整性(Integrity)框架的目的是通过阻止威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性。所谓完整性，就是数据不以未经授权方式进行改变或损毁的特征。
完整性服务有几种分类方式：
1||| 根据防范的违规分类，违规操作分为未授权的数据修改、未授权的数据创建、未授权的数据删除、未授权的数据插入和未授权的数据重放。
2||| 依据提供的保护方法分为阻止完整性损坏和检测完整性损坏。
3||| 依据是否支持恢复机制，分为具有恢复机制的和不具有恢复机制的。
由于保护数据的能力与正在使用的媒体有关，对于不同的媒体，数据完整性保护机制是有区别的，可概括为以下两种情况。
1||| 阻止对媒体访问的机制。包括物理隔离的不受干扰的信道、路由控制、访问控制。
2||| 用以探测对数据或数据项序列的非授权修改的机制。未授权修改包括未授权数据创建、数据删除以及数据重放。而相应的完整性机制包括密封、数字签名、数据重复(作为对抗其他类型违规的手段)、与密码变换相结合的数字指纹和消息序列号。
按照保护强度，完整性机制可分为：
1||| 不做保护；
2||| 对修改和创建的探测；
3||| 对修改、创建、删除和重复的探测；
4||| 对修改和创建的探测并带恢复功能；
5||| 对修改、创建、删除和重复的探测并带恢复功能。
6. 抗抵赖性框架
抗抵赖(Non-repudiation)服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。框架所描述的抗抵赖服务的目的是提供有关特定事件或行为的证据。事件或行为本身以外的其他实体可以请求抗抵赖服务。抗抵赖服务可以保护的行为实例有发送X.400 消息、在数据库中插入记录、请求远程操作等。
当涉及消息内容的抗抵赖服务时，为提供原发证明，必须确认数据原发者身份和数据完整性。为提供递交证明，必须确认接收者身份和数据完整性。在某些情况下，还可能需要涉及上下文信息(如日期、时间、原发者/接收者的地点等)的证据。抗抵赖服务提供下列可在试图抵赖的事件中使用的设备：证据生成、证据记录、验证生成的证据、证据的恢复和重验。纠纷可以在纠纷两方之间直接通过检查证据解决，也可能不得不通过仲裁者解决，由仲裁者评估并确定是否发生过有纠纷的行为或事件。
抗抵赖由4个独立的阶段组成，分别为：
1||| 证据生成
在这个阶段中，证据生成请求者请求证据生成者为事件或行为生成证据。卷入事件或行为中的实体称为证据实体，其卷入关系由证据建立。根据抗抵赖服务的类型，证据可由证据实体，或与可信第三方的服务一起生成，或者单独由可信第三方生成。
2||| 证据传输、存储及恢复
在这个阶段，证据在实体间传输或从存储器取出来或传到存储器。
3||| 证据验证
在这个阶段，证据在证据使用者的请求下被证据验证者验证。本阶段的目的是在出现纠纷的事件中，让证据使用者确信被提供的证据确实是充分的。可信第三方服务也可参与，以提供验证该证据的信息。
4||| 解决纠纷
在解决纠纷阶段，仲裁者有解决双方纠纷的责任。
V. 数据库系统安全设计
i. 数据库完整性是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过数据库管理系统(Database Management System,DBMS)或应用程序来实现，基于DBMS的完整性约束作为模式的一部分存入数据库中。
ii. 数据库完整性设计原则
1. 根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。
2. 实体完整性约束和引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定时间和空间来换取系统的易用性是值得的。
3. 要慎用目前主流DBMS都支持的触发器功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易产生错误，非用不可时，最好使用 Before 型语句级触发器。
4. 在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆。如果使用CASE工具，一般有默认的规则，可在此基础上修改使用。
5. 要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。
6. 要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。数据库设计人员不仅负责基于DBMS的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。
7. 应采用合适的CASE工具来降低数据库设计各阶段的工作量。好的CASE工具能够支持整个数据库的生命周期，这将使数据库设计人员的工作效率得到很大提高，同时也容易与用户沟通。
iii. 数据库完整性的作用
数据库完整性约束能够防止合法用户使用数据库时，向数据库中添加不合语义的数据内容。
利用基于DBMS的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。同时，由于DBMS的完整性控制机制是集中管理的，因此比应用程序更容易实现数据库的完整性。
合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。例如装载大量数据时，只要在装载之前临时使基于DBMS的数据库完整性约束失效，此后再使其生效，就能保证既不影响数据装载的效率又能保证数据库的完整性。
在应用软件的功能测试中，完善数据库完整性有助于尽早发现应用软件的错误。
数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。动态约束通常由应用软件来实现。不同DBMS支持的数据库完整性基本相同，某常用关系型数据库系统支持的基于DBMS的完整性约束，如表 4-3 所示。
iv. 数据库完整性设计示例
一个好的数据库完整性设计，首先需要在需求分析阶段确定要通过数据库完整性约束实现的业务规则。然后在充分了解特定DBMS提供的完整性控制机制的基础上，依据整个系统的体系结构和性能要求，遵照数据库设计方法和应用软件设计方法，合理选择每个业务规则的实现方式。最后，认真测试，排除隐含的约束冲突和性能问题。
基于DBMS的数据库完整性设计大体分为
（1） 需求分析阶段
（2） 概念结构设计阶段
概念结构设计阶段是将依据需求分析的结果转换成一个独立于具体 DBMS的概念模型，即实体关系图(Entity-Relationship Diagram,ERD)。
（3） 逻辑结构设计阶段
此阶段就是将概念结构转换为某个 DBMS所支持的数据模型，并对其进行优化，包括对关系模型的规范化等。
VI. 安全架构设计案例分析
i. 以某基于混合云的工业安全架构设计为例。
ii. 混合云架构往往被大型企业所接受。混合云融合了公有云和私有云，是近年来云计算的主要模式和发展方向。
iii. 大型企业采用混合云技术的安全生产管理系统的架构
iv. 在设计基于混合云的安全生产管理系统中，需要重点考虑5个方面的安全问题。
（1） 设备安全
（2） 网络安全
（3） 控制安全
（4） 应用安全
（5） 数据安全
八、 云原生架构
I. 概要
“云原生”Cloud Native 拆开来看，Cloud 就是指其应用软件和服务是在云端而非传统意义上的数据中心。Native 代表应用软件从一开始就是基于云环境，专门为云端特性而设计，可充分利用和发挥云环境的弹性与分布式优势，最大化释放云环境生产力。
II. 发展概述
i. “瀑布式流程”开发模式，一方面造成了开发上下游的信息 不对称，另一方面拉长了开发周期和调整难度。
ii. 敏捷开发只是解决了软件开发的效率和版本更新的速度，还没有和运 维管理等有效打通。
iii. DevOps可以看作是开发、技术运营和质量保障三者的交集，促进他们之间的沟通、协作与整合，从而提高开发周期和效率。
iv. 云原生的容器、微服务等技术正是为DevOps提供了很好的前提条件，保证IT软件开发实现DevOps开发和持续交付的关键应用。换句话说，能够实现 DevOps和持续交付，已经成为云原生技术价值不可分割的内涵部分。
v. 云原生与商业场景的深度融合，不仅为各行业注入了发展与创新的新动能，也促使云原生技术更快发展、生态更加成熟，主要表现为以下几点。
1. 从为组织带来的价值来看，云原生架构通过对多元算力的支持，满足不同应用场景的个性化算力需求，并基于软硬协同架构，为应用提供极致性能的云原生算力；基于多云治理和边云协同，打造高效、高可靠的分布式泛在计算平台，并构建包括容器、裸机、虚机、函数等多种形态的统一计算资源；以“应用”为中心打造高效的资源调度和管理平台，为企业提供一键式部署、可感知应用的智能化调度，以及全方位监控与运维能力。
2. 通过最新的DevSecOps 应用开发模式，实现了应用的敏捷开发，提升业务应用的迭代速度，高效响应用户需求，并保证全流程安全。对于服务的集成提供侵入和非侵入两种模式辅助企业应用架构升级，同时实现新老应用的有机协同，立而不破。
3. 帮助企业管理好数据，快速构建数据运营能力，实现数据的资产化沉淀和价值挖掘，并借助一系列Al技术，再次赋能给企业应用，结合数据和AI的能力帮助企业实现业务的智能升级。
4. 结合云平台全方位组织级安全服务和安全合规能力，保障组织应用在云上安全构建，业务安全运行。
III. 架构定义
i. 从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
ii. 云原生技术部分依赖于传统云计算的3层概念，即基础设施即服务(laaS)、平台即服务(PaaS)和软件即服务(SaaS)。
iii. 云原生的代码通常包括三部分：
1. 业务代码
指实现业务逻辑的代码
2. 三方软件
是业务代码中依赖的所有三方库，包括业务库和 基础库
3. 处理非功能特性的代码
指实现高可用、安全、可观测性等非功能性能力的代码。
只有业务代码是核心，是给业务真正带来价值的，另外两个部分都只算附属物
iv. 代码结构发生巨大变化
在云环境中，“如何获取存储”变成了若干服务，包括对象存储服务、块存储服务和文件存储服务。云不仅改变了开发人员获得这些存储能力的界面，还在于云服务解决了分布式场景中的各种挑战，包括高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等，应用的开发人员不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题，也不用处理当业务峰值到来时如何对存储节点进行扩容的问题，而应用的运维人员不用在发现“零日漏洞(zeroday)”安全问题时紧急对三方存储软件进行升级。
v. 非功能性特性大量委托
i. 任何应用都提供两类特性：
1. 功能性特性
真正为业务带来价值的代码，比如建立客户资料、处理订单、支付等。即使是一些通用的业务功能特性，比如组织管理、业务字典管理、搜索等也是紧贴业务需求的。
2. 非功能性特性
没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
ii. 云计算解决方案
1. 虚拟机
当虚拟机检测到底层硬件发生异常时，自动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具备对外服务的能力，应用本身及其使用用户对整个迁移过程都不会有任何感知。
2. 容器
容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产流量的切换等操作，整个过程自动完成而无须运维人员干预。
3. 云服务
如果应用把“有状态”部分都交给了云服务(如缓存、数据库、对象存储等),加上全局对象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的“无状态”应用，高可用故障带来的业务中断会降至分 钟级；如果应用是N:M(N台客户端中的每一台都可以访问到M台服务器)的对等架构模式，那么结合负载均衡产品可获得很强的高可用能力。
vi. 高度自动化的软件交付
容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。
对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够“理解”目标环境、交付内容、配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。
IV. 基本原则
1. 服务化
当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务(MiniService)架构等，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和提升系统稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。
2. 弹性
弹性则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让组织不用关注额外软硬件资源的成本支出(包括闲置成本),降低了组织的IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为既有软硬件资源储备不足而“说不”,保障了组织收益。
3. 可观测
可观测性与监控、业务探活、应用性能检测(Application Performance Monitor,APM)等系统提供的能力不同，可观测性是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。
4. 韧性
韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件漏洞(bug)、黑客攻击等对业务不可用带来致命影响的因素。
韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间(Mean Time Between Failure,MTBF)。从架构设计上，韧性包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ(Availability Zones,可用区)内的高可用、单元化、跨 region(区域)容灾、异地多活容灾等。
5. 所有过程自动化
一方面标准化组织内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
6. 零信任
零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”,其本质诉求是以身份为中心进行访问控制。
零信任第一个核心问题就是身份(Identity),赋予不同的实体不同的身份，解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维等微服务场景下，身份及其相关策略不仅是安全的基础，更是众多(包括资源、服务、环境等)隔离机制的基础；在用户访问组织内部应用的场景下，身份及其相关策略提供了即时的接入服务。
7. 架构持续演进
云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度),但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险，以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。
V. 常用架构模式
1. 服务化架构
服务化架构是新时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如IDL)定义彼此业务关系，以标准协议(HTTP、gRPC等)确保彼此的互联互通，结合领域模型驱动(Domain Driven Design,DDD)、测试驱动开发(Test Driven Development,TDD)、容器化部署提升每个接口的代码质量和迭代速度。
服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。
2. Mesh化架构
Mesh(网格)化架构是把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离，让中间件的软件开发工具包(Software Development Kit,SDK)与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
分离后在业务进程中只保留很“薄”的Client部分，Client 通常很少变化，只负责与Mesh 进程通信，原来需要在 SDK中处理的流量控制、安全等逻辑由Mesh进程完成。
实施 Mesh 化架构后，大量分布式架构模式(如熔断、限流、降级、重试、反压、隔仓等)都由Mesh进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性(比如零信任架构能力等),按流量进行动态环境隔离，基于流量做冒烟/回归测试等
3. Serverless
Serverless(无服务器)将“部署”这个动作从运维中“收走”,使开发者不用关心应用运 行地点、操作系统、网络配置、CPU性能等。
Serverless 并非适用任何类型的应用，因此架构决策者需要关心应用类型是否适合于 Serverless 运算。如果应用是有状态的，由于 Serverless 的调度不会帮助应用做状态同步，因此云在进行调度时可能导致上下文丢失；如果应用是长时间后台运行的密集型计算任务，会无法发挥 Serverless 的优势；如果应用涉及频繁的外部I/O(包括网络或者存储，以及服务间调用等),也因为繁重的I/O负担、时延大而不适合。Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
4. 存储计算分离
分布式环境中的CAP(一致性：Consistency;可用性：Availability;分区容错性：Partition tolerance)困难主要是针对有状态应用，因为无状态应用不存在C(一致性)这个维度，因此可以获得很好的A(可用性)和P(分区容错性),因而获得更好的弹性。在云环境中，推荐把各类暂态数据(如 session)、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，这时可以考虑通过采用时间日志+快照(或检查点)的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。
5. 分布式事务
传统采用XA(eXtended Architecture)模式，虽然具备很强的一致性，但是性能差。
基于消息的最终一致性通常有很高的性能，但是通用性有限。
TCC(Try-Confirm-Cancel)模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高。
SAGA模式(指允许建立一致的分布式应用程序的故障管理模式)与TCC模式的优缺点类似但没有Try这个阶段，而是每个正向事务都对应一个补偿事务，也使开发维护成本高。
开源项目SEATA的 AT模式非常高性能，无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。
6. 可观测
可观测架构包括 Logging、Tracing、Metrics三个方面，Logging提供多个级别(verbose/debug/warning/error/fatal)的详细信息跟踪，由应用开发者主动提供；Tracing 提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics 则提供对系统量化的多维度度量。
架构决策者需要选择合适的、支持可观测的开源框架(比如Open Tracing、Open Telemetry等),并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等),规划这些可观测数据在哪些服务和技术组件中传播，利用日志和Tracing信息中的 spanid/traceid,确保进行分布式链路分析时有足够的信息进行快速关联分析。
由于建立可观测性的主要目标是对服务SLO(Service Level Objective)进行度量，从而优化 SLA(Service Level Agreement,服务水平协议),因此架构设计上需要为各个组件定义清晰的 SLO,包括并发度、耗时、可用时长、容量等。
7. 事件驱动
事件驱动架构(Event Driven Architecture,EDA)本质上是一种应用/组件间的集成架构模式。事件和传统的消息不同，事件具有Schema,所以可以校验Event的有效性，同时 EDA具备 QoS保障机制，也能够对事件处理失败进行响应。
事件驱动架构不仅用于(微)服务解耦，还可应用于下面的场景中。
1||| 增强服务韧性
由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被上游感知，自然也就不会对上游带来影响。
2||| CQRS(Command Query Responsibility Segregation,命令查询的责任分离)
把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的API接口；结合 EDA中的 Event Sourcing机制可以用于维护数据变更的一致性，当需要重新构建服务状态时，把EDA中的事件重新“播放”一遍即可。
3||| 数据变化通知
在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。
4||| 构建开放式接口
在EDA下，事件的提供者并不用关心有哪些订阅者，不像服务调用——数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。
5||| 事件流处理
应用于大量事件流(而非离散事件)的数据分析场景，典型应用是基于Kafka的日志处理。
6||| 基于事件触发的响应
在IoT时代大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返回，天然适合用 EDA 来构建数据处理应用。
VI. 云原生案例
i. 某快递公司作为发展最为迅猛的物流组织之一，一直积极探索技术创新赋能商业增长之路，以期达到降本提效的目的。目前，该公司日订单处理量已达千万量级，亿级别物流轨迹处理量，每天产生数据已达到TB级别，使用1300+个计算结点来实时处理业务。过往该公司的核心业务应用运行在IDC机房，原有IDC系统帮助该公司安稳度过早期业务快速发展期。但伴随着业务体量指数级增长，业务形式愈发多元化。原有系统暴露出不少问题，传统IOE架构、各系统架构的不规范、稳定性、研发效率都限制了业务高速发展的可能。软件交付周期过长，大促保障对资源的特殊要求难实现、系统稳定性难以保障等业务问题逐渐暴露。在与某云服务商进行多次需求沟通与技术验证后，该公司最终确定云原生技术和架构实现核心业务搬迁上云。
ii. 解决方案
1. 引入云原生数据库
通过引入OLTP跟OLAP型数据库，将在线数据与离线分析逻辑拆分到两种数据库中，改变此前完全依赖Oracle数据库的现状。满足在处理历史数据查询场景下 Oracle 数据库所支持实际业务需求的不足。
2. 应用容器化
伴随着容器化技术的引进，通过应用容器化有效解决了环境不一致的问题，确保应用在开发、测试、生产环境的一致性。与虚拟机相比，容器化提供了效率与速度的双重提升，让应用更适合微服务场景，有效提升产研效率。
3. 微服务改造
由于过往很多业务是基于Oracle的存储过程及触发器完成的，系统间的服务依赖也需要Oracle数据库OGG(Oracle Golden Gate)同步完成。这样带来的问题就是系统维护难度高且稳定性差。通过引入Kubernetes的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个系统更易于维护。
iii. 架构确立
综合考虑某快递公司实际业务需求与技术特征，该企业确定的上云架构如图4-3
（1） 基础设施
全部计算资源取自某云服务商上的裸金属服务器。相较于一般云服务器(ECS),Kubermetes搭配服务器能够获得更优性能及更合理的资源利用率。且云上资源按需取量，对于拥有促活动等短期大流量业务场景的某公司而言极为重要。相较于线下自建机房、常备机器云上资源随取随用。在促活动结束后，云上资源使用完毕后即可释放，管理与采购成本更低。
（2） 流量接入
云服务商提供两套流量接入，一套是面向公网请求，另外一套是服务内部调用。域名解析采用云 DNS 及 PrivateZone。借助 Kubernetes 的 Ingress 能力实现统一的域名转发，以节省公网SLB 的数量，提高运维管理效率。
（3） 平台层
基于Kubernetes 打造的云原生 PaaS 平台优势明显突出，主要包括：
1||| 打通DevOps闭环，统一测试、集成、预发、生产环境；
2||| 天生资源隔离，机器资源利用率高；
3||| 流量接入可实现精细化管理；
4||| 集成了日志、链路诊断、Metrics平台；
5||| 统一APIServer接口和扩展，支持多云及混合云部署。
（4） 应用服务层
每个应用都在 Kubernetes上面创建单独的一个 Namespace,应用和应用之间实现资源隔离。通过定义各个应用的配置YAML模板，当应用在部署时直接编辑其中的镜像版本即可快速完成版本升级，当需要回滚时直接在本地启动历史版本的镜像快速回滚。
（5） 运维管理
线上Kubernetes集群采用云服务商托管版容器服务，免去了运维Master结点的工作，只需要制定 Worker结点上线及下线流程即可。同时业务系统均通过阿里云的 PaaS平台完成业务日志搜索，按照业务需求投交扩容任务，系统自动完成扩容操作，降低了直接操作 Kubernetes 集群带来的业务风险。
iv. 应用效益
1. 成本
云产品都免运维自行托管在云端，有效节省人工运维成本，让企业更专注于核心业务。
2. 稳定性
云上产品提供至少5个9(99.999%）以上的 SLA 服务确保系统稳定，而自建系统稳定性调高很多。在数据安全方面云上数据可以轻松实现异地备份，云服务商数据存储体系下的归档存储产品具备高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。
3. 效率
借助与云产品深度集成，研发人员可以完成一站式研发、运维工作。从业务需求立项到拉取分支开发，再到测试环境功能回归验证，最终部署到预发验证及上线，整个持续集成流程耗时可缩短至分钟级。排查问题方面，研发人员直接选择所负责的应用，并通过集成的SLS日志控制台快速检索程序的异常日志进行问题定位，免去了登录机器查日志的麻烦。
4. 赋能业务
云服务商提供超过300余种的云上组件，组件涵盖计算、AI、大数据、IoT 等诸多领域。研发人员开箱即用，有效节省业务创新带来的技术成本。