一文简述系统架构设计

软件架构指从需求分析到软件设计之间的过渡过程。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

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

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

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

解决好软件复用、质量和维护问题，是研究软件架构的根本目的。

软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。

软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计住要关注软件组织的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。

软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训基础。

软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

1.1.1 需求分析阶段

需求分析和SA设计面临的是不同的对象：一个是空间问题，另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构件SA模型；如何保证模型转换的可追踪性。

1.1.2 设计阶段

设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3层次：SA的基本概念（构件和连接子）、体系结构描述语言ADL、SA模型的多视图表示。

1.1.3 实现阶段

最初SA研究往往只关注较高层次的系统设计、描述和验证、为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在以下几个方面。

1> 研究基于SA的开发过程支持，如项目组织结构、配置管理等；

2> 寻求从SA向实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等；

3> 研究基于SA的测试技术。

1.1.4 构件组装阶段

在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容如下两个方面。

1> 如何支持可复用构件的互联，即对SA设计模型中约束的连接子的实现提供支持；

2> 在组装过程中，如何检测并消除体系结构失配问题。

在构件组装阶段的失配问题主要包括：由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。

1.1.5 部署阶段

SA对软件部署作用如下：

1> 提供高层的体系结构视图来描述部署阶段的软硬件模型；

2> 基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。

1.1.6 后开发阶段

后开发阶段是指软件部署安装之后的阶段，这一阶段的SA研究主要围绕维护、演化、复用等方面来进行，典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。

1> 动态软件体系结构：现实中的软件具有动态性，体系结构会在运行时发生改变。运行时变化包括两类：软件内部执行所导致的体系结构改变和软件系统外部的请求对软件进行的重配置。这部分研究内容包括体系结构设计阶段的支持和运行时刻基础设施的支持。

2> 体系结构恢复与重建：对于现有系统在开发时候没有考虑SA的情况，从这些系统中恢复或重构体系结构。从已有的系统中获取体系结构的重建方法分为4类：手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术（如数据库挖掘等）。

1.2.1 性能指标

1.2.1.1 计算机

对计算机评价的主要性能指标有：时钟频率（主频）、运算速度、运算精度、内存的存储容量、存储器的存取周期、数据处理速率PDR（processingdatarae）、吞吐率、各种响应时间、各种利用率、RASIS特性（即可靠性Reliability、可用性Availability、可维护性Sericeability、完整性和安全性Integraity and Security）、平均故障响应时间、兼容性、可扩充性、性能价格比。

1.2.1.2 路由器

对路由器评价的主要性能指标有：设备吞吐量、端口吞吐量、全双工线速转发能力、背靠背帧数、路由表能力、背板能力、丢包率、时延、时延抖动、VPN支持能力、内部时钟精度、队列管理机制、端口硬件队列数、分类业务带宽保证、RSVP、IP Diff Serv、CAR支持、冗余、热插拔组件、网管粒度、计费能力/协议、分组语音支持方式、协议支持、语音压缩能力、端口密度、信令支持。

1.2.1.3 交换机

对交换机评价的主要性能指标有：交换机类型、配置、支持的网络类型、最大ATM端口数、最大SONET端口数、最大FDDI端口数、背板吞吐量、缓冲区大小、最大MAC地址表大小、最大电源数、支持协议和标准、路由信息协议RIP、RIP2、开放式最短路径优先第2版、边界网关协议BGP、无类域间路由CIDR、互联网成组管理协议IGMP、距离矢量多播路由协议PIM、资源预留协议RSVP、802.1p优先级标记、多队列、路由、支持第三层交换、支持多层（4到7层交换）、支持多协议路由、支持路由缓存、可支持最大路由表数、VLAN、最大VLAN数量、网管、支持网管类型、支持端口镜像、QoS、支持基于策略的第2层交换、每端口最大优先级队列数、支持基于策略的第3层交换、支持基于策略的应用级QoS、支持最小/最大带宽分配、冗余、热交换组件（管理卡，交换结构，接口模块，电源，冷却系统，支持端口链路聚集协议，负载均衡）。

1.2.1.4 网络

对网络评价的性能指标有：设备级性能指标、网络级性能指标、应用级性能指标、用户级性能指标、吞吐量。

1.2.1.5 操作系统

对操作系统评价的指标有：系统的可靠性、系统的吞吐率（量）、系统响应时间、系统资源利用率、可移植性。

1.2.1.6 数据库管理系统

对数据库管理系统评价的指标包含数据库本身和管理系统两部分，包括数据库的大小、数据库中表的数量、单个表的大小、表中允许的记录（行）数量、单个记录（行）的大小、表上所允许的索引数量、数据库所允许的索引数量、最大并发事务处理能力、负载均衡能力、最大连接数等。

1.2.1.7 WEB服务器

对WEB服务器评价的指标有最大并发连接数、响应延迟、吞吐量。

1.2.2 性能评价方法

1.2.2.1 性能评测的主要指标

