系统架构设计

系统架构（System Architecture）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。架构设计优劣决定了系统的健壮性和生命周期的长短。

解决相对复杂的需求分析问题；

解决非功能属性在系统占据重要位置的设计问题；

解决生命周期长、扩展性需求高的系统整体结构问题；

解决系统基于组件需要的集成问题；

解决业务流程再造难的问题。

基础研究阶段（1968-1994）

概念体系和核心技术形成阶段（1999-2000年）

理论体系完善与发展阶段（1996年至今）

普及应用阶段（2000年至今）

分层架构

事件驱动架构

微核架构（插件架构）

微微服架构

云架构

结构模型

框架模型

动态模型

过程模型

架构设计师是负责系统架构的人、团队或组织。
架构设计师是系统或产品线的设计责任人，是一个负责理解和管理并最终确认和评估非功能性系统需求(如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等)，给出开发规范，搭建系统实现的核心构架，对整个软件架构、关键构件和接口进行总体设计并澄清关键技术细节的高级技术人员。

架构设计师的职责应该是技术领导，这意味着架构设计师除了拥
有专门技能外，还必须拥有领导能力。
工作职责是在软件项目开发过程中，将客户的需求转换为规范的
开发计划，并制定这个项目的总体架构，指导整个开发团队完成
这个计划。主导系统全局分析设计与实施、负责软件架构和关键
技术决策。架构设计师应能迅速抓住问题要害，并做出合理的关
键决定，具备战略性和前瞻性思维能力，善于把握全局，能够在
更高抽象级别上进行思考。

(1)领导与协调整个项目中的技术活动(分析、设计和实施等)
(2)推动主要的技术决策并最终表达为系统架构。
(3)确定系统架构，并促使其架构设计的文档化，这里的文档化应
包括需求、设计、实施和部署等"视图"。
从技术角度看，架构设计师的职责就是抽象设计、非功能设计和
关键技术设计等三大任务

系统软件包括：操作系统、程序设计语言翻译系统、
中间件、数据库管理系统和网络软件等。

应用软件是指为某类应用需要或解决某个特定问题而设计的软
件，如图形图像处理软件、财务软件等。

(1)消息中间件
(2)事务处理(交易)中间件
(3)数据存取管理中间件
(4)Web服务器中间件
(5)安全中间件
(6)跨平台和架构的中间件
(7)专用中间件
(8)网络中间件

性能指标

非性能指标

C代表信道容量，单位是b/s
B代表信号带宽，单位是Hz
S代表信号平均功率，单位是W
N代表噪声平均功率，单位是W
S/N代表信噪比，单位是dB(分贝)

开放系统互连模型OSI

TCP/IP协议集

基本构造块

运用于整个语言的公用机制

图

类图

对象图

用例图

序列图

通信图

状态图

活动图

构件图

部署图

组合结构图

包图

交互概览图

计时图

1)探索性研究阶段
2)概念阶段
3)开发阶段
4)生产阶段
5)使用阶段
6)保障阶段
7)退役阶段

1)计划驱动方法
2)渐进迭代式开发
3)精益开发
4)敏捷开发

概念的产生过程

需求分析过程

总体规划

系统分析

系统设计

系统实施

系统验收

改正性维护

适应性维护

完善性维护

预防性维护

描述问题状态的综合数据库

存放启发式经验知识的知识库

对知识库的知识进行推理的推理机

 单机系统，包括:文字处理、日程安排、文档管理、电子报表、数据处理。
 多机系统，包括:电子会议、电子邮件、语音处理、图形图像处理，联机情报检索。

对信息流的控制管理，包括信息的收集、加工、传递、交流、存取、提供、分析、判断、应用和反馈，中层管理人员完成。

根据预定目标做出行动决定，由企业高层及其“智囊团”(专业人员) 来完成。

(1) G2G (政府对政府)   
(2) G2B (政府对企业)
(3) G2C (政府对公民)
(4) G2E (政府对公务员)

机密性

完整性

可用性

可控性

可审查性

设备安全

数据安全

内容安全

行为安全

一是引进自动分配密钥机制，以提高系统的效率;

二是尽可能减少系统中驻留的密钥量

两个用户A和B在获得共享密钥时有4种方式：
(1)经过A选取的密钥通过物理手段发送给另一方B。
(2)由第三方选取密钥，通过物理手段分别发送给A和B。
(3)A、B 事先已有一个密钥，其中一方选取新密钥后，用已有密
钥加密该新密钥后发送给另一方。
(4)三方A、B、C各有一保密信道，C 选取密钥后，分别通过A、B
各自的保密信道发送。

