分布式系统复习笔记2019年秋
Introduction
分布式系统定义(集合、单一、一致)
独立计算机的集合,对外呈现一个单一的、一致的系统。
分布式系统的目标(MDOS)
- (Make resources available)让资源可用
- (Distribution transparency)分布式透明
- (Openness)开放
- (Scalability)可扩展性
为什么要分布式(ESIRI)
Economics 经济性 |
微处理器能提供比大型机更好的性价比 |
Speed 速度 |
分布式系统能提供比大型机更强的计算能力 |
Inherent distribution 固有的分布性 |
有一些应用包含物理上分布的机器 |
Reliability 可靠性 |
当某台机器崩溃时,整个系统仍能正常工作 |
Incremental growth 可扩展性 |
计算能力逐步增加 |
分布式系统透明性和开放性的含义
- 透明性:在用户面前呈现为单个计算机系统,隐藏底层的细节
- 开放性:能够和其它开放系统提供的服务进行通信互访,独立于底层异构的环境。
分布式系统的类型(计算、信息、普适)
- 分布式计算系统 :网格计算、云计算等
- 分布式信息系统:分布式数据库等
- 分布式普适系统:节点更小、可移动、嵌入式的分布式系统
Distributed System Architecture
分布式系统架构风格(层次、对象、时空解耦)
- 在逻辑上分为不同组件,然后将它们分布到不同的机器上
- 层次风格用于c-s系统
- 基于对象的风格用于分布式对象系统
- 空间上解耦,时间上异步
- 发布/订阅模式 (空间上解耦)
- 分享数据空间 (时空上解耦)
分布式系统组织形式(集中、分布、混合)
- 集中控制式
- 去中心化
- 混合式
客户-服务器模式和对等模式
Basic Client-Server 模型(单服务器/多客户端):
-
- 特点:服务器提供服务;客户端使用服务;客户端和服务端可以在不同机器上;客户端通过请求/回复模式使用服务
- 缺陷:服务器成为瓶颈;服务器成为单点故障;系统很难扩展
- 多个服务器/多个客户端,web proxy ,web applets, thin clients
- 传统三层结构:User-interface layer、Processing layer, Data layer
对等模式(结构、非结构、混合)
-
- 结构化 p2p:将节点组织成结构化覆盖网络例如逻辑环和超立方等,并根据节点ID来指定任务
- 非结构化p2p:节点之间随机覆盖,两个节点有一定的概率建立链接。算法有Flooding,Random walk(随机选个节点v,v要么返回结果,要么随机选择一个自己的邻居)。
- 混合p2p:CS与p2p的结合。边缘服务器架构,例如CDN的架构
分布式系统组织为中间件
在大多数情况下,分布式系统会根据特定的架构风格去部署,这样的风格并不是在所有情况下都是最优的,因此需要动态适配中间件的行为。
Processes
进程vs 线程
- 进程是具有独立功能的程序关于某个数据集合的一次性活动,是资源分配和调度的基本单位。(ready ,running, blocked)
- 线程是进程的一个实体,是CPU调度的基本单位。
- 线程之间共享地址空间,进程间则独立。一个进程可以有多个线程
- 优势:代码迁移最多包含代码、数据、执行状态的迁移,总传输量小于一个虚拟机,所以轻量,网络负载小,无需引入其它中间语言
- 劣势:在异构系统中目标计算可能不适合执行迁移的代码,进程、线程、处理器上下文可能高度依赖本地硬件,OS和运行时系统。
代码迁移
Code segment/ Data segment / Excution state
强迁移 vs. 弱迁移
- 只迁移代码和数据段,相对简单,需要将代码传送和代码提取区分开
- 迁移整个组件,包含执行状态
Manging local resources
本地资源在目标处可能不可用
资源类型:
- 固定:不能被迁移,例如硬件
- 牢固:迁移代价很大
- 独立:很容易迁移
对象到资源的绑定:
- 通过标识符:目标需要一个具体的实例(例如数据库)
- 通过值:目标需要资源的值(例如 缓存的集合)
- 类型:目标需要资源的类型
Migration in heterogeneous systems
主要问题
- 目标机器可能不适合执行迁移代码
- 进程/线程/处理器上下文可能高度依赖本地硬件、os和运行时系统
利用在不同平台上实现的抽象机器
- 解释型语言,拥有自己的VM
- 虚拟机
Communication
通信的类型(持久/非持久、异步/同步)
非持久通信:无法在下一个服务器或接收者处传递消息时,服务器将丢弃该消息
持久通信:只要传递消息,消息就会存储在通信服务器中
同步通信和异步通信
远程过程调用RPC(Remote procedure call protocol)
RPC概念:当机器A上的一个进程调用机器B上的一个过程,则调用进程挂起,被调用进程在B上执行。信息可通过参数或者结果传递,过程对程序员不可见。
目标:让远程调用在程序员看起来是本地的普通调用。
RPC的工作过程
(1) 客户端(client)以本地调用方式(即以接口的方式)调用服务;
(2) 客户端存根(client stub)接收到调用后,负责将方法、参数等组装成能够进行网络传输的消息体(将消息体对象序列化为二进制);
(3) 客户端通过sockets将消息发送到服务端;
(4) 服务端存根( server stub)收到消息后进行解码(将消息对象反序列化);
(5) 服务端存根( server stub)根据解码结果调用本地的服务;
(6) 本地服务执行并将结果返回给服务端存根( server stub);
(7) 服务端存根( server stub)将返回结果打包成消息(将结果消息对象序列化);
(8) 服务端(server)通过sockets将消息发送到客户端;
(9) 客户端存根(client stub)接收到结果消息,并进行解码(将结果消息发序列化);
(10) 客户端(client)得到最终结果。
故障处理
- 客户端不能找到服务器
e.g. 服务端挂掉/ 服务端更新而客户端还用的老版本
解决方案:使用 返回值(-1)、exception、signal等代表异常
- 客户端到服务端的请求信息丢失
客户端设置一个timer,超时重发
- 服务端到客户端的回复信息丢失
客户端设置一个timer,超时则重发;对于不幂等的请求,为请求分配序号,服务器区别不同的请求
- 服务端在收到请求后崩溃
- 等待服务器重启然后重发,保证RPC至少被执行一次(至少执行一次语义)
- 立刻放弃并汇报错误,保证RPC最多执行一次
- 什么也不做,语义由客户端自己保证
- 客户端在发送请求后挂掉
问题:计算在服务端进行却没有接收计算结果的一端(孤儿),浪费了计算资源,并且可能在计算时还会锁定数据;还可能导致混淆,因为客户端重启后重新调用RPC可能收到上一个RPC的结果。
解决方案:1)extermination:在客户端存根发送RPC前,将操作记录在安全存储的 log entry上,重启后,查看 log entry 然后将 孤儿终止(为每个RPC写 log entry 代价较高,如果网络切分了也无法终止孤儿)2)reincarnation:给时间划分不同的时期,当客户端重启时,开始一个新的时期,并将这个消息广播出去,服务器收到这个消息时,就终止任务的计算。3)expiration: 给rpc执行一个标准的时间段,未完成任务需显式申请附加配额。
动态绑定(优势:灵活、多服务器、版本一致。劣势:ex/import开销、瓶颈)
客户端如何定位服务器?一种解决方案是将服务器地址写死在代码里面,这样不灵活;更好的方式是动态绑定:当服务器开始执行时,发送一个消息给binder 告诉自己所能提供的接口,然后当客户端第一次调用RPC时,询问binder服务器的位置,然后再进行操作。
动态绑定过程
- 服务器向一个binder 注册自己的信息表示自己的存在,这些信息包括它的名字、版本号、唯一标志符,句柄。
- 当客户端第一次调用一个rpc时,客户端存根利用接口名、版本号向binder 询问接口信息。如果有,binder返回句柄以及标识符。
- 客户端存根将句柄当作地址,发送调用信息,包括标识符和参数
优势:
- 灵活
- 可以支持多个服务器提供同一个接口,从而实现负载均衡、容错、协助认证
- binder可以确保client 和server 使用同样版本的接口
缺点:
- 导入导出接口的额外开销
- binder在大型分布式系统中可能成为瓶颈
基于消息的通信
同步异步
同步:sender 被阻塞,直到消息存储在receiver的本地缓存或receiver接受到消息为止
异步:sender 发送信息后继续工作,消息存储在sender 端或着第一通信服务器的的本地缓存
持久性/非持久性
持久性:只要将消息传递到接收方,消息就存储在通信系统中。
持久性消息也称为消息队列系统,sender和receiver都有自己的队列,当sender将消息放到receiver消息队列中时,receiver可以不是活跃状态,反之亦然。
非持久性:消息被sender放到网上,如果其无法传递给下一个通信主机则丢弃。
面向流的通信(buffer、packet不放连续帧、复用/解复用)
数据流是一种支持等时数据传输的面向连接的通信工具
特点:1)单向 2)通常只有单个来源多个接收者 3)接收者或者源是硬件包装器 4)简单的流:音频或者视频 5)复杂的流:音频视频组合
Qos:1)传输数据所需的比特率 2)建立会话之前的最大延迟 3)端到端的最大延迟(数据单元到达对方的最大时间)4)最大延迟的方差或者抖动 5)最大往返延迟
- 利用 buffer 降低抖动
- 一个packet内不放连续的帧来降低丢包的影响
- 多个子流复用为单个流,并在接收器处解复用,同步在 复用/解复用时解决
同步与资源管理
同步问题
在单cpu系统中,可以使用信号量等方法解决互斥、同步问题,分布式系统中由于没有共享内存这些方法是不起作用的。在分布式系统中,如果发生两个事件,很难知道哪个先发生,因为两个时钟的差异、计算机时钟受时钟漂移影响,所以需要时钟同步来保证时钟的相对一致
逻辑时钟和物理时钟
时钟同步不是必须的,如果两个进程没有交互,他们的时钟可以不同步,重要的不是所有流程都确切的约定在几点,而是他们同意事件发生的顺序。
逻辑时钟:仅考虑节点间的交互在事件的发生顺序上达成一致,而不考虑时钟是否接近实际时间的算法
物理时钟:内部时钟不仅要一样,而且也要接近实际时间
时钟同步机制
Cristian’s Time Sync
服务器和客户端之间通过二次报文交换,确定主从时间误差,客户端校准本地计算机时间,完成时间同步,有条件的话进一步校准本地时钟频率。
流程如下:
- 客户端发送附带T1时间戳的查询报文给服务器;
- 服务器在该报文上添加到达时刻T2和响应报文发送时刻T3;
- 客户端记录响应报到达时间T4
RTT(Round Trip Time)= (t4-t1)-(t3-t2). RTT表示从发送到接受数据包的时间。假设来回网络链路是对称的,即传输时延相等,那么可以计算客户端于服务器之间的时差D为 (t2-t1)- RTT/2, 所以客户端在自己当前时间上加上误差D就可以校准时间。同时为了提高准确率,可以发送多次请求,计算RTT的平均值。
逻辑时钟
给每个事件e 一个时间戳C,满足下面两个属性:1)如果事件 a 和事件b 在同一个进程里(不同进程分布在不同机器上),并且a 先于b,只需要C(a) < C(b) 。 2)如果a 发送一个消息m,而b接受消息m,则必须满足C(a) < C(b)。
因为没有全局时钟,可以为每个进程维护一个逻辑时钟。
lamport算法(3步)
每个事件对应一个Lamport时间戳,初始值为0
- 如果事件在节点内发生,本地进程中的时间戳+1
- 如果事件属于发送事件,本地进程中的时间戳+1,并在消息中带上该时间戳
- 如果时间属于接受事件,本地进程中的时间戳 = Max (本地时间戳,消息中的事件戳)+ 1
这样保证了事件的偏序关系,但仍然存在不同进程中的两个事件同时发生,因此可以为每个进程编号,在C(a) == C(b)的情况下,若a进程号小于b进程号,则认为a先于b,从而保证全序性(这里a,b的先后并不重要,只是这样可以对全局事件进行排序)
total order multicasting (全序组播)(基于队列,4步:顺序接受;发送消息;接受消息,放入队列,发送ACK;应用消息)
如何保证分布式系统中各个子系统都按相同的顺序执行一组操作?一个等价的问题就是如何在分布式系统下实现全序组播。
使用进程Id 保证不同进程的逻辑时钟不一致,C(a).i (i是进程号) 发生在C(b).j 之前可以表示为: C(a) < C(b) 或 C(a) == C(b), i < j 。
实现细节:
- 设一个发送者发送的所有消息都按照他发送的顺序被接受,
- 进程 Pi 发送一个带有时间戳的消息MSGi 给其它所有进程。它自己也将这个消息放入本地的队列Qi
- 进程按照消息的时间戳顺序把接收到的消息放入一个本地的队列中,然后向其他所有进程多播一个ACK(确认消息收到)
- 进程Pj 有在满足下面条件时,才会执行消息:
- MSGi 在Qj 头部
- MSGi在Qj中时间戳最小
实现原理:
- 收到消息的时间戳低于ACK的时间戳,这是Lamport Clock的特性
- 所有的进程在本地保存的队列都是相同的,保证了实现顺序的一致性
向量时戳(3步:vector含义;发送msg+vector;更新vector)
lamport lock 特点
- 如果 a 因果先于 b,则 C(a) < C(b)
- 如果 C(a) < C(b) ,a不一定 因果先于b,可能是并发关系
向量时戳就是解决这个问题的。
- 每个进程Pi有一个vector VC_i[n] , VC_i[j]表示Pi 知道的关于Pj上发生的事件数
- 当Pi发送一个消息m,VC_i[i] +=1,然后将消息m和自己的VC一起发送出去
- 当进程Pj收到消息m时,更新自己的VC_j[k]为 Max(VC_j[k] ,VC_i[K]),然后将相应的VC_j[j] + 1
分布式系统的互斥访问
Centralized Mutual Exclusion
集中式算法:仿照单机处理系统中的方法,选举一个进程作为协作者,由这个协作者调度对共享资源的访问。
当一个进程要访问共享资源,它要向协作者发送一个请求信息,说明它想要访问哪个资源。如果当前没有其他进程访问资源,协作者就发送准许的应答消息。
特性:
- 安全的,每次只有一个进程访问共享资源
- 基于队列的公平性
- 没有饿死问题
- 非常好实现(三种消息:一个请求,一个授权,一个释放)
缺点:
- 协调者:单点故障,性能瓶颈
- 如果进程发送请求后阻塞,则不能区分协调者挂了还是被拒绝了。
A Distributed Algorithm (基于时间戳投票)
- 当一个进程想要访问临界资源时,构建访问请求信息带上自己的时间戳,然后发送给所有其它进程
- 当一个进程收到了其它进程的请求信息,1) 如果它没有也不想访问这个资源,回复ok。 2)如果正在访问这个资源,则将请求信息放到队列里 。3)如果想访问但还没访问,就对比下自己发出的访问请求信息中的时间戳,如果自己的更小,则将请求放入队列;否则回复ok
缺点:
- 如果任何进程崩溃,它将对后续操作无反应,会被认为是拒绝,从而阻止其它进程访问
- 需要可靠的多播,维护一系列信息
- 比集中算法更慢、更复杂、更不可靠
Token ring algorithm
将进程组织为逻辑环,然后传一个令牌,拥有令牌的可以访问资源
分布式系统的选举机制
Bully Algorithm(3步:优先级组播;出局/接管;没收到接管获胜)
每个进程都有自己的优先级,问题是如何找到最高优先级的进程
- 每个进程都能开始一轮选举,将选举消息附带上自己的优先级发送给所有其它进程
- 进程收到消息后,比对自己的优先级,自己低则出局,自己高则回复接管消息
- 如果一个没有收到一个接管消息,则它就赢了,向所有其它进程发送胜利消息。
Election in a ring
任何进程都可以发送选举消息,然后这个消息不断往下传,每传到一个节点大家都将自己的优先级信息附加上去,最后回到选举发起者那里,然后找到优先级最高的那个作为协调者,将消息传播出去。
复制与一致性
复制的优势与不足(可靠性/性能;复制透明度/一致性)
优势 :可靠性、性能
不足:复制透明度;一致性问题。
真正实现一致性,需要考虑数据更新时如何进行实际的分发,副本的位置、更新的方式,更新的速度
数据一致性模型
Data-centric consistency
数据的共享是通过分布式共享存储器、分布式共享数据库或者分布式共享文件系统实现的。
Strict consistency
需要保证数据更新的同时,所有副本也同样同时更新,但显然是不可能实现的
Sequential consistency
允许任何读写操作的交叉执行,但是要保证所有进程能够确认统一的执行顺序,不会存在不同进程的执行顺序得到不同的结果的现象。
存在严重的性能问题,对于任何顺序一致性存储,提高读操作性能必降低写操作性能
实现顺序一致性:对于写操作,使用全序多播;对于读操作,立即返回本节点上对应变量的值。
Linearizability
线性一致性相对于顺序一致性增加了时间戳顺序的要求,更加严格
Causal Consistency
弱化的顺序一致性,顺序存储的因果一致性定位为:所有进程必须以相同的顺序看到具有潜在因果关系的写操作。不同机器上的进程可以以不同的顺序被看到并发写操作。
实现因果一致性要求跟踪哪些进程看到了哪些写操作。换句话说,因果一致性允许不同的机器以不同的顺序看到并发的写操作,但是所有机器必须以相同的顺序看到因果相关的操作。
FIFO Consistency
所有进程以某个单一进程提出写操作的顺序看这些写操作,但是不同进程可以以不同的顺序看到不同进程提出的写操作。也就是说,进程不必再开始进行下一个写操作之前停止并且等待前一个写操作的完成。不同进程产生的写操作都是并发的。
它仅仅要求:对于同一个进程执行的读写序列,对于任何一个变量x的读操作read(x),读到的值都是在此读操作之前最后一次此进程发出的写操作write(x)更新的值。而对于不同节点发出的写序列,其他节点的读操作可以按任意顺序返回值。
Weak Consistency
引入同步变量s,当一个进程对变量设置值的时候,不保证其他进程什么时候能够看到值的变化,但是当执行了一次同步操作后,所有进程会看到最新的值。
Release Consistency
使用两个同步变量ACQ和REL成对控制,释放一致性规则如下
- 对共享数据执行读写操作之前,所有进程之前的获取操作都已经完成
- 在释放操作被允许之前,所有进程之前对数据的读写操作都必须已经完成
- 对同步变量的访问是FIFO一致的
Entry Consistency
Client-centric consistency(最终一致性;只需保证更新消息被传出去;访问多个和一个副本难度不同)
本质上以客户为中心的一致性模型为单一的客户提供一致性保证,并不为不同客户的并发访问提供一致性保证。
Eventual consistency
如果在一段相当长的时间内没有更新操作,那么所有的副本将逐渐成为一致的。
单调读:进程在t时刻看到x,保证后续操作不会看到x的更老版本。
单调写:写操作必须完全串行执行,不能交叉。
写后读(read-your-writes consistency):一个写操作总是在同一进程后续读操作之前完成,不管这个后续读在什么位置。
读后写:对数据项x的任何后续写操作,保证发生在于x读取值相同或比之更新的值上。
三种数据拷贝的类型:永久复制(多个拷贝分布在LAN的多个server上;);server发起的复制;client发起的复制(主要是cache)
更新传播的三种方式:仅传播一个更新通知;传播更新后数据;传播更新操作种类;
数据一致性协议实例
基于法定数量的协议(两个不等式)
要求客户在读写一个复制的数据项之前请求半数以上的服务器并多的返回的版本号,以确定数据的最新版本。假设所有副本数量加起来等于V
每个操作需要获得一个读的法定数量Vr 和写的法定数量Vw,必须遵循以下规则:
- Vr + Vw > V
- Vw > V/2
容错
可信系统(Dependable System)特征(ARSM)
- (Availability)可用性:在任何给定的时刻,系统都可以正确及时地工作,并执行用户的请求。
- (Reliability)可靠性:系统可以无故障持续运行,但是只能根据时间间隔来定义。高可靠性的系统可以在一个相对较长的时间内持续工作而不被中断。
- (Safety)安全性:系统偶然出现故障时还能正确操作和运行。
- (Maintainability)可维护性:表示发生故障后系统能被恢复到可用性的难易程度。
提高系统可信性的途径(信息|时间|物理冗余;少量关键组件同时运行)
使用冗余来掩盖故障:对其它进程隐藏故障的发生。
- 信息冗余:添加额外的位或码检测恢复数据传输错误
- 时间冗余:重复执行异常终止的任务
- 物理冗余:添加额外的硬件或软件
一种不需要大量关键组件同时运行的设计。
K容错系统
复制进程的管理(基于主进程|选举|层级;复制写|法定数量协议|平等)
基于主进程的复制:主进程负责协调所有更新;如果协调者挂了,备份接管(通常需要选举);进程之间是层级的组织方式。
复制写:主动复制,基于法定数量协议;平等组织;没有单点失败
设计问题
- 系统能够经受K个组件的故障并且还能满足规范要求。当这些组件是失败沉默的情况下,需要K+1个组件可以提供K容错;如果发生拜占庭失败,至少需要2k+1个进程才能获得K容错
- 组结构:平等/分层
- 需要管理组以及组关系;集中式:group server;分布式:全序多播
拜占庭问题(ByZantine Problem)
通信是可靠的但是进程不可靠。(通信不可靠的两军问题无解,最多只能降低不可靠性)。
问题定义
n 个不同地点的蓝色将军想要达成共识,但是其中的m个是叛徒。那么忠诚的将军们能否在同一个行动上达成共识?这个与K容错是有区别的。K容错是正确节点都会得到相同结果,而拜占庭将军问题是正确节点也会存在有不同结果。
算法步骤
第一步:每个军将告诉其他所有n-1个将军自己的兵力(真假未知)。
第二步:每个将军收集消息形成一个向量。
第三步:每个将军将自己的向量发送给其它所有将军。
第四步:每个将军检查新收到的向量的第i个元素。把多数值保留下来,得到一致结果。
结论:具有m个故障进程的系统中,只有存在2m+1个正确的进程才能达成一致,也即共有3m+1个进程。
Byzantine Generals Problem
设计一个协议,一个司令要送一个命令给他的n-1个副官,使得
IC1. 所有忠诚的副官遵守同一个命令。(一致性)
IC2. 假如司令是忠诚的,则每一个忠诚的副官遵守他送出的该命令。(准确性)
约定:忠诚的将军将遵守协议,而叛徒则可能破坏协议,尽可能的干绕其它人的判断。叛徒是匿名的。而且最后不需要确定谁是叛徒。拜占廷将军问题就是要让爱国的将军达成一致,而不是找叛国的将军。
Oral Message Algorithm (OM算法)
叛徒少于1/3,拜占庭问题可解
A1) 传送正确
A2) 接收者知道是谁发的
A3) 沉默(不发信息)可被检测
OM(n,0):
- 司令发送命令给所有副官
- 副官按照接受到的命令行事
OM(n,m):
- 司令发送命令给所有副官,设副官i收到命令vi
- 分为独立的n-1轮:对每个副官i,将其视为司令,使用OM(n-1,m-1)将vi发送到所有其它n-2个副官
- 这样每个副官都收到n-1条消息,每个副官都按照出现次数更多的命令行事(如果进攻和撤退命令一样多,则默认撤退)
系统恢复
发生故障后恢复到正确的状态
- 回退恢复
- 前向恢复
检查点
独立检查点
- 每个进车独立设立检查点
- 进程可以回滚到全局一致的状态
协调检查点
所有的进程进行同步,以共同将其状态写入本地稳定存储,从而形成全局一致状态
两个算法:
-
- 分布式快照 -- 非阻塞式
- 两阶段锁定协议 two-phase blocking protocol
two-phase blocking protocol
- 协调者将 Checkpoint_request 消息组播给其它进程
- 当一个进程收到了消息,它就设立一个检查点,将任何应用程序发给它的后续消息放到队列里(进入阻塞状态),并且发送一个ACK通知协调者
- 当协调者收到了所有的ACKs,就组播一个 Checkpoint_done 消息个允许阻塞的进程继续执行
云计算
定义
一种计算能力,提供了计算资源与底层结构之间的抽象,使用户可以通过网络方便的、按需使用的来对一个共享资源池进行迅速的配置、部署与使用,并且只需要很少的管理以及与服务商的交互。
服务分类
软件即服务SaaS (Software as a Service) |
Salesfoce online CRM服务 |
平台即服务PaaS(Platform as a Service) |
Google App Engine Sina App Engine(SAE) |
基础设施即服务IaaS(Infrastructure as Service) |
Amazon EC2、S3 阿里云 |
特点
- 高可靠性:冗余副本、负载均衡
- 通用性:支撑千万变化的实际应用
- 按需服务:按需购买
- 安全:摆脱数据丢失、病毒入侵
- 方便:支持多终端、数据共享
云计算模式
- 公有云:资源以“按需服务”的方式提供给公用服务;服务以一种效用计算的方式被出租使用
- 私有云:为一个单独客户而构建的,提供对数据、安全性和服务质量的最有效控制。
- 混合云:安全因素,并非所有的企业信息都能放置在公有云上。
云计算与云平台
- 云计算是一种计算模式、而不是一种产品
- 按需服务是云计算的核心理念,类似于水、电等基础设施
- 云平台是实现云计算模式的产品,是用户使用云计算服务的入口,也让服务商以最小代价满足用户请求。
虚拟化
虚拟化是由位于下层的软件模块,将其封装或抽象,提供软硬件的接口,使得上层的软件可以直接运行在这个虚拟的环境,和运行原来的环境一样。
虚拟化与云计算
虚拟化特点 |
为云计算带来的好处 |
封装与隔离 |
保证每个用户有安全可信的工作环境 |
多实例 |
保证较高的资源利用率 为服务器合并提供基础 |
硬件无关性 |
整合异构硬件资源 可实现虚拟机迁移,使资源调度、负载平衡容易实现 |
特权功能 |
入侵和病毒检测 |
动态调整资源 |
细粒度的可扩展性 |
边缘计算
基本思想:把云计算平台从移动核心网络内部迁移到移动接入网边缘
概念
- 利用靠近数据源的边缘地带来完成的运算程序。
- 一种分布式的计算模式
- 大部分计算在边缘设备上完成,而不是主要在集中式云环境中运行
集中式云环境缺点:
不易扩展、集中而脆弱、安全信任难以实现、更易受到攻击、控制设备时延高
优点
措施:把大部分计算沉降在靠近设备的边缘,小部分连接远处的云端
- 实时响应时间短(火灾、控制灯等),减轻整个IT基础架构的负担
- 减少网络传输量,传输处理的数据,而非原始数据,防止网络拥塞
- 边缘计算实现数据的安全性和隐私性
- 敏感数据在边缘设备上生成、处理和保存,而不是通过不安全的网络传输
- 数据保密性好
- 充分利用智能设备的运算能力
- 在边缘设备处存储和处理数据
- 利用计算能力使边缘设备的行为类似于云类操作
- 应用程序可以快速执行,并与端点建立可靠且高度响应的通信
云计算与边缘计算的结合
可能结合的一种架构
- 中心云——集中式
- Fog 和Edge——分布式
特点
- 集中于分布相结合
- 边缘设备根据不同时延要求分配任务给边缘云或集中云