1> 时钟频率：一般来讲，主频越高，速度越快；

2> 指令执行速度：计量单位KIPS（每秒千条指令）、MIPS（每秒百万条指令）；

3> 等效指令速度法：统计各类指令在程序中所占比例，并进行折算，是一种固定比例法；

4> 数据处理速率（Processing Data Rate，PDR）法：采用计算PDR值的方法来衡量机器性能，PDR值越大，机器性能越好。PDR与每条指令和每个操作数的平均位数以及每条指令的平均运算速度有关；

1.2.2.2 基准程序法Benchmark

把应用程序中用得最多、最频繁的那部分核心程序作为评价计算机性能的标准程序，称为基准测试程序（benchmark），是目前被用户一致承认的测试性能的较好方法，有多重多样的基准程序，包括：

1> 整数测试程序：同一厂家的机器，采用相同的体系结构，用相同的基准程序测试，得到的MIPS值越大，一般说明机器速度越快；

2> 浮点测试程序：指标MFLOPS（理论峰值浮点速度）；

3> SPEC基准程序（SPEC Benchmark）：重点面向处理器性能的基准程序集，将被测计算机的执行时间标准化，即将被测计算机的执行时间除以一个参考处理器的执行时间啊in；

4> TCP基准程序：用于评测计算机在事务处理、数据库处理、企业管理与决策系统等方面的性能。其中，TPC-C是在线事务处理（On-line Transaction Processing，OLTP）的基准程序，TPC-D是决策支持的基准程序。TPC-E作为大型企业信息服务的基准程序。

大多数情况下，为测试新系统的性能，用户必须依靠评价程序来评价机器的性能，下面列出了4中评价程序，他们评测的准确程度依次递减：真实的程序、核心程序、小型基准程序、合成基准程序。

1.2.2.3 阿姆达尔解决方法

阿姆达尔（Amdahl）定律主要用于系统性能改进的计算中。阿姆达尔定律是指计算机系统中对某一部件采用某种更快的执行方式锁获得的系统性能改变程度，取决于这种方式被使用的频率，或所占总执行时间的比例。

阿姆达尔定律定义了采用特定部件所取得的加速比。假定我们使用某种增强部件，计算机的性能就会得到提高，那么加速比就是下式所定义的比率：

软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系，评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。

1.3.1 开发期质量属性

开发期质量属性主要指在软件开发阶段锁关注的质量属性，主要包含6个方面：

1> 易理解性：指设计被开发人员理解的难易程度；

2> 可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性；

3> 可重用性：指重用软件系统或某一部分的难易程度；

4> 可测试性：指对软件测试以证明其满足需求规范的难易程度；

5> 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难以程度；

6> 可移植性：将系统从一个运行环境转移到另一个不同的运行环境的难易程度。

1.3.2 运行期质量属性

运行期指令属性主要指在软件运行阶段所关注的质量属性，主要包含：

1> 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求；

2> 安全性：指软件系统同时兼顾向合法用户提供服务，以及组织非授权使用的能力；

3> 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力，例如通过增加服务器来提高能力；

4> 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度；

5> 可靠性：软件系统在一定的时间内持续无故障运行的能力；

6> 可用性：指系统在一定时间内正常工作的时间所占的比例，可用性会瘦到系统错误、恶意攻击、高负载等问题影响；

7> 鲁棒性：是软件系统在正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也成健壮性或容错性。

1.3.3 质量属性效用树和质量属性判断

1.3.3.1 性能

定义：在规定的时间能够完成某种功能，是加了时间限制的功能，即系统对某个功能的响应时间，一般情况下的描述都会带有时间字样或用速度来形容。

优化策略：增加计算机资源、优先级队列、减少计算开销、引入并发机制、采用资源调度等。

代表参数：响应时间、吞吐量。

1.3.3.2 可靠性

. 定义：可靠性是系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。

设计策略：心跳、Ping/Echo、冗余、选举。

1.3.3.3 可用性

可用性是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能恢复正常的速度来表示，如障碍间隔时间。

出现故障后能够恢复可用的能力。

设计策略：心跳、Ping/Echo、冗余、选举。

1.3.3.4 安全性

安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力，如保密性、完整性、不可抵赖性、可控性。

设计策略：入侵检测、用户认证、用户授权、追踪审计。

1.3.3.5 可修改性

可修改性指能够快速的以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过考察这些变更的代价衡量。

可用投入精力增加系统功能的特性。

设计策略：接口-实现分类、抽象、信息隐藏。

1.3.3.6 功能性

功能性是系统所能完成期望的工作能力，一项任务的完成需要系统中许多或大多数构件的相互协作。

1.3.3.7 可变性

可变性是指体系结构经扩充或变更而成为新体系结构的能力，这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构，当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

1.3.3.8 互操作性

互操作性作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

1.3.4 架构权衡分析法ATAM

架构权衡分析法ATAM，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。

ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。

整个评估过程强调以属性作为架构评估的核心概念，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