主体(Subject)

客体(Object)

控制策略

1)访问控制矩阵
2)访问控制表
3)能力表
4)授权关系表

优点

缺点

适用场景

原型法成败的关键及效率的高低，在于模型的建立及建模的速度。

适用场景

适用场景

快速应用开发模型的流程

敏捷开发更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重人的作用。

敏捷开发方法

是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。
UP是基于构件的，软件系统建模时，UP使用的是UML。

特点

(1)初始级
(2)已管理级
(3)严格定义级
(4)定量管理级
(5)优化级

功能需求

非功能需求

设计约束

业务需求

用户需求

系统需求

严格定义方法

原型方法

是什么

不包括

需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。

系统分析的基本任务是在充分了解用户需求的基础上，把对新系统的理解表达为系统需求规格说明书。

系统设计的目标是根据系统分析的结果，完成系统的构建过程。
其主要目的是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型，指导系统实施工作的顺利开展。

结构化分析（SA）

结构化设计(SD)

结构化编程(SP)

需求分析
概念结构设计
逻辑结构设计
物理设计
数据库的实施
数据库的运行和维护

5个层次

5个活动

两种对象类之间的结构

1)OOA原则

1)实体类

2)控制类

3)边界类

黑盒测试法

白盒测试法

灰盒测试法

桌前检查(Desk Checking)

代码审查

代码走查

(1) 内部确认测试：由软件开发组织内部按软件需求说明书进行测试。
(2) Alpha测试：由用户在开发环境下进行测试。
(3) Beta测试：由用户在实际使用环境下进行测试。
(4) 验收测试：针对软件需求说明书，在交付前以用户为主进行测试。

功能测试
健壮性测试
性能测试
用户界面测试
安全性测试
安装与反安装测试

(1)负载测试：指数据在超负荷环境中运行，程序是否能够承担。
(2)强度测试：在系统资源特别低的情况下考查软件系统运行情况。
(3)容量测试：确定系统可处理的同时在线的最大用户数。

(1)评估系统的能力
(2)识别体系中的弱点
(3)系统调优
(4)检测软件中的问题
(5)验证稳定性和可靠性

1. 活动定义 2. 活动排序 3. 活动资源估算 4. 活动历时估算 5. 制定进度计划 6. 进度控制

(1)WBS的工作包是可控和可管理的，不能过于复杂。
(2)任务分解也不能过细，一般原则WBS的树形结构不超过6层。
(3)每个工作包要有一个交付成果。
(4)每个任务必须有明确定义的完成标准。
(5)WBS必须有利于责任分配。

1)前导图法

2)箭线图法

(1)开发库
(2)受控库
(3)产品库

是数据库中存储的基本对象，是描述事物的符号记录。

数据库是统一管理的、长期储存在计算机内的，有组织的相关数据的集合。

DBMS 是数据库系统的核心软件，是由一组相互关联的数据集合和一组用以访问这些数据的软件组成。它是一种解决如何科学地组织和储存数据如何高效地获取和维护数据的系统软件。

由数据库及其管理软件组成的系统。

数据结构

数据操作

数据的约束条件

层次模型

网状模型

关系模型

面向对象的数据模型

一个数据库只有一个模式

用途

一个数据库只有一个内模式

实体完整性

参照完整性

用户自定义完整性

数据冗余

修改异常

插入异常

删除异常

概念结构设计的目标是产生反映系统信息需求的数据库概念结构，即概念模式。

E-R模型

逻辑结构设计就是在概念结构设计的基础上进行数据模型设计，可以是层次模型、网状模型和关系模型

步骤

物理结构设计就是为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）

步骤

常见的多值数据库有Rocket U2、Extensible Storage Engin(ESE/NT)、 OpenInsight 和OpenQM等

常见的时间序列数据库：InfluxDB、OpenTSDB。

主流数据库产品：GridGain和CrateDB。

批处理体系结构风格

管道-过虑器体系结构风格

面向对象风格

主程序/子程序风格

层次型体系结构风格

客户端/服务器体系结构风格

进程通信体系结构风格

事件系统体系结构风格

解释器体系结构风格

规则系统体系结构风格

开发过程中，只要发现有可复用的资产，就对其进行复用

开发之前，就要进行规划，以决定哪些需要复用

为一组相近或相似的应用建立基本能力与必备基础的过程，它覆盖了建立可重用软件元素的所有活动。

