一、软件架构演化概论
软件架构的演化和维护的目的是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改。软件架构的演化和维护过程是一个不断迭代的过程,通过演化和维护,软件架构逐步得到完善,以满足用户需求。
软件架构的演化就是软件整体结构的演化,演化过程涵盖软件架构的全生命周期,包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。所以,人们通常说软件架构是演化来的,而不是设计来的。
软件架构定义是SA={组件,连接件,约束},这类软件架构演化主要关注的就是组件、连接件和约束的添加、修改与删除等。
-
组件是软件架构的基本要素和结构单元,表示系统中主要的计算元素、数据存储以及一些重要模块,当需要消除软件架构存在的缺陷、新增功能、适应新的环境时都涉及组件的演化。组件的演化体现在组件中模块的增加、删除或修改。
-
连接件是组件间的交互关系,多数情况下组件的演化牵涉到连接件的演化。连接件的演化体现在组件交互消息的增加、删除或改变。
-
约束是组件和连接件之间的拓扑关系和配置,它为组件和连接件提供额外数据支撑,可以是架构的约束数据,或架构的参数。
1、软件架构演化典型的分类方法
(1) 按照软件架构的实现方式和实施粒度分类:
①基于过程和函数的演化
②面向对象的演化
③基于组件的演化和基于架构的演化
(2) 按照研究方法将软件架构演化方式分为4类:
①第1类是对演化的支持,如代码模块化的准则、可维护性的支持(如内聚和耦合)、代码重构等;
②第2类是版本和工程的管理工具,如CVS和COCOMO;
③第3类是架构变换的形式方法,包括系统结构和行为变换的模型,以及架构演化的重现风格等;
④第4类是架构演化的成本收益分析决定如何增加系统的弹性。
(3) 针对软件架构的演化过程是否处于系统运行时期 ,将软架构演化分为静态演化 和动态演化。
-
静态演化发生在软件架构的设计、实现和维护过程中,软件系统还未运行或者处在运行停止状态。
-
动态演化发生在软件系统运行过程中。
2、软件架构演化时期
(1)设计时演化
设计时演化是指发生在体系结构模型和与之相关的代码编译之前的软件架构演化。
(2)运行前演化
运行前演化是指发生在编译之后、执行之前的软件架构演化,这时由于应用程序并未执行,修改时不用考虑应用程序的状态,但需要考虑系统的体系结构,且系统需要具有添加和删除组件的机制。
(3)有限制运行时演化
有限制运行时演化是指系统在设计时就规定了演化的具体条件,将系统置于"安全"模式下,演化只发生在某些特定约束满足时,可以进行一些规定好的演化操作。
(4)运行时演化
运行时演化是指系统的体系结构在运行时不能满足要求时发生的软件架构演化,包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。此时的演化是最难实现的。
3、静态演化
(1)静态演化需求
软件架构静态演化的需求是广泛存在的,可归结为两个方面:
①设计时演化需求。在架构开发和实现过程中对原有架构进行调整,保证软件实现与架构的一致性以及软件开发过程的顺利进行。
②运行前演化需求。软件发布之后由于运行环境的变化,需要对软件进行修改升级,在此期间软件的架构同样要进行演化。
(2)静态演化的一般过程
软件静态演化是系统停止运行期间的修改和更新,即一般意义上的软件修复和升级。与此时相对应的维护方法有三类:更正性维护、适应性维护、完善性维护。软件的静态演化包括如下5个步骤:
①软件理解:查阅软件文档,分析软件架构,识别系统组成元素及其之间的相互关系,提取系统的抽象表示形式。
②需求变更分析:静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的,需要找出新的软件需求与原有的差异。
③演化计划:分析原系统,确定演化范围和成本,选择合适的演化计划。
④系统重构:根据演化计划对系统进行重构,使之适应当前的需求。
⑤系统测试:对演化后的系统进行测试,查找其中的错误和不足。
4、动态演化
动态演化是在系统运行期间的演化,在不停止系统功能的情况下完成演化,较之静态演化更加困难。具体发生在有限制的运行时演化和运行时演化阶段。
(1) 软件动态性的等级
软件的动态性分为3个级别:
-
交互动态性 :要求数据在固定的结构下动态交互。
-
结构动态性 :允许对结构进行修改,通常形式是组件和连接件实例的添加和删除,这种动态性是研究和应用的主流。
-
架构动态性 :允许软件架构的基本构造变动,即结构可以被重定义,如新的组件类型的定义。
(2) 动态演化的内容
根据所修改的内容不同,软件的动态演化包括以下4个方面:
-
属性改名 :目前所有的ADL都支持对非功能属性的分析和规约,而在运行过程中,用户可能会对这些指标进行重新定义(如服务响应时间)。
-
行为变化 :在运行过程中,用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。如,为了提高安全级别而更换加密算法;将HTTP协议改为HTTPS协议。
-
拓扑结构改变 :如增删组件,增删连接件,改变组件与连接件之间的关联关系等。
-
风格变化:一般软件演化后其架构风格应当保持不变,如果非要改变软件的架构风格也只能将架构风格变为衍生风格。如将两层C/S结构调整为三层C/S结构等。
二、软件架构演化原则
列举 18 种软件架构可持续演化原则,并针对每个原则设计了相应的度量方案。每个方案都能紧抓该原则的本质,做到从架构方面提供有价值的信息,帮助对架构进行有效观察。
1、演化成本控制原则
● 原则名称:演化成本控制(ECC)原则。
● 原则解释:演化成本要控制在预期的范围之内,也就是演化成本要明显小于重新开发成本。
● 原则用途:用于判断架构演化的成本是否在可控范围内,以及用户是否可接受。
● 度量方案:CoE<<CoRD。
● 方案说明:CoE为演化成本,CoRD为重新开发成本,CoE远小于CoRD最佳。
2、进度可控原则
● 原则名称:进度可控原则。
● 原则解释:架构演化要在预期时间内完成,也就是时间可控。
● 原则用途:根据该原则可以规划每个演化过程的任务量;体现一种迭代、递增(持续演化)的演化思想。
● 度量方案:ttask=|Ttask-T'task|。
● 方案说明:某个演化任务的实际完成时间(Ttask)和预期完成时间(T'task)的时间差ttask越小越好。
3、风险可控原则
● 原则名称:风险可控原则。
● 原则解释:架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
● 原则用途:用于判断架构演化过程中各种风险是否易于控制。
● 度量方案:分别检验。
● 方案说明:时间风险、经济风险、人力风险、技术风险都不存在。
4、主体维持原则
● 原则名称:主体维持原则
● 原则解释:对称稳定增长(AIG)原则所有其他因素须与软件演化协调,开发人员、销售人员、用户必须熟悉软件演化的内容,从而达到令人满意的演化。因此,软件演化的平均增量的增长须保持平稳,保证软件系统主体行为稳定。
● 原则用途:用于判断架构演化是否导致系统主体行为不稳定。
● 度量方案:计算AIG即可,AIG = 主体规模的变更量 / 主体的规模。
● 方案说明:根据度量动态变更信息(类型、总量、范围) 来计算
5、系统总体结构优化原则
● 原则名称:系统总体结构优化原则。
● 原则解释:架构演化要遵循系统总体结构优化原则,使得演化之后的软件系统整体结构(布局)更加合理。
● 原则用途:用于判断系统整体结构是否合理,是否最优。
● 度量方案:检查系统的整体可靠性和性能指标。
● 方案说明:判断整体结构优劣的主要指标是系统的可靠性和性能。
6、平滑演化原则
● 原则名称:平滑演化(IWR)原则
● 原则解释:在软件系统的生命周期里,软件的演化速率趋于稳定,如相邻版本的更新率相对固定。
● 原则用途:用于判断是否存在剧烈架构演化。
● 度量方案:计算IWR即可,IWR = 变更总量 / 项目规模。
● 方案说明:根据度量动态变更信息(类型、总量、范围等)来计算。
7、目标一致原则
● 原则名称:目标一致原则
● 原则解释:架构演化的阶段目标和最终目标要一致。
● 原则用途:用于判断每个演化过程是否达到阶段目标,所有演化过程结束是否能达到最终目标。
● 度量方案:otask=|Otask - O'task|。
● 方案说明:阶段目标的实际达成情况(Otask)和预期目标(O'task)的差otask越小越好。
8、模块独立演化原则
● 原则名称:模块独立演化原则,或修改局部化原则。
● 原则解释:软件中各模块(相同制品的模块,如Java的某个类或包)自身的演化最好相互独立,或者至少保证对其他模块的影响比较小或影响范围比较小。
● 原则用途:用于判断每个模块自身的演化是否相互独立。
● 度量方案:检查模块的修改是否是局部的。
● 方案说明:可以通过计算修改的影响范围来进行度量。
9、影响可控原则
● 原则名称:影响可控原则。
● 原则解释:软件中一个模块如果发生变更,其给其他模块带来的影响要在可控范围内也就是影响范围可预测。
● 原则用途:用于判断是否存在对某个模块的修改导致大量其他修改的情况。
● 度量方案:检查影响的范围是否可控。
● 方案说明:通过计算修改的影响范围来进行度量。
10、复杂性可控原则
● 原则名称:复杂性可控(CC)原则。
● 原则解释:架构演化必须要控制架构的复杂性,从而进一步保障软件的复杂性在可控范围内。
● 原则用途:用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。
● 度量方案:CC小于某个阈值。
● 方案说明:CC增长可控。
11、有利于重构原则
● 原则名称:有利于重构原则。
● 原则解释:架构演化要遵循有利于重构原则,使得演化之后的软件架构更方便重构。
● 原则用途:用于判断架构易重构性是否得到提高。
● 度量方案:检查系统的复杂度指标。
● 方案说明:系统越复杂越不容易重构。
12、有利于重用原则
● 原则名称:有利于重用原则。
● 原则解释:架构演化最好能维持,甚至提高整体架构的可重用性。
● 原则用途:用于判断整体架构可重用性是否遭到破坏。
● 度量方案:检查模块自身的内聚度、模块之间的耦合度。
● 方案说明:模块的内聚度越高,该模块与其他模块之间的耦合度越低,越容易重用。
13、设计原则遵从性原则
● 原则名称:设计原则遵从性原则。
● 原则解释:架构演化最好不能与架构设计原则冲突。
● 原则用途:用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结,要保障其得到充分使用)。
● 度量方案:RCP =∣CDP ∣/∣D**P∣。
● 方案说明:冲突的设计原则集合(CDP)和总的设计原则集合(DP)的比较,RCP越小越好。
14、适应新技术原则
● 原则名称:适应新技术(TI)原则。
● 原则解释:软件要独立于特定的技术手段,这样才能够让软件运行于不同平台。
● 原则用途:用于判断架构演化是否存在对某种技术依赖过强的情况。
● 度量方案:T**I =1−DD**T ,DD**T=∣依赖的技术集合∣/∣用到的技术合集∣。
● 方案说明:根据演化系统对关键技术的依赖程度进行度量。
15、环境适应性原则
● 原则名称:环境适应性原则。
● 原则解释:架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。
● 原则用途:用于判断架构在不同环境下是否仍然可使用,或者容易进行环境配置。
● 度量方案:硬件/软件兼容性。
● 方案说明:结合软件质量中兼容性指标进行度量。
16、标准依从性原则
● 原则名称:标准依从性原则。
● 原则解释:架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。
● 原则用途:用于判断架构演化是否具有规范性,是否有章可循;而不是胡乱或随意地演化。
● 度量方案:需要人工判定。
17、质量向好原则
● 原则名称:质量向好(QI)原则。
● 原则解释:通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意,例如可靠性提高了。
● 原则用途:用于判断架构演化是否导致某些质量指标变得很差。
● 度量方案:EQI>SQ。
● 方案说明:演化之后的质量(EQI)比原来的质量(SQ)要好。
18、适应新需求原则
● 原则名称:适应新需求原则。
● 原则解释:架构演化要容易适应新的需求变更;架构演化不能降低原有架构适应新需求的能力;架构演化最好可以提高适应新需求的能力。
● 原则用途:用于判断演化之后的架构是否降低了架构适应新需求的能力。
● 度量方案:RNR =∣A**NR ∣/∣NR∣。
● 方案说明:适应的新需求集合(ANR)和实际新需求集合(NR)的比较,RNR越小越好。
三、软件架构演化评估方法
根据演化过程是否已知可将评估过程分为:
① 演化过程已知的评估
② 演化过程未知的评估
1、演化过程已知的评估
演化过程已知的评估其目的在于通过对架构演化过程进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化,对该演化过程中相关质量属性进行评估。涉及评估流程以及具体的相关指标的计算方法。
(1)评估流程
架构演化评估的基本思路是将架构度量应用到演化过程中,通过对演化前后的不同版本的架构分别进行度量,得到度量结果的差值及其变化趋势,并计算架构间质量属性距离,进而对相关质量属性进行评估。
(2)架构演化中间版本度量
对于不同类型的质量属性,其度量方法不同,度量结果的类型也不同。本章主要度量的是架构的可维护性和可靠性。
对于可靠性,度量结果是一个实数值。
对于可维护性,它包含圈复杂度、扇入扇出度、模块间耦合度、模块的响应、紧内聚度、松内聚度等6个子度量指标。通过比较原子演化前后架构质量属性Qi-1和Qi间的变化,可以分析该类演化对评估系统的外部质量属性的影响,进而找出架构内部结构变化和外部质量属性变化间的关联。
2、演化过程未知的评估
演化过程未知时,我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化,只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变,并分析这些改变与架构相关质量属性的关联关系。即以结果为导向去查。
四、大型网站系统架构演化
| 要素 | 技术要点 |
|---|---|
| 从架构来看 | MVC, MVP, MVVM, REST, Webservice, 微服务。 |
| 从缓存来看 | 集群(负载均衡)、CDN |
| 从并发分流来看 | MemCache, Redis, Squid |
| 从数据库来看 | 主从库(主从复制),内存数据库,反规范化技术,NoSQL,分区(分表)技术,视图与物化视图。 |
| 从持久化来看 | Hibernate, Mybatis |
| 从分布存储来看 | Hadoop, FastDFS,区块链。 |
| 从数据编码看 | XML,JSON |
| 从Web应用服务器来看 | Apache, WebSphere, Weblogic, Tomcat, JBOSS, IIS。 |
| 从安全来看 | SQL注入攻击 |
| 其他 | 静态化,有状态与无状态,响应式Web设计、中台 |
1、第一阶段:单体架构
小型网站最开始没有太多人访问,只需要一台服务器就绰绰有余,这时网站的应用程序、数据库、文件等所有资源都在一台服务器上。

2、第二阶段:垂直架构
将应用和数据分离,整个网站使用3台服务器的:应用服务器、文件服务器和数据库服务器。

-
应用服务器处理大量的业务逻辑,因此需要更快更强大的处理器速度。
-
数据库服务器需要快速磁盘检索和数据缓存,因此需要更快的磁盘和更大的内存。
-
文件服务器需要存储大量用户上传的文件,因此需要更大容量的硬盘。
3、第三阶段:使用缓存改善网站性能
把经常访问的小部分数据缓存在内存中,可以减少数据库的访问压力,提高整个网站的数据访问速度,改善数据库的写入性能。

网站使用的缓存可分为两种:
● 缓存在应用服务器上的本地缓存
● 缓存在专门的分布式缓存服务器上的远程缓存使用缓存后,数据访问压力得到有效缓解,但是单一应用服务器能够处理的请求连接有限,在网站访问高峰期,应用服务器成为整个网站的瓶颈。
缓存技术:
⚡ MemCache:Memcache是一个高性能的分布式的内存对象缓存系统,用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。
⚡ Redis:Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。
⚡ Squid:Squid是一个高性能的代理缓存服务器,Squid支持FTP,gopher、HTTPS和HTTP协议。和一般的代理缓存软件不同,Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。
| 比较项 | Memcache | Redis |
|---|---|---|
| 数据类型 | 简单Key/Value结构 | 不仅仅支持简单的k/v类型的数据,同时还提供list,set,hash等数据结构的存储 |
| 持久性 | 不支持 | 支持(所以一旦服务器挂掉,Redis数据丢失还可以恢复) |
| 分布式存储 | Memcache服务器需要通过hash一致化来支撑主从结构(从的服务器内容各不相同) | 多种方式,主从、sentinel、cluster等 |
| 多线程支持 | 支持 | redis把任务封闭在一个线程中,不支持多线程 |
| 内存管理 | 使用stab Allcation进行内存管理,按照既定的内存,将内存切割成特定的长度来存储相应的数据 | 无 |
| 事务支持 | 弱支持,只能保证事务中的每个操作连续执行 | 有限支持 |
| 数据容灾 | 不支持,不能做数据恢复 | 支持,可以在灾难发生时,恢复数据。 |

| Redis集群切片方式 | |
|---|---|
| 客户端分片 | 在客户端通过Key的hash值对应到不同的服务器 |
| 中间件分片 | 在应用软件和Redis中间由中间件实现服务到后台redis节点的路由分派 |
| 客户端服务端协作分片 | redisCluter模式,客户端采用一致性哈希,服务端提供错误节点的重定向服务slot上。不同的slot对应到不同服务器。 |
| Redis分布式存储方案 | |
|---|---|
| 主从模式 | 一主多从,故障时手动切换。 |
| 哨兵模式 | 有哨兵的一主多从,主节点故障自动选择新的主节点。 |
| 集群模式 | 分节点对等集群,分slots,不同slots的信息存储到不同节点 |
| Redis数据分片方案 | 说明 |
|---|---|
| 范围分片 | 按数据范围值(0-60,61-80,81-100) |
| 哈希分片 | 通过key进行hash运算分片(类似于取余),余数相同放在一个实例。 |
| 一致性哈希分片 | 利用扩展结点,可以有效解决重新分配结点带来的无法命中问题。哈希分片的改进(有效解决hash无法命中问题) |
| Redis数据类型 | 特点 | 实例 |
|---|---|---|
| String(字符串) | 存放二进制如缓存 | 缓存、计数、共享session |
| Hash(字典) | 无序字典,数组+链表,适合存储对象key对应一个HashMap,针对一组数据。 | 存储、读取、修改用户属性 |
| List(列表) | Linked List:双向链表,有序,增删快,查询慢。Array List:数组方式,有序,增删慢,查询快。 | 消息队列,文章列表;记录前N个最新登录的用户ID列表 |
| Set(集合) | 键值对无序,唯一。支持并、交、差集操作 | 独立IP,共同爱好,标签。 |
| Sorted Set(有序集合) | 键值对,有序,自带按权重排序效果 | 排行榜 |
| Redis淘汰策略 | 机制名 | 策略 |
|---|---|---|
| 不淘汰 | noeviction | 禁止驱逐数据,内存不足以容纳新数据时,新写入操作就会报错。系统默认的一种淘汰策略。 |
| 设置了过期时间的键空间 | 1、volatile-random 2、volatile-lru 3、volatile-ttl | 1、随机移除某个key。 2、优先移除最近未使用的key。 3、ttl值小的key优先移除。 |
| 全键空间 | 1、allkeys-random 2、allkeys-lru | 1、移除某个key。 2、优先移除最近未使用的key。 |
Redis提供了两种持久化存储的机制,分别是RDB (Redis DataBase)持久化方式和AOF (Append Only File)持久化方式。RDB持久化方式是指在指定的时间间隔内将内存中的数据集快照写入磁盘,是Redis默认的持久化方式。AOF方式是指redis会将每一个收到的写命令都通过write函数追加到日志文件中。 两种方式各有优缺点,大致的比较如下:
(1) 磁盘更新频率:AOF比RDB文件更新频率高。
(2) 数据安全:AOF比RDB更安全。
(3) 数据一致性:RDB间隔一段时间存储,可能发生数据丢失和不一致;AOF通过append模式写文件,即使发生服务器宕机,也可通过redis-check-aof工具解决数据一致性问题。
(4) 重启性能:RDB性能比AOF好。
(5) 数据文件大小:AOF文件比RDB文件大。
该项目的实际需求是:在系统出现宕机等故障时,需要在最短时间内通过重启等方式重新建立服务,因此重启性能是最需要考虑的因素,故该开发团队选择RDB方式。
4、第四阶段:服务集群

使用服务集群改善网站并发处理能力通过增加服务器的方式改善负载压力、提高系统性能,从而实现系统的可伸缩性。应用服务器集群是网站可伸缩架构设计中较为简单成熟的一种。
(1)服务集群阶段会产生的问题
①用户的请求由谁来转发到具体的应用服务器?应该发给哪个服务器进行响应请求?
②用户如果每次访问的服务器不一样,那么如何维护session的一致性?
解决方法:
1.客户端:cookie携带session
2.集群服务器之间同步session
3.将session存入redis。
(2)服务集群带来两个问题
①负载均衡
负载均衡组件:keepalived。健康检查和失败切换是keepalived的两大核心功能。所谓的健康检查,就是采用tcp三次握手,icmp请求,http请求,udp echo请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行主要是应用于配置了主备模式的负载均衡器,利用VRRP维持主备负载均衡器的心跳,当主负载均衡器出现问题时,由备负载均衡器承载对应的业务,从而在最大限度上减少流量损失,并提供服务的稳定性。Nginx、lvs、zookeeper等。


静态均衡算法:(不考虑动态负载)

1.轮询法:将请求按顺序轮流地分配到每个节点上,不关心每个节点实际的连接数和当前的系统负载。
● 优点:简单高效,易于水平扩展,每个节点满足字面意义上的均衡;
● 缺点:没有考虑机器的性能问题,根据木桶最短木板理论,集群性能瓶颈更多的会受性能差的服务器影响。
2.随机法:将请求随机分配到各个节点。由概率统计理论得知,随着客户端调用服务端的次数增多,其实际效果越来越接近于平均分配,也就是轮询的结果。优缺点和轮询相似。
3.源地址(目标地址)哈希法:源地址哈希的思想是根据客户端的IP地址,通过哈希函数计算得到一个数值,用该数值对服务器节点数进行取模,得到的结果便是要访问节点序号。采用源地址哈希法进行负载均衡,同一IP地址的客户端,当后端服务器列表不变时,它每次都会落到到同一台服务器进行访问。目标地址哈希算法:根据请求目标IP做散列找到对应结点。
● 优点:相同的IP每次落在同一个节点,可以人为干预客户端请求方向,例如灰度发布;
● 缺点:如果某个节点出现故障,会导致这个节点上的客户端无法使用,无法保证高可用。当某一用户成为热点用户,那么会有巨大的流量涌向这个节点,导致冷热分布不均衡,无法有效利用起集群的性能。所以当热点事件出现时,一般会将源地址哈希法切换成轮询法。
4.加权轮询法:不同的后端服务器可能机器的配置和当前系统的负载并不相同,因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重,让其处理更多的请;而配置低、负载高的机器,给其分配较低的权重,降低其系统负载,加权轮询能很好地处理这一问题,并将请求顺序且按照权重分配到后端。
加权轮询算法要生成一个服务器序列,该序列中包含n个服务器。n是所有服务器的权重之和。在该序列中,每个服务器的出现的次数,等于其权重值。并且,生成的序列中,服务器的分布应该尽可能的均匀。比如序列 {a, a, a, a, a, b, c} 中,前五个请求都会分配给服务器a,这就是一种不均匀的分配方法,更好的序列应该是:{a, a, b, a, c, a, a}。
● 优点:可以将不同机器的性能问题纳入到考量范围,集群性能最优最大化;
● 缺点:生产环境复杂多变,服务器抗压能力也无法精确估算,静态算法导致无法实时动态调整节点权重,只能粗糙优化。
5.加权随机法:与加权轮询法一样,加权随机法也根据后端机器的配置,系统的负载分配不同的权重。不同的是,它是按照权重随机请求后端服务器,而非顺序。
6.键值范围法:根据键的范围进行负载,比如0到10万的用户请求走第一个节点服务器,10万到20万的用户请求走第二个节点服务器......以此类推。
● 优点:容易水平扩展,随着用户量增加,可以增加节点而不影响旧数据;
● 缺点:容易负载不均衡,比如新注册的用户活跃度高,旧用户活跃度低,那么压力就全在新增的服务节点上,旧服务节点性能浪费。而且也容易单点故障,无法满足高可用。
动态负载均衡算法:(考虑动态负载)
1.最小连接数法:根据每个节点当前的连接情况,动态地选取其中当前积压连接数最少的一个节点处理当前请求,尽可能地提高后端服务的利用效率,将请求合理地分流到每一台服务器。俗称闲的人不能闲着,大家一起动起来。
● 优点:动态,根据节点状况实时变化;
● 缺点:提高了复杂度,每次连接断开需要进行计数;
2.加权最小连接算法:考虑结点处理能力不同,按最小连接数分配。
3.最快响应速度法:根据请求的响应时间,来动态调整每个节点的权重,将响应速度快的服务节点分配更多的请求,响应速度慢的服务节点分配更少的请求,俗称能者多劳,扶贫救弱。
● 优点:动态,实时变化,控制的粒度更细,跟灵敏;
● 缺点:复杂度更高,每次需要计算请求的响应速度;
● 实现:可以根据响应时间进行打分,计算权重。
4.观察模式法:观察者模式是综合了最小连接数和最快响应度,同时考量这两个指标数,进行一个权重的分配。
5.加权百分比法:考虑了节点的利用率、硬盘速率、进程个数等,使用利用率来表现剩余处理能力。
②有状态和无状态的问题
无服务状态:对单次请求的处理,不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到,服务器不存储任何信息。
有状态:它会自身保存一些数据,先后的请求是有关联的。
(a)Identification Bean(身份认证构件)
(b)ResPublish Bean(资源发布构件)
(c)ResRetrieval Bean(资源检索构件)
(d)OnlineEdit Bean(在线编辑构件)
(e)Statistics Bean(统计分析构件)
有状态构件包含:(a)、(b)、(d)
无状态构件包含:(c)、(e)
5、第五阶段:数据库读写分离
在网站的用户达到一定规模后,数据库因为负载压力过高而成为网站的瓶颈。目前的主流数据库提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。

应用服务器在写数据的时候,访问主数据库,主数据库通过主从复制(同步)机制将数据更新同步到从数据库,这样当应用服务器读数据的时候,就可以通过从数据库获得数据。
读写分离和主从复制策略
主从数据库结构特点:
1.设置物理上不同的主/从服务器,一般而言一主多从,也可以多主多从。
2.让主服务器负责数据的写操作,从服务器负责数据的读操作,从而有效减少数据并发操作的延迟,但是带来了数据不一致问题,因此需要采用主从复制策略保持数据的一致性。
MYSQL数据库,主从复制是通过binary log来实现主从服务器的数据同步,MYSQL数据库支持三种复制类型分别为基于SQL语句的复制、基于行的复制和混合。
数据同步方案有:
1.触发器 (当同步要求比较严格的时候);
2.一致性要求不严格 (定时器 );
3.数据库插件。
6、第六阶段:反向代理和 CDN 加速网站响应
随着网站业务不断发展,用户规模越来越大,由于区域的差别使得网络环境异常复杂,不同地区的用户访问网站时,速度差别也极大。为了更好的用户体验,网站需要加速网站访问速度。主要手段有使用CDN和反向代理。CDN和反向代理的基本原理都是缓存。

● CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据。
● 反向代理部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。
响应式Web设计 是一种网络页面设计布局,其理念是集中创建页面的图片排版大小,可能以智能地根据用户行为以及使用的设备进行相应的布局。
(1)流式布局和弹性化设计:使用相对单位,设定百分比而非具体值的方式设置页面元素的大小
(2)响应式图片:不仅要同比的缩放图片,还要在小设备上降低图片本身的分辨率。
(3)媒体查询
7、第七阶段:使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后,一台服务器拆分成两台服务器,但是随着网站业务的发展依然不能满足需求,这时需要使用分布式数据库。文件系统也一样,需要使用分布式文件系统。
分布式数据库是网站数据库拆分最后手段,只有在单表数据规模非常庞大的时候才使用。不到不得已时,网站更常用的数据库拆分手段是业务分库,将不同业务的数据部署在不同的物理服务器上。

8、第八阶段:使用NoSQL和搜索引擎
随着网站业务越来越复杂,对数据存储和检索的需求也越来越复杂,网站需要采用一些非关系数据库技术,如NoSQL和非数据库查询技术如搜索引擎。NoSQL和搜索引擎都是源自互联网的技术手段,对可伸缩的分布式特性具有更好的支持。

应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。
9、第九阶段:业务拆分
大型网站为了应对日益复杂的业务场景,通过使用分而治之的手段将整个网站业务分成不同的产品线。如电商网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线,分归不同的业务团队负责。具体到技术上,也会根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署。

应用之间可以通过一个超链接建立关系,也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个完整系统。
10、第十阶段:分布式服务
随着业务拆分越来越小,存储系统越来越庞大,应用系统的整体复杂度呈指数级增加,部署维护越来越困难。由于所有应用要和所有数据库系统连接,在数万台服务器规模的网站中,这些连接的数目是服务器规模的平方,导致数据库连接资源不足,拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。由这些可复用的业务连接数据库,提供共用业务服务,而应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成具体业务操作。
用户需求不断变化,所以只有以客户为中心,不断的迭代和试错的框架才能立于不败之地。
场景:客户需求:短视频、知识付费、社交平台......
技术跟进:Supercell(皇室战争、部落战争)不断试错,开发试错,阿里提出"大中台、小前台"的战略。
原理:多个项目相互独立会出现重复发明轮子的现象,项目越来越复杂,也让开发效率低下。这样用分层的思想提炼一个中间层为所有的项目提供一些公共资源,相当于战地指挥部、资源供给平台,要数据给数据、要技术给技术。这个中间层就是中台。
按照不同的功能和角色
● 业务中台: 支付中心、商品中心、营销中心、搜索中心、用户中心、交易中心。
● 技术中台: 向各个项目提成通用的底层框架、引擎、中间件(MQ、RPC框架、分布式事务、分布式缓存、容器等)。
● 算法中台: 语音识别、图像识别、搜索算法、推荐算法、人机对话、垃圾过滤等。
中台的适应场合
· 从0-1创业型公司,让项目野蛮生长即可,如果想耗费大量的资源去搭建中台,可能中台还没搭建好,公司已经饿死了。
· 1-N的阶段适合搭建中台,不仅为了活下去而是更好的生活。
· N-N+1搭建中台势在必行。
中台必须具备的4个核心能力:数据汇聚整合能力、数据提纯加工能力、数据服务可视化、价值变现方面。
案例分析:写出符合1~8各个层次的阶段类型

五、软件架构维护
软件架构是软件开发和维护过程中的一个重点制品,是软件需求和设计、实现之间的桥梁。软件架构的维护与演化密不可分,维护需要对软件架构的演化过程进行追踪和控制,以保障软件架构的演化过程能够满足需求(亦有说法将架构维护作为架构演化的一部分)。
由于软件架构维护过程一般涉及架构知识管理、架构修改管理和架构版本管理等内容,下面分别对它们进行介绍。
1、软件架构知识管理
软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示,进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑,并能够为其他软件架构的相关活动提供参考。
(1)架构知识的定义
架构知识 = 架构设计 + 架构设计决策。
(2)架构知识管理的含义
架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化,从架构文档等信息来源中捕捉架构知识,进而提供架构的质量属性及其设计依据以进行记录和评价。
2、软件架构修改管理
在软件架构修改管理中,一个主要的做法就是建立一个隔离区域,保障该区域中任何修改对其他部分的影响比较小,甚至没有影响。为此,需要明确修改规则、修改类型,以及可能的影响范围和副作用等。
3、软件架构版本管理
软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据,并为架构演化量化度量奠定了基础。
4、软件架构可维护性度量实践:
架构可维护性的六个子度量指标:
(1)圈复杂度(CCN)
由于在组件图中组件是独立的,每个组件代表一个系统或子系统中的封装单位,封装了完整的事务处理行为,组件图能够通过组件之间的控制依赖关系来体现整个系统的组成结构。
对架构的组件图进行圈复杂度的度量,可以对整个系统的复杂程度做出初步评估,在设计早期发现问题和做出调整,并预测待评估系统的测试复杂度,及早规避风险,提高软件质量。实践表明程序规模以 CCN≤10为宜。
例题:

解析:上图共有3个闭合的区间,即判定节点个数为3,所以CCN为:3+1=4
(2)扇入扇出度(FFC)
扇入是指直接调用该模块的上级模块的个数,扇出指该模块直接调用的下级模块的个数。

用扇入扇出度综合评估组件主动调用以及被调用的频率。扇入扇出度越大,表明该组件与其他组件间的接口关联或依赖关联越多。
(3)模块间耦合度(CBO)
模块间耦合度CBO度量模块与其他模块交互的频繁程度。
组件与其他组件的依赖关系及接口越多,该组件的耦合度越大。CBO越大的模块,越容易受到其他模块修改和错误的影响,因而可维护性越差,风险越高。
(4)模块的响应(RFC)
RFC度量组件执行所需的功能的数量,包括接口提供的功能、依赖的其他模块提供的功能以及子模块提供的功能。
(5)紧内聚度TCC和松内聚度LCC
内聚度是模块内部各成份之间的联系紧密程度,联系越紧其内聚度越大。好的架构设计应该遵循"高内聚-低耦合"原则,提高模块的独立性,降低模块间接口调用的复杂性。
六、未来新信息技术
1、信息物理系统
(1)信息物理系统的概念
信息物理系统(Cyber-Physical Systems,CPS)通过集成先进的感知、计算、通信、控制等信息技术和自动控制技术,构建了物理空间与信息空间中人、机、物、环境、信息等要素相互映射、适时交互、高效协同的复杂系统,实现系统内资源配置和运行的按需响应、快速迭代、动态优化。
CPS是在环境感知的基础上,深度融合计算、通信和控制能力的网络化物理设备系统,通过计算进程和物理进程相互影响的反馈循环实现深度融合和实时交互来增加或扩展新的功能,以安全、可靠、高效和实时的方式检测或者控制一个物理实体。
(2)CPS的实现
CPS的体系架构:
①单元级CPS是具有不可分割性的CPS最小单元,其本质是通过软件对物理实体及环境进行状态感知、计算分析,并最终控制到物理实体,构建最基本的数据自动流动的闭环,形成物理世界和信息世界的融合交互。同时,为了与外界进行交互,单元级CPS应具有通信功能。单元级CPS是具备可感知、可计算、可交互、可延展、自决策功能的CPS最小单元,一个智能部件、一个工业机器人或一个智能机床都可能是一个CPS最小单元。
②系统级CPS基于多个单元级CPS的状态感知、信息交互、实时分析,实现了局部制造资源的自组织、自配置、自决策、自优化。在单元级CPS功能的基础上,系统级CPS还包含互联万通、即插即用、边缘网关、数据互操作、协同控制、监视与诊断等功能。其中互连互通、边缘网关和数据互操作实现单元级CPS的异构集成。
③SoS级CPS的有机组合构成SoS级CPS。SoS级CPS主要实现数据的汇聚,从而对内进行资产的优化和对外形成运营优化服务。其主要功能包括:数据存储、数据融合、分布式计算、大数据分析、数据服务,并在数据服务的基础上形成了资产性能管理和运营优化服务。
(3)CPS的技术体系
CPS的技术体系分为四大核心技术要素:
● "一硬"(感知和自动控制),是CPS实现的硬件支撑;
● "一软"(工业软件),固化了CPS计算和数据流程的规则,是CPS的核心;
● "一网"(工业网络),互连互通和数据传输的网络载体;
● "一平台"(工业云和智能服务平台),CPS数据汇聚和支撑上层解决方案的基础,对外提供资源管控和能力服务。
2、人工智能和机器人
人工智能(Artificial Intelligence,AI)是利用数字计算机或者数字计算机控制的机器模拟延伸和扩展人的智能,感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
人工智能的目标是了解智能的实质,并生产出一种新的能以人类智能相似的方式做出反应的智能机器。该领域的研究包括机器人、自然语言处理、计算机视觉和专家系统等。根据人工智能是否能真正实现推理、思考和解决问题,可以将人工智能分为弱人工智能和强人工智能。
(1)弱人工智能
弱人工智能是指不能真正实现推理和解决问题的智能机器,这些机器表面看像是智能的,但是并不真正拥有智能,也不会有自主意识。
目前的主流研究仍然集中于弱人工智能,并取得了显著进步,如在语音识别、图像处理和物体分割、机器翻译等方面都取得了重大突破,某些方面甚至可以接近或超越人类水平。
(2)强人工智能
强人工智能是指真正能思维的智能机器,并且认为这样的机器是有知觉和有自我意识的,这类机器可分为类人(机器的思考和推理类似人的思维)与非类人(机器产生了和人完全不一样的知觉和意识,使用和人完全不一样的推理方式)两大类。
(3)人工智能关键技术
⚡ 自然语言处理 :研究实现人与计算机之间用自然语言进行有效通信的各种理论和方法。自然语言处理涉及的领域主要包括:机器翻译(利用计算机实现从一种自然语言到另外一种自然语言的翻译)、语义理解(利用计算机理解文本篇章内容,并回答相关问题)和问答系统(让计算机像人类一样用自然语言与人交流)等。
⚡ 计算机视觉 :是使用计算机模仿人类视觉系统的科学,让计算机拥有类似人类提取、处理、理解和分析图像以及图像序列的能力,将图像分析任务分解为便于管理的小块任务。自动驾驶、机器人、智能医疗等领域均需要通过计算机视觉技术从视觉信号中提取并处理信息。
⚡ 知识图谱 本质上是结构化的语义知识库,是一种由节点和边组成的图数据结构,以符号形式描述物理世界中的概念及其相互关系。知识图谱就是把所有不同种类的信息连接在一起而得的一个关系网络,提供了从"关系"的角度去分析问题的能力。知识图谱在搜索引擎、可视化展示和精准营销方面有很大的优势,已为业界的热门工具。可用于发欺诈、不一致性验证、组团欺诈等对公共安全保障形成威胁的领域。
⚡ 人机交互 主要研究人和计算机之间的信息交换,包括人到计算机和计算机到人的两部分信息交换,是人工智能领域重要的外围技术。人机交互是与认知心理学、人机工程学、多媒体技术、虚拟现实技术等密切相关的综合学科的交叉。人机交互技术除了传统的基本交互和图形交互外,还包括语音交互、情感交互、体感交互及脑机交互等技术。
⚡ 虚拟现实或增强现实 是以计算机为核心的新型视听技术。结合相关科学技术,在一定范围内生成与真实环境在视觉、听觉等方面高度近似的数字化环境。用户借助必要的装备与数字化环境中的对象进行交互,相互影响,获得近似真实环境的感受和体验,通过显示设备、跟踪定位设备、触力觉交互设备、数据获取设备、专用芯片等实现。
⚡机器学习 是人工智能的核心研究领域之一,其最初的研究动机是为了让计算机系统具有人的学习能力以便实现人工智能。具体来说,机器学习是以数据为基础,通过研究样本数据寻找规律,并根据所得规律对未来数据进行预测。目前,机器学习广泛应用于数据挖掘、计算机视觉、自然语言处理、生物特征识别等领域。
◆ 按学习模式不同分为监督学习 (需提供标注的样本集 )、无监督学习 (不需提供标注的样本集)、半监督学习 (需提供少量标注的样本集)、强化学习(需反馈机制)。
◆ 按学习方法不同分为传统机器学习(需手动完成)、深度学习(需大量训练数据集和强大GPU服务器提供算力)
◆ 机器学习常见算法:迁移学习、主动学习、演化学习。
(4)机器人
机器人的定义,具有如下3个条件的机器可以称为机器人:
(1) 具有脑、手、脚等三要素的个体;
(2) 具有非接触传感器(用眼、耳接收远方信息)和接触传感器;
(3) 具有平衡觉和固有觉的传感器。
机器人4.0有以下几个核心技术:
◆ 云-边-端的无缝协同计算
◆ 持续学习与协同学习
◆ 知识图谱
◆ 场景自适应
◆ 数据安全
机器人的分类:按照控制方式分类,机器人可分为操作机器人、程序器人、示教再现机器人、智能机器人、综合机器人
3、边缘计算&数字孪生体&云计算&大数据
(1)边缘计算
边缘计算的概念:ISO/IEC JTC1/SC38给出的边缘计算是一种将主要处理和数据存储放在网络边缘节点的分布式计算形式。
ETSI(欧洲电信标准协会):提供了移动网络边缘IT服务环境和计算能力,强调靠近移动用户,以减少网络操作和服务交付的时延,提高用户体验。本质 就是:计算处理职能本地化。

边缘计算的特点:
①联接性 :联接性是边缘计算的基础。所联接物理对象的多样性及应用场景的多样性需要边缘计算具备丰富的联接功能,如各种网络接口、网络协议、网络拓扑、网络部署与配置、网络管理与维护。
②数据第一入口 :边缘计算作为物理世界到数字世界的桥梁,是数据的第一入口。
③约束性:边缘计算产品需适配工业现场相对恶劣的工作条件与运行环境,对边缘计算设备的功耗、成本、空间有较高的要求。边缘计算产品需要考虑通过软硬件集成与优化,以适配各种条件约束,支撑行业数字化多样性场景。
④分布性:边缘计算实际部署天然具备分布式特征。这要求边缘计算支持分布式计算与存储、实现分布式资源的动态调度与统一管理、支撑分布式智能、具备分布式安全等能力。
边云协同,具体内容如下:
①资源协同:边缘节点提供计算、存储、网络、虚拟化等基础设施资源、具有本地资源调度管理能力,同时可与云端协同,接受并执行云端资源调度管理策略,包括边缘节点的设备管理、资源管理以及网络连接管理。
②数据协同:边缘节点主要负责现场/终端数据的采集,按照规则或数据模型对数据进行初步处理与分析,并将处理结果以及相关数据上传给云端;云端提供海量数据的存储、分析与价值挖掘。边缘与云的数据协同,支持数据在边缘与云之间可控有序流动,形成完整的数据流转路径,高效低成本对数据进行生命周期管理与价值挖掘。
③智能协同:边缘节点执行推理,实现分布式智能;云端开展模型训练,并将模型下发边缘节点。
④应用管理协同:边缘节点提供应用部署与运行环境,并对本节点多个应用的生命周期进行管理调度;云端主要提供应用开发、测试环境,以及应用的生命周期管理能力。
⑤业务管理协同:边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例;云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。
⑥服务协同:边缘节点按照云端策略实现部分ECSaaS服务,通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务;云端主要提供SaaS服务在云端和边缘节点的服务分布策略,以及云端承担的SaaS服务能力。
边缘安全的价值体现在以下几方面:
● 提供可信的基础设施
● 为边缘应用提供可信赖的安全服务
● 保障安全的设备接入和协议转换
● 提供安全可信的网络及覆盖
边缘计算应用场合
● 智慧园区
● 安卓云与云游戏
● 视频监控
● 工业物联网
● Cloud VR
(2)数字孪生体
数字孪生体 是现有或将有的物理实体对象的数字模型,通过实测、仿真和数据分析来实时感知、诊断、预测物理实体对象的状态,通过优化和指令来调控物理实体对象的行为,通过相关数字模型间的相互学习来进化自身,同时改进利益相关方在物理实体对象生命周期内的决策<。
数字孪生体的三项核心技术:
● 建模:是将我们对物理世界的理解进行简化和模型化。
● 仿真:建模和仿真是一对伴生体。建模是模型化我们对物理世界或问题的理解,仿真就是验证和确认这种理解的正确性和有效性。所以,数字化模型的仿真技术是创建和运行数字孪生体、保证数字孪生体与对应物理实体实现有效闭环的核心技术。
● 基于数据融合的数字线程:目前VR、AR以及MR等增强现实技术、数字线程、系统工程和MBSE、物联网、云计算、雾计算、边缘计算、大数据技术、机器学习和区块链技术,仍为数字孪生体构建过程中的内外围核心技术。
(3)云计算
云计算是分布式计算的一种,指通过网络"云"将巨大的数据计算处理程序分解成无数个小程序,通过多部服务器组成的系统进行处理和分析这些小程序,得到结果后返回给用户。云计算早期就是简单的分布式计算,解决任务分发,并进行计算结果的合并。现阶段所说的云服务已经不单单是一种分布式计算,而是分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗余和虚拟化等计算机技术混合演进、跃升的结果。(腾讯云、阿里云、华为云等)
云计算的服务方式:
● SaaS (软件即服务 )用户根据自己实际需求,通过互联网向厂商订购所需的应用软件服务,按定购的服务多少或时间长短向厂商支付费用,并通过标准浏览器向客户提供应用服务。
● PaaS (平台即服务 )在PaaS模式下,服务提供商将分布式开发环境与平台作为一种服务来提供。厂商提供开发环境、服务器平台、硬件资源等服务给客户,客户在服务提供商平台的基础上定制开发自己的应用程序。
● IaaS (基础设施即服务 )IaaS模式下,服务提供商将内存、I/O设备、存储和计算能力等整合为一个虚拟的资源池,为客户提供所需要的存储资源、计算资源、虚拟化服务器等服务。
云计算的部署方式:
● 公有云 :指第三方提供商为用户提供的能够使用的云,公有云一般可通过Internet使用,是免费或成本低廉的。
● 私有云 :为一个客户单独使用而构建的云,因而提供对数据、安全性和服务质量的最有效控制。
● 社区云:由几个组织共享的云端基础设施,它们支持特定的社群,有共同的关切事项,例如使命任务、安全需求、策略与法规遵循考量等。管理者可能是组织本身,也可能是第三方。
● 混合云。
(4)大数据
大数据是指其大小或复杂性无法通过现有常用的软件工具,以合理的成本并在可接受的时限内对其进行捕获、管理和处理的数据集。
大数据特征(5V)
● 大量(Volume):数据量的大小决定数据的价值和潜在的信息;单位是PB(1024TB)、EB(1024PB)。
● 高速(Velocity):指获得数据的速度和处理速度。
● 多样性(Variety):类型繁多,包括各种结构化、半结构化和非结构化的数据。
● 真实性(Veracity):数据的质量。
● 价值(Value):单位价值密度低,合理运用大数据,以低成本创造高价值。
大数据分析步骤 为:数据获取/记录→信息抽取/清洗/注记→数据集成/聚集/表现→数据分析/建模→数据解释。
大数据应用领域:制造业、服务业、交通行业、医疗行业。