1.3.5 架构风险

架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

1.3.5.1 风险点与非风险点

风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患，如描述：目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复影响系统的可修改性。

非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达，如描述：假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的。

不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的，可接受的，则为非风险点。

1.3.5.2 敏感点

敏感点是指为了实现某种特定的质量属性，一个或多个构件（或构件之间的关系）所具有的特性，如描述：对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计。

1.3.5.3 权衡点

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点，例如安全和性能的权衡，如描述：更改加密的级别将对安全性和性能产生影响。

软件架构风格是指描述特定软件系统组织方式的惯用模式，组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反应众多系统共有的结构和语义，共包含5大架构风格，每个大架构风格又包含若干子风格，如下：

1> 数据流风格：批处理、管道-过滤器；

2> 调用/返回风格：主程序/子程序、面向对象、层次结构；

3> 独立构件风格：进程通信、事件驱动系统（隐式调用）；

4> 虚拟机风格：解释器、规则系统；

5> 仓库风格：数据库系统、黑板系统、超文本系统。

1.4.1 子风格特点介绍

1> 架构需求：重在账务标识构件的三部，如上图左；

2> 架构设计：将需求阶段的标识构件映射成构件，进行分析，如上图右；

3> 架构（体系结构）文档化：主要产出两种文档，即架构（体系结构）规格说明书，测试架构（体系架构）需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败；

4> 架构复审：由外部人员（独立于开发组织之外的人，如用户代表和领域专家等）参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审；

5> 架构实现：用实体来显示出架构，实现构件，构件组装成系统，如下图左；

6> 架构演化：对架构进行改变，按需求增删构件，使架构可复用，如下图右。

构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。

构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能被单独部署。

构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署；相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

一个模块是不带单独资源的原子构件。

一个单独的包被编译成多个单独的类文件——每个公共类都有一个。

模块是一组类和可能的非面向对象的结构体，如果过程或者函数。

构件的特性是：

1> 独立部署单元

2> 作为第三方的组装单元；

3> 没有（外部的）可见状态。

一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没有什么意义。

对象的特性是：

1> 一个实例单元，具有唯一性；

2> 可能具有状态，此状态外部可见；

3> 封装了自己的状态和行为。

接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。

关注于如何支持建立面向构件的解决方案，面向构件的编程需要下列基本的支持：

1> 多态性（可替代性）；

2> 模块封装性（高层次信息的隐藏）；

3> 后期的绑定和装载（部署独立性）；

4> 安全性（类型和模块安全性）；

构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户直接操作的细节进行封装，同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节。目前，国际上常用的购进标准主要有三大流派。

1> EJB（Enterprise Java Bean）规范由Sun公司制定，有三种类型的EJB，分别是会话Bean（Session Bean）、实体Bean（Entity Bean）和消息驱动Bean（Message-driven Bean）。EJB实现应用中关键的业务逻辑，创建基于构件的企业级应用程序；

2> COM、DCOM、COM+：COM是微软公司的。DCOM是COM的进一步扩展，具有位置独立性和语言无关性。COM+并不是COM的新版本，是COM的新发展或是更高层次的应用。

3> COBRA标准主要分为三个层次：对象请求代理、公共对象服务和公共设施。

最底层的对象请求代理是ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”；

在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；

最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效写作所需的协定规则。

1> 领域分析：该阶段的主要目标是获得领域模型（领域需求），识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

2> 领域设计：该阶段的目标是获得DSSA，DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

3> 领域实现：这个阶段的主要目标是根据领域模型和DSSA开发和组织可重用信息，这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

1> 领域专家：领域专家包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等，提供关于领域中系统的需求设计规约和实现知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等等。

2> 分析人员：分析人员由具有知识工程北京的有经验的系统分析员来担任，控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。

3> 设计人员：设计人员由有经验的软件设计人员来担任，根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。

4> 实现人员：实现人员由有经验的程序设计人员来担任，根据领域模型和DSSA，开发构件。

领域开发环境：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具；

领域特定的应用开发环境：应用工程师根据具体环境来讲核心架构实例化；

应用执行环境：操作员实现实例化后的架构。

软件层次式架构是最通用的架构，也被叫作N层架构模式。大部分的应用会分成表现层（或称为展示层）、中间层（或称为业务层）、数据访问层（或称为持久层）和数据层。层次架构是最通用的架构，常作为初始架构，每层只关注本层工作即可。

表现层主要解决与用户沟通层面、展示内容、提取信息及反馈；

中间层往往可划分几个层级，包含业务逻辑；

访问层主要与数据库对接，通过访问层获取数据，对中间层业务逻辑进行支持；

数据层用于存储和管理数据。

使用XML设计表现层。

UIP提供了一个扩展的框架，用于简化用户接买进与商业逻辑代码的分离的方法，可以用它来写复杂的用户界面导航和工作流处理，并且它能够复用在不同场景、并可以随着应用的增加而进行扩展。