通过重用软件资源，以领域通用体系结构为框架，开发出满足用户需求的一系列应用软件的过程

1.性能

2.可靠性

3.可用性

4.安全性

5.可修改性

6.功能性

7.可变性

8.互操作性

子主题

SAAM 分析评估架构的过程包括5 个步骤，即场景开发、架构描
述、单个场景评估、场景交互和总体评估。

是评价软件构架的一种综合全面的方法。
主要针对性能、可用性、安全性和可修改性，在系统开发之前，
可以使用ATAM方法在多个质量属性之间进行评价和折中

成本效益分析法 (CBAM)是在ATAM上构建，用来对架构设计决策
的成本和收益进行建模，是优化此类决策的一种手段。CBAM 的
思想就是架构策略影响系统的质量属性，反过来这些质量属性又
会为系统的项目干系人带来一些收益(称为效用)，CBAM 协助项
目干系人根据其投资回报(ROI)选择架构策略。

自然时间

运行时间

执行时间

F(t) 单位时间内失效的元件数与元件总数的比例

软件系统在规定的条件下、规定的时间内不发生失效的概率。

可靠度的公式为R(t)=1-F(t)

单位时间软件系统出现失效的概率

系统平均失效前时间 (MTTF)也叫平均失效等待时间，定义为从0
时到故障发生时系统的持续运行时间的期望值

平均恢复前时间(MTTR)也叫平均故障修复时间，是从出现故障到
修复成功中间的这段时间，它包括确认失效发生所必需的时间，
记录所有任务的时间，还有将设备重新投入使用的时间。

子主题

MTBF= MTTR+ MTTF 实际MTTR很小，所以MTBF≈MTTF。

按成本的影响

对系统能力的影响

广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运
用建模、统计、试验、分析和评价等一系列手段对软件系统实施
的一种测试

(1)发现软件系统在需求、设计、编码、测试和实施等方面的缺陷。
(2)为软件的使用和维护提供可靠性数据。
(3)确认软件是否达到可靠性的定量要求。

1.恢复块设计

2.N版本程序设计

3.冗余设计

检错技术，在软件出现故障后能及时发现并报警，提醒维护人员
进行处理。

降低复杂度设计的思想就是在保证实现软件功能的基础上，简化
软件结构，缩短程序代码度，优化软件数据流向，降低软件复杂
度，从而提高软件可靠性。

软件复杂性

1.双机热备技术

2.服务器集群技术

组件是软件架构的基本要素和结构单元，表示系统中主要的计
算元素、数据存储以及一些重要模块，当需要消除软件架构存
在的缺陷、新增功能、适应新的环境时都涉及组件的演化。组
件的演化体现在组件中模块的增加、删除或修改。

连接件是组件间的交互关系，多数情况下组件的演化牵涉到连接件
的演化。连接件的演化体现在组件交互消息的增加、删除或改变。

约束是组件和连接件之间的拓扑关系和配置，它为组件和连接件 提供额外数据支撑，可以是架构的约束数据，或架构的参数

基于过程和函数的演化

面向对象的演化

基于组件的演化

基于架构的演化

第1类是对演化的支持，如代码模块化的准则、可维护性的支持(如内聚和耦合)、代码重构等

第2类是版本和工程的管理工具，如CVS 和COCOMO

第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等

第4类是架构演化的成本收益分析决定如何增加系统的弹性

静态演化发生在软件架构的设计、实现和维护过程中，软件系 统还未运行或者处在运行停止状态。

动态演化发生在软件系统运行过程中

(1)设计时演化需求。

(2)运行前演化需求。

软件静态演化是系统停止运行期间的修改和更新，即一般意义上
的软件修复和升级。与此时相对应的维护方法有三类：更正性维
护、适应性维护、完善性维护

1)软件动态性的等级

2)动态演化的内容

⚫ 原则名称：演化成本控制 (ECC)原则。
⚫ 原则解释：演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本。
⚫ 原则用途：用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。
⚫ 度量方案：CoE<<CoRD。
⚫ 方案说明：CoE为演化成本，CoRD为重新开发成本，CoE远小于CoRD最佳。