使用UIP框架的应用程序把表现层分为了以下几层。

1> User Interface Components：这个组件就是原来的表现层，用户看到的和进行交互的都是这个组件，它负责获取用户的数据并且返回结果。

2> User Interface Process Components：这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为User Interface Components提供了重要的支持功能。

表现层动态生成设计：基于XML的界面管理技术可实现灵活的界面配置（静态）、界面动态生成和界面定制（动态）。其思路是用XML生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面。

4.2.1 组件设计

组件设计：业务逻辑组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。增加业务逻辑组件的接口，是为了提供更好的解耦，控制器无须与具体的业务逻辑组件耦合，而是面向接口编程。

4.2.2 工作流设计

工作流设计：工作流定义为业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。工作流参考模型如下图所示：

共包含6个基本模块，分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、调用应用和管理监控工具。

1> 接口1：过程定义导入/导出接口，其特点是转换格式和API调用，从而支持过程定义信息间的互相转换；

2> 接口2：客户端应用程序接口，通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务，然后由任务表处理器负责，从任务表中选择、推进任务项，有任务表处理器或者终端用户来控制应用工具的活动。

3> 接口3：应用程序调用接口，允许工作流机直接激活一个应用工具，来执行一个活动。典型的是调用以后台服务为主的应用程序，没有用户接口。当执行活动要用到的工具，需要与终端用户交互，通常是使用客户端应用程序接口来调用那个工具，这样可以为用户安排任务时间表提供更多的灵活性。

4> 接口4：工作流机协作接口，其目标是定义相关标准，以使不同开发商的工作流系统产品相互间能够进行无缝的任务项传递。

5> 接口5：管理和监视接口，提供的功能包括用户管理、角色管理、审查管理、资源控制、过程管理和过程状态处理器等。

4.2.3 实体设计

业务逻辑层实体提供对业务数据库及相关功能（在某些设计中）的状态编程访问，业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中多个相关表。

在应用程序中表示业务逻辑层实体的方法有很多（从以数据为中心的模型到更加面向对象的表示法），如XML、通用DataSet、有类型的DataSet等。

如下图左侧是业务实体用XML表示，右侧所示为用于Order业务逻辑层实体的通用DataSet对象。此DataSet对象具有两个Data Table对象，分别保存订单信息和订单详细信息。每个DataTable具有一个对应的UniqueConstraint对象，分别保存订单信息和订单详细信息。每个DataTable具有一个对应的UniqueConstraint对象，用于标识表中的主键。此外，该DataSet还有一个Relation对象，用于将订单详细信息与订单相关联。

业务框架位于系统架构的中间层，是实现系统功能的核心组件，采用容器形式，便于系统功能的开发、代码重用和管理。

上图即在吸收了SOA思想之后的一个三层体系结构图的简图。

业务层采用业务容器的方式存在与整个系统当中，采用此方式可以大大降低业务层和相邻各层的耦合，表示层代码只需要将业务参数传递给业务容器，而不需要业务层多余的干预。如此一来，可以有效地防止业务层代码渗透到表示层。

在业务层容器中，业务逻辑是按照Domain Model-Service Control思想来实现的。

1> Domain Model是领域层业务对象，它仅仅包含业务相关的属性；

2> Service是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来；

3> Control服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。

5中数据访问模式：

1> 在线访问：会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互；

2> DataAccess Object：是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开；

3> Data Transfer Object：是经典EJB设计模式之一，DTO本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据，这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其他的对象行为。

4> 离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中，称为应用的中心。离线，对数据的各种操作独立与各种与后台数据源之间的连接或是事务。

5> 对象/关系映射（Object/Relation Mapping，O/R Mapping）：大多数应用中的数据都是依据关系模式模型存储在关系型数据库中；而很多应用程序中的数据在开发或是运行时则是以对象的形式组织起来的，那么，对象/关系映射就提供了这样一种工具或是平台，能够帮助将应用程序中的数据转换成关系型数据库中的记录；或是将关系数据库中的记录转换成应用程序中代码便于操作对象。

4.3.1 工厂模式在数据库访问层的应用

首先定义一个操作数据库的结构DataAccess，然后根据数据库的不同，由类工厂决定实例化哪个类。

因为DataAccess的具体实现类有一些共同的方法，所以先从DataAccess实现一个抽象的AbstractDataAccess类，包含一些公用方法，然后，分别为SqlServer、Oracle和OLED吧数据库编写三个数据库访问的具体实现类。

现在已经完成了所要的功能，下面需要创建一个Factory类，来实现自动数据库切换的管理，这个类很简单，主要的功能是根据数据库类型，返回适当的数据库操作类。

4.3.2 事务处理设计

JavaBean使用JDBC方式进行事务处理：在JDBC中，打开一个连接对象Connection时，默认是aotu-commit模式，每个SQL语句都被当做一个事务，即每次执行一个语句，都会自动地得到事务确认。为了能将多个SQL语句组合成一个事务，要将auto-commit模式屏蔽掉。在auto-commit模式屏蔽掉之后，如果不调用commit()方法，SQL语句不会得到事务确认，在最近一次commit()方法调用之后的所有SQL会在commit()调用时得到确认。

4.3.3 连接对象管理设计

通过资源池解决资源频繁分配、释放所造成的问题。

建立连接池的第一步，就是要建立一个静态的连接池。所谓静态，是指池中的连接是在系统初始化时就分配好的，并且不能够随意关闭。Java中给我们提供了很多容器类，可以方便地用来构建连接池，如Vector、Stack等。在系统初始化时，根据配置创建连接并放置在连接池中，以后所使用的连接都是从该连接池中获取的，这样就可以避免连接随意建立、关闭造成的开销。

有了这个连接池，下面就可以提供一套自定义的分配、释放策略。当客户请求数据库连接时，首先看连接池中是否有未分配出去的连接。如果存在空闲连接则把连接分配给客户，并标记该连接为已分配。若连接池中没有空闲连接，就在已经分配出去的连接中，寻找一个合适的连接给客户，此时该连接在多个客户间复用。

当客户释放数据库连接时，可以根据该连接是否被复用，进行不同的处理。如果连接没有使用者，就放入到连接池中，而不是被关闭。

4.3.4 数据架构规划与设计

数据库设计与XML设计融合。

XML文档分为两类：一类是以数据为中心的文档，这种文档在结构上是规则的，在内容上是同构的，具有较少的混合内容和嵌套层次，人们只关心文档中的数据而并不是关心数据元素的存放顺序，这种文档简称为数据文档，它常用来存储和传输Web数据。另一类是以文档为中心的文档，这种文档的结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的，这种文档常用来在网页上发布描述性信息、产品性能介绍和E-mail信息等。

经提出的XML文档的存储方式有两种：基于文件的存储方式和数据库存储方式。

1> 基于文件的存储方式是指将XML文档按其原始文本形式存储，主要存储技术包括操作系统文件库、通用文档管理系统和传统数据库的列。这种存储方式需要维护某种类型的附加索引，以建立文件之间的层次结构。基于文件的存储方式特点：无法获取xml文档中结构化数据；通过附加索引可以定位具有某些关键字的xml文档，一旦关键字不能确定，将很难定位；查询时，只能以原始文档的形式返回，既不能获取文档内部信息；文件管理存在容量大、管理难的缺点。

2> 数据库存储方式：数据库在数据管理方面具有管理方便、存储占用空间小、检索速度较快、修改效率高和安全性好等优点。一种比较自然的想法是采用数据库对xml文档进行存取和操作，这样可以利用相对程序的数据库技术处理文档内部的数据。数据库存储方式的特点：能够管理结构化和半结构化数据；具有管理和控制整个文档集合本身的能力；可以对文档内部的数据进行操作；具有数据库技术的特性，如多用户、并发控制和一致性约束等；管理方便，易于操作。

4.3.5 ORM

ORM，Object-Relational-Mapping，对象与关系数据之间的映射。

1> 映射关系表

2> 实现技术对比

物联网可以分为三个层次，底层是用来感知数据的感知层，即利用传感器、二维码、FRID等设备随时随地获取物体的信息；第二层是数据传输处理的网络层，即通过各种传感网络与互联网的融合，将对象当前的信息实时准确地传递出去；第三层则是与行业需求结合的应用层，即通过智能计算、云计算等将对象进行智能化控制。

感知层用于识别物体、采集信息。感知层包括二维码标签和识读器、RFID标签和读写器、摄像头、GPS、传感器、M2M终端、传感器网关等，主要功能是识别对象、采集信息，与人体结构中皮肤和五官作用类似，感知层解决的是人类世界和物理世界的数据获取问题。

网络层用于传递信息和处理信息。网络层包括通信网与互联网的融合网络、网络管理中心、信息中心和智能处理中心等。网络层将感知层获取的信息进行传递和处理，类似于人体结构中的神经中枢和大脑。网络层解决的是传输和预处理感知层所获得数据的问题。

应用层实现广泛智能化。应用层是物联网与行业专业技术的深度融合，结合行业需求实现行业智能化，这类似于人们的社会分工。

物联网应用层利用经过分析处理的感知数据，为用户提供丰富的特定服务。应用层解决的是信息处理和人机交互的问题。

1> 两层C/S架构：客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件为维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。

2> 三层C/S架构：将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上，即将两层C/S架构中的数据从服务器中独立出来。

3> 三层B/S架构：是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称0客户端架构，虽然不用开发客户端，但有很多缺点。

MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了三个核心模块：控制器、模型、视图。

4.6.1 三要素

1> 模型（Model）：模型层是应用程序的主体部分，用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据，模型表示业务数据和业务逻辑，一个模型通常可为多个视图提供数据，以提高用用的可重用性。