⚫ 原则名称：进度可控原则。
⚫ 原则解释：架构演化要在预期时间内完成，也就是时间可控。
⚫ 原则用途：根据该原则可以规划每个演化过程的任务量；体现一种迭代、递增(持续演化)的演化思想。
⚫ 度量方案:：ttask=|Ttask-T'task|。
⚫ 方案说明：某个演化任务的实际完成时间 (Ttask) 和预期完成时间 (T'task)的时间差ttask越小越好。

⚫ 原则名称：风险可控原则。
⚫ 原则解释：架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
⚫ 原则用途：用于判断架构演化过程中各种风险是否易于控制。
⚫ 度量方案：分别检验。
⚫ 方案说明：时间风险、经济风险、人力风险、技术风险都不存在

⚫ 原则名称：主体维持原则
⚫ 原则解释：对称稳定增长(AIG)原则所有其他因素须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，
从而达到令人满意的演化。因此，软件演化的平均增量的增长须保持平稳，保证软件系统主体行为稳定。
⚫ 原则用途：用于判断架构演化是否导致系统主体行为不稳定。
⚫ 度量方案：计算AIG即可，AIG=主体规模的变更量/主体的规模。
⚫ 方案说明：根据度量动态变更信息(类型、总量、范围 高级项目经理 ) 来计算

⚫ 原则名称：系统总体结构优化原则。
⚫ 原则解释：架构演化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。
⚫ 原则用途：用于判断系统整体结构是否合理，是否最优。
⚫ 度量方案：检查系统的整体可靠性和性能指标。
⚫ 方案说明：判断整体结构优劣的主要指标是系统的可靠性和性能。

⚫ 原则名称：平滑演化(IWR)原则 ⚫ 原则解释：在软件系统的生命周期里，软件的演化速率趋于稳 定，如相邻版本的更新率相对固定。 ⚫ 原则用途：用于判断是否存在剧烈架构演化。 ⚫ 度量方案：计算IWR即可，IWR=变更总量/项目规模。 ⚫ 方案说明：根据度量动态变更信息 (类型、总量、范围等) 来 计算

⚫ 原则名称：目标一致原则
⚫ 原则解释：架构演化的阶段目标和最终目标要一致。
⚫ 原则用途：用于判断每个演化过程是否达到阶段目标，所有演
化过程结束是否能达到最终目标。
⚫ 度量方案：otask=|Otask-O'task|。 ⚫ 方案说明：阶段目标的实际达成情况 (Otask) 和预期目标
(O'task)的差otask越小越好。

⚫ 原则名称：模块独立演化原则，或修改局部化原则。
⚫ 原则解释：软件中各模块(相同制品的模块，如Java的某个类或
包)自身的演化最好相互独立，或者至少保证对其他模块的影
响比较小或影响范围比较小。
⚫ 原则用途：用于判断每个模块自身的演化是否相互独立。
⚫ 度量方案：检查模块的修改是否是局部的。
⚫ 方案说明：可以通过计算修改的影响范围来进行度量。

⚫ 原则名称：影响可控原则。
⚫ 原则解释：软件中一个模块如果发生变更，其给其他模块带来
的影响要在可控范围内也就是影响范围可预测。
⚫ 原则用途：用于判断是否存在对某个模块的修改导致大量其他
修改的情况。
⚫ 度量方案：检查影响的范围是否可控。
⚫ 方案说明：通过计算修改的影响范围来进行度量。

⚫ 原则名称：复杂性可控(CC)原则。
⚫ 原则解释：架构演化必须要控制架构的复杂性，从而进一步保
障软件的复杂性在可控范围内。
⚫ 原则用途：用于判断演化之后的架构是否易维护、易扩展、易
分析、易测试等。
⚫ 度量方案：CC小于某个阈值。
⚫ 方案说明：CC增长可控。

⚫ 原则名称：有利于重构原则。
⚫ 原则解释：架构演化要遵循有利于重构原则，使得演化之后的
软件架构更方便重构。
⚫ 原则用途：用于判断架构易重构性是否得到提高。
⚫ 度量方案：检查系统的复杂度指标。
⚫ 方案说明：系统越复杂越不容易重构

⚫ 原则名称：有利于重用原则。 ⚫ 原则解释：架构演化最好能维持，甚至提高整体架构的可重用 性。 ⚫ 原则用途：用于判断整体架构可重用性是否遭到破坏。 ⚫ 度量方案：检查模块自身的内聚度、模块之间的耦合度。 ⚫ 方案说明：模块的内聚度越高，该模块与其他模块之间的耦合 度越低，越容易重用。

⚫ 原则名称：设计原则遵从性原则。 ⚫ 原则解释：架构演化最好不能与架构设计原则冲突。 ⚫ 原则用途：用于判断架构设计原则是否遭到破坏(架构设计原 则是好的设计经验总结，要保障其得到充分使用)。 ⚫ 度量方案：RCP=|CDP| / |DP|。 ⚫ 方案说明：冲突的设计原则集合 (CDP) 和总的设计原则集合 (DP)的比较，RCP越小越好。

⚫ 原则名称：适应新技术(TI) 原则。
⚫ 原则解释：软件要独立于特定的技术手段，这样才能够让软件
运行于不同平台。
⚫ 原则用途：用于判断架构演化是否存在对某种技术依赖过强的
情况。
⚫ 度量方案：TI=1-DDT，DDT=|依赖的技术集合|/|用到的技术合集|。 ⚫ 方案说明：根据演化系统对关键技术的依赖程度进行度量

⚫ 原则名称：环境适应性原则。
⚫ 原则解释：架构演化后的软件版本能够比较容易适应新的硬件
环境与软件环境。
⚫ 原则用途：用于判断架构在不同环境下是否仍然可使用，或者
容易进行环境配置。
⚫ 度量方案：硬件/软件兼容性。
⚫ 方案说明：结合软件质量中兼容性指标进行度量

⚫ 原则名称：标准依从性原则。
⚫ 原则解释：架构演化不会违背相关质量标准(国际标准、国家
标准、行业标准、企业标准等)。 ⚫ 原则用途：用于判断架构演化是否具有规范性，是否有章可循；
而不是胡乱或随意地演化。
⚫ 度量方案：需要人工判定

⚫ 原则名称：质量向好(QI)原则。
⚫ 原则解释：通过演化使得所关注的某个质量指标或某些质量指
标的综合效果变得更好或者更满意，例如可靠性提高了。
⚫ 原则用途：用于判断架构演化是否导致某些质量指标变得很差。
⚫ 度量方案：EQI>SQ。 ⚫ 方案说明：演化之后的质量(EQI) 比原来的质量(SQ) 要好。

⚫ 原则名称：适应新需求原则。
⚫ 原则解释：架构演化要容易适应新的需求变更；架构演化不能
降低原有架构适应新需求的能力；架构演化最好可以提高适应
新需求的能力。
⚫ 原则用途：用于判断演化之后的架构是否降低了架构适应新需
求的能力。
⚫ 度量方案：RNR=|ANR|/|NR|。 ⚫ 方案说明：适应的新需求集合 (ANR) 和实际新需求集合 (NR)的
比较，RNR越小越好

通过对演化前后的不同版本的架构分别进行度量，得到度量结果的差值及其变化趋势，并计算架构间质量属性距离，进而对相关质量属性进行评估

对于可靠性，度量结果是一个实数值

对于可维护性，它包含圈复杂度、扇入扇出度、模块间耦合度、模块的响应、紧内聚度、松内聚度等 6个子度量指标

架构知识= 架构设计 + 架构设计决策

1.圈复杂度(CCN)

2.扇入扇出度(FFC)

3.模块间耦合度(CBO)

4.模块的响应(RFC)

5.紧内聚度TCC

6.松内聚度LCC

1.弱人工智能

2.强人工智能

大数据是指其大小或复杂性无法通过现有常用的软件工具，以合
理的成本并在可接受的时限内对其进行捕获、管理和处理的数据
集

⚫ 大量(Volume)：数据量的大小决定数据的价值和潜在的信息；单位是PB(1024TB)、EB(1024PB)。 
⚫ 高速(Velocity) ：指获得数据的速度和处理速度。
⚫ 多样性(Variety) ：类型繁多，包括各种结构化、半结构化和非结构化的数据；。
⚫ 真实性(Veracity)：数据的质量。
⚫ 价值(Value)：单位价值密度低，合理运用大数据，以低成本创造高价值。

集中式

\分布式

例如工厂的管理信息系统，从管理职能角度划分，包括供应、生
产、销售、人事、财务等主要功能的信息管理子系统

1.战略系统

2.业务系统

3.应用系统

4.企业信息基础设施

TOGAF是一种开放式企业架构标准，它为标准、方法论和企业架
构专业人员之间的沟通提供一致性保障。

架构开发方法(ADM)为开发企业架构所需要执行各个步骤以及它
们之间的关系进行详细的定义，同时它也是 TOGAF 规范中最为核
心的内容。

ADM架构开发包括十个阶段

⚫ 系统规划

⚫ 系统分析

⚫ 系统设计

⚫ 系统实施

⚫ 系统运行和维护

⚫ 关键成功因素法(CSF)

⚫ 战略目标集转化法(SST)

⚫ 企业系统规划法(BSP)

⚫ 企业信息分析与集成技术

⚫ 产出/方法分析

⚫ 投资回收法

⚫ 征费法 (chargout)

⚫ 零线预算法

⚫ 阶石法

(1)要注意污水池反模式

(2)需要考虑的是分层架构可能会让你的应用变得庞大

⚫ 领域实体：定义了业务中的对象，对象有属性和行为；
⚫ 业务规则：定义了需要完成一个动作，必须满足的条件；
⚫ 数据完整性：某些数据不可少；
⚫ 工作流：业务流程的全部或部分自动化，在此过程中，文档、
信息或任务按照一定的过程规则流转，实现组织成员间的协调
工作以达到业务的整体目标。

以数据为中心的文档

以文档为中心的文档

(1)基于文件的存储方式

(2)数据库存储方式

服务化架构是云时代构建云原生应用的标准架构模式，要求以应
用模块为颗粒度划分一个软件，以接口契约(例如IDL) 定义彼此业
务关系，以标准协议 (HTTP、gRPC 等)确保彼此的互联通，结合
DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个
接口的代码质量和迭代速度。

Mesh 化架构是把中间件框架(如 RPC、缓存、异步消息等)从业务
进程中分离，让中间性SDK 与业务代码进一步解耦，从而使得中
间件升级对业务进程没有影响，其至迁移到另外一个平台的中间
件也对业务透明。

Serverless 将“部署”这个动作从运维中“收走”，使开发者不用
关心应用运行地点、操作系统、网络配置、CPU 性能等，从架构
抽象上看，当业务流量到来/业务事件发生时，云会启动或调度
一个已启动的业务进程进行处理，处理完成后云自动会关闭/调
度业务进程，等待下一次触发，也就是把应用的整个运行都委托
给云

Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，
扩展和管理容器化应用，是一个全新的基于容器技术的分布式架
构解决方案。Kubernetes 提供了分布式应用管理的核心能力。
⚫ 资源调度：根据应用请求的CPU、Memory资源量，或者GPU等
设备资源，在集群中选择合适的节点来运行应用。
⚫ 应用部署与管理：支持应用的自动发布与应用的回滚，以及与
应用相关的配置的管理；也可以自动化存储卷的编排，让存储
卷与容器应用的生命周期相关联。
高级项目经理 任铄
edu.51cto.com
⚫ 自动修复：Kubernetes能监测这个集群中所有的宿主机，当宿
主机或者OS出现故障，节点健康检查会自动进行应用迁移；
K8s也支持应用的自愈，极大简化了运维管理的复杂性。
⚫ 服务发现与负载均衡：Service是对一组提供相同功能的Pods的
抽象，并为它们提供一个统一的入口。借助Service，应用可以
方便的实现服务发现与负载均衡，并实现应用的零宕机升级。。
⚫ 弹性伸缩：K8s可以监测业务上所承担的负载，如果这个业务
本身的CPU利用率过高，或者响应时间过长，它可以对这个业
务进行自动扩容。

UDDI(统一描述、发现和集成协议)是一种用于描述、发现、集成
Web Service的技术，它是Web Service协议栈的一个重要部分。

WSDL (Web 服务描述语言)，是一个用来描述 Web 服务和说明如 何与 Web 服务通信的XML语言。

SOAP(简单对象访问协议)是在分散或分布式的环境中交换信息的
简单协议，是一种轻量的、简单的、基于XML 的协议。

(1)提供位置透明的消息路由和寻址服务。 (2)提供服务注册和命名的管理功能。 (3)支持多种消息传递范型(如请求/响应、发布/订阅等)。 (4)支持多种可以广泛使用的传输协议。 (5)支持多种数据格式及其相互转换。 (6)提供日志和监控功能。

⚫ 需求分析

⚫ 现有网络系统分析，即通信规范分析

⚫ 确定网络逻辑结构，即逻辑网络设计

⚫ 确定网络物理结构，即物理网络设计

⚫ 安装和维护

1)接入层

2)分布层

3)核心层

(1)三层结构减轻了内层网络主设备的负载。由于分布层的过滤和 汇聚，使得核心层设备避免了处理大量细节路由信息，降低CPU 开销和网络带宽消耗。 (2)降低了网络成本。按不同层次功能要求选择网络设备，可以降 低不必要的功能投入花费。此外，层次化的模型结构便于网络管 理，降低网络运行维护花费。 (3)简化了设计元素，使设计易于理解。 (4)容易变更层次结构。局部升级不会影响其他部分，扩展方便。