2> 视图（View）：视图是程序中处理数据显示的部分，通常视图是依据模型数据创建的，是用户看到并与之交互的界面，视图向用户显示相关的数据，并能接受用户的输入数据，但是它并不进行任何实际的业务处理。

3> 控制器（Controller）：控制器是程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据，是用户界面和模型的接口，其解释视图的输入，将其解释为系统能够理解的对象，同时识别用户运作，将其解释为对模型特定的方法调用，并且负责处理来自模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

4.6.2 MVC特点

MVC分层有助于管理复杂的应用程序，因为可以在一个时间内专门关注一个方面，例如，可以在不依赖业务逻辑的情况下专注于视图设计，同时也让应用程序的测试更加容易。

MVC分层同时也简化了分组开发，不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

MVC不是一种严格的层次架构风格（要求只能与相邻层次发生对接），模型和视图之前是有沟通的，是跨越了控制层的。

4.6.3 J2EE

J2EE是MVC的一个重要应用场景，模型层一般使用EJB，如Entity Bean、Session Bean，视图层一般使用JSP，控制层一般使用Servlet。

4.6.3.1 J2EE四层架构

客户层组件：J2EE应用程序可以是基于web方式的，也可以是基于传统方式的静态HTML页面和Applets，是客户层组件。

web层组件：J2EE web层组件可以使JSP页面或Servlet。

业务层组件：业务层代码的逻辑用来满足特定领域的业务逻辑处理。

信息系统层：企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划（ERP），大型机事务处理，数据库系统，和其他的遗留信息系统。例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。

4.6.3.2 JSP+Servlet+JavaBean+DAO

JSP：用于显示、搜集数据的部分，作为MVC中的视图V。

Servlet：作为业务逻辑层，用于处理复杂的业务逻辑，如验证数据、实例化JavaBean、调用DAO连接数据库等，作为MVC中控制器C，在其中会调用Service方法处理服务。

JavaBean：用于数据的封装，方便将查询结果在Servlet与JSP页面之间进行传递等。

DAO：用于连接数据库及进行数据库操作如：查询、删除、更改等。

DAO与JavaBean合在一起为MVC中的模型M。

基本流程：JSP发一个数据到Servlet，servlet收到后做下解析再根据数据调用相应的service去服务，service如果要调用数据库就通过DAO跟数据库交互，使用JavaBean完成封装，返回结果给servlet，servlet再返回给JSP。

MVP是MVC的变种，其最大的改进是在MVC基础上做了严格的分层，视图只与解释器做交互，模型至于解释器交互，模型与视图之间没有交互。其优点包括：

1> 模型与视图完全分离，可以修改视图而不影响模型；

2> 可以高效地使用模型，因为所有交互都发生在一个地方（Presenter）内部；

3> 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑；

4> 如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）。

MVP是以传统的消息反馈机制完成的，MVVM从结构上讲与传统一样，但是提出了数据绑定的理念，完成数据的双向绑定也是MVVPN架构风格最显著的特征。

RIA称为富互联网风格，弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML试下的接口更加健壮，且有可视化内容，本质还是网络模式，其优点包括反应速度快、易于传播、交互性强。

1> RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；

2> RIA简化并改进了B/S架构的用户交互；

3> 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

SOA是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能，各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。

面向服务的架构约定在整个体系当中以服务的形式来完成相关的系统智能，相当于一个框架理念，它包含多个服务来协作完成。如何定义服务、如何去协调服务和定义服务标准是没有明确的定义的。

Web Service对其服务结构和交互协议进行了明确的规定，所以WebService本质上是一种技术。其主要包含三种角色：服务请求者、服务提供者、服务注册中心。如下是Web Service常用到的协议：

WSDL：WebService接口对应的WSDL文件，该文件通过xml格式说明如何调用，可以看作WebService的接口文档（使用说明书）。

REST，Representational State Transfer，表述性状态转移是一种通常使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

网页开发中一直存在着浏览器与服务器交互的问题，早期的交互主要是通过GET完成的，这样在服务端就需要有多重接口来区分不同的操作，导致接口数量较多，占用的资源也较多。REST就是将命令丰富化，不同命令对同一个接口进行操作时完成不同的功能，这样就减少了接口数量、节省了资源。REST有以下5个原则：

1> 网络上所有的事物都被抽象为资源；

2> 每个资源对应一个唯一的资源标识；

3> 通过通用的连接件接口对资源进行操作；

4> 对资源的各种操作不会改变资源标识；

5> 所有的操作都是无状态的。

ESB是企业服务总线，简单来说是一根管道，用来连接各个服务节点，ESB的存在时为了集成不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。

ESB解决的主要问题是各个服务系统之前的对接问题，只需要转换到对接ESB上即可。

5.3.1 ESB特点

1> SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合；

2> 描述服务的元数据和服务注册管理；

3> 在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；

4> 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求和服务提供者，提高对安全的支持、服务质量保证、客观理性和负载平衡等。

5.3.2 ESB主要功能

1> 提供位置透明性的消息路由和寻址服务；

2> 提供服务注册和命名的管理功能；

3> 支持多种消息传递泛型；

4> 支持多种可以广泛使用的传输协议；

5> 支持多种数据格式及其相互转换；

6> 提供日志和监控功能。

微服务，顾名思义，就是小服务，属于面向服务架构的一种。

5.4.1 微服务优缺点

5.4.2 微服务架构模式方案

5.4.3 微服务与SOA区别

微服务本质上是从SOA演化而来：

1> 微服务比SOA更精细，可以独立进程方式存在；

2> 微服务接口更通用化，如用HTTP RESTful，各种终端都可调用，语言无关，平台无关；

3> 更倾向于分布式部署，互联网场景更合适。

云计算是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相分离的，云计算应用所需的计算与存储通常在云端完成，客户端需要通过互联网访问计算与存储能力。

云计算概念的内涵包含两个方面：平台和应用。平台即基础设施，其地位相当于PC上的操作系统，云计算应用程序需要构建在平台之上。

优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低（前期投入低、综合使用成本也低）

1> 软件即服务SaaS：在SaaS的服务模式下，服务提供商将应用软件统一部署在云计算平台上，客户根据需要通过互联网向服务提供商订购应用软件服务，服务提供商根据客户所订购软件的数量、时间的长短等因素收费，并且通过标准浏览器向客户提供应用服务。

2> 平台即服务PaaS：在PaaS模式下，服务提供商将分布式开发环境与平台作为一种服务来提供，这是一种分布式平台服务，厂商提供开发环境、服务器平台、硬件资源等服务给客户，客户在服务提供商平台的基础上定制开发自己的应用程序，并通过其服务器和互联网传递给其他客户。

3> 基础设施及服务IaaS：在IaaS模式下，服务提供商将堕胎服务器组成的云端基础设施作为计量服务提供给客户，具体来说，服务提供商将内存、I/O设备、存储和计算能力等整合为一个虚拟的资源池，为客户提供所需要的存储资源、虚拟化服务器等服务。

在灵活性方面：SaaS、PaaS、I阿aS灵活性依次增强；

在方便性方面：IaaS、PaaS、SaaS方便性依次增强。

1> 公有云：在公有云模式下，云基础设施是公开的，可以自由地分配给公众、企业、学术界与政府机构，它们都可以拥有和管理公有云，并实现对公有云的操作。公有云能够以低廉的价格为最终用户提供有吸引力的服务，创造新的业务价值。

2> 社区云：在社区云模式下，云基础设施分配给一些社区组织所专有，这些组织共同关注任务、安全需求、政策等信息。云基础设施被社区内的一个或多个组织所拥有、管理及操作。社区云是公有云范畴内的一个组成部分。

3> 私有云：在私有云模式下，云基础服务设施分配给由多种用户组成的单个组织，它可以被这个组织或其他第三方组织所拥有、管理及操作。

4> 混合云：混合云是公有云、私有云和社区云的组合，由于安全和控制原因，并非所有的企业信息都能放置在公有云上，因此企业将会使用混合云模式。

管理层对云计算对外提供服务的各个层级都可以提供管控；

用户访问层为了方便使用云计算的服务而提供的用户访问接口；

资源层对应IaaS、平台层对应PaaS、应用层对应SaaS。应用层负责提供软件服务如财务管理、客户关系管理、商业智能等，平台层为用户提供对资源层服务的封装以使用户可以构建自己的应用，资源层提供虚拟化资源从而隐藏物理资源的负责性。

云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系，其本质是从Oncloud到Incloud，即诞生于云之上。

1> 服务化原则：使用微服务；

2> 弹性原则：可以根据业务变化自动伸缩；

3> 可观测原则：通过日志、链路跟踪和度量；

4> 韧性原则：面对异常的抵御能力；

5> 所有过程自动化原则：自动化交付工具；

6> 零信任原则：默认不信任网络内部和外部的任何人/设备/系统，通过身份验证等检查机制进行服务请求接受；

7> 架构持续演进原则：业务高速迭代情况下的架构与业务平衡。

1> 服务化架构模式：典型代表微服务，服务拆分使维护压力大增，一般情况下都选该方式，面临其他专业问题时选择其他对应模式；

2> Mesh化架构模式：把中间框架（RPC、缓存、异步消息）从业务进程中分离，由Mesh进程完成；

3> Serverless模式：将部署这个动作从运维中收走，把应用整个运行都委托给云，非常适合于事件驱动的数据计算任务；

4> 存储计算分离模式：各类暂态数据如session用云服务保存；

5> 分布式事务模式：解决微服务模式中多数据源事务问题；

6> 可观测架构：包括Logging、Tracing、Metrics三个方面；

7> 事件驱动架构：本质上是一种应用/组件间的集成架构模式。

1> 庞大的单体应用：需要多人开发的业务模块，考虑通过服务化进行拆分，并让组织与架构匹配；

2> 单体应用硬拆为微服务：服务拆分要适度，小规模软件的服务拆分（为拆而拆）、数据依赖（服务间数据依赖）、性能降低；

3> 缺乏自动化能力的微服务：手动维护大量微服务是不现实的。

1> 微服务个体约束：每个微服务都是独立的，修改一个微服务不能影响另一个服务；

2> 微服务与微服务之前的横向关系：通过第三方服务注册中心来满足服务的可发现性；

3> 微服务与微服务之间的纵向约束：数据是微服务的私产，访问时需要通过微服务；

4> 全局视角下的微服务分布式约束：高效运维整个系统。

7.5.1 操作系统差异

7.5.2 部署差异

边缘计算是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台就近提供最近端服务，其本质是计算处理职能的本地化。

边缘计算将数据的处理、应用程序的运行甚至一些功能服务的实现，由网络中心下放到网络边缘的节点上。在网络边缘侧的智能网关上就近采集并且处理数据，不需要大量未处理的原生数据上传到远处的大数据平台。

采用边缘计算的方式，海量数据能够就近处理，大量的设备也能实现高效协同的工作，诸多问题迎刃而解。因此，边缘计算理论上可满足许多行业在敏捷性、实时性、数据优化、应用智能，以及安全与隐私保护等方面的关键需求。

边缘计算的业务本质是云计算在数据中心之外汇聚节点的延伸和演进，主要包括云边缘、边缘云和云化网关三类落地形态；以“边云协同”和“边缘智能”为核心能力发展方向；软件平台需要考虑导入云理念、云架构、云技术，提供端到端实时、协同式智能、可信赖、可动态重置等能力；硬件平台需要考虑异构计算能力。

1> 云边缘：是云服务在边缘侧的延伸，逻辑上仍是云服务，主要的能力提供依赖于云服务或需要与云服务紧密协同；

2> 边缘云：是在边缘侧构建中小规模云服务能力，边缘服务能力主要由边缘云提供；

3> 云化网关：以云化技术与能力重构原有嵌入式网关系统，云化网关在边缘侧提供协议/接口转换、边缘计算能力，部署在云侧的控制器提供边缘节点的资源调度、应用管理与业务编排等能力。

1> 联接性：联接性是边缘计算的基础，所联接物理对象的多样性及应用场景的多样性，需要边缘计算具备丰富的联接功能。

2> 数据第一入口：边缘计算作为物理世界到数字世界的桥梁，是数据的第一入口，拥有大量、实时、完整的数据，可基于数据全生命周期进行管理与价值创造，将更好地支撑预测性维护、资产向效率与管理等创新应用；

3> 约束性：边缘计算产品需适配工业现场相对恶劣的工作条件与运行环境，如防电磁、防尘、防爆、抗振动、抗电流/电压波动等。在工业互联场景下，对边缘计算设备的功耗、成本、空间也有较高的要求。

4> 分布性：边缘计算实际部署天然具备分布式特征，这要求边缘计算支持分布式计算与存储、实现分布式资源的动态调度与统一管理、支撑分布式智能、具备分布式安全等能力。

边缘计算与云计算各有所长，云计算擅长全局性、非实时、长周期的大数据处理与分析，能够在长周期维护、业务决策支撑等领域发挥优势；边缘计算更适用局部性、实时、短周期数据的处理与分析，能更好地支撑本地业务的实时智能化决策与执行。

边缘计算既靠近执行单元，更是云端所需要价值数据的采集和初步处理单元，可以更好地支撑云端应用；反之，云计算通过大数据分析优化输出的业务规则或模型可以下发到边缘侧，边缘计算基于新的业务规则或模型运行。

边云协同主要包括六种协同：

1> 资源协同：边缘计算提供计算、存储、网络、虚拟化等基础设施资源、具有本地资源调度管理能力，同时可与云端协同，接受并执行云端资源调度管理策略，包括边缘节点的设备管理、资源管理以及网络连接管理；

2> 数据协同：边缘节点主要负责现场/终端数据的采集，按照规则或数据模型对数据进行初步处理与分析，并将处理结果以及相关数据上传给云端，云端提供海量数据的存储、分析与价值挖掘；

3> 智能协同：边缘节点按照AI模型执行推理，实现分布式智能；云端开展AI的集中式模型训练，并将模型下发边缘节点；

4> 应用管理协同：边缘节点提供应用与部署环境，并对本节点多个应用的生命周期进行管理调度，云端主要提供应用开发、测试环境以及应用的生命周期管理能力；

5> 业务管理协同：边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例；云端主要提供按照客户需求实现应用/数字孪生/网络等业务编排能力；

6> 服务协同：边缘节点按照云端策略实现部分ECSaaS服务，通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务，云端主要提供SaaS服务在云端和边缘节点的服务分部策略，以及云端承担的SaaS服务能力。

智慧园区、安卓云与云游戏、视频监控、工业互联网、Cloud VR。