分布式架构知识体系必读

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

分布式架构知识体系必读

1.问题

•1、何为分布式何为微服务?

•2、为什么需要分布式?

•3、分布式核心理论基础,节点、网络、时间、顺序,一致性?

•4、分布式是系统有哪些设计模式?

•5、分布式有哪些类型?

•6、如何实现分布式?

2.关键词

节点,时间,一致性,CAP,ACID,BASE,P2P,机器伸缩,网络变更,负载均衡,限流,鉴权,服务发现,服务编排,降级,熔断,幂等,分库分表,分片分区,自动运维,容错处理,全栈监控,故障恢复,性能调优

3.全文概要

随着移动互联网的发展智能终端的普及,计算机系统早就从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在,按照分布式理论的指导构建出庞大复杂的应用服务,也已经深入人心。本文力求从分布式基础理论,架构设计模式,工程应用,部署运维,业界方案这几大方面,介绍基于MSA(微服务架构)的分布式的知识体系大纲。从而对SOA到MSA 进化有个立体的认识,从概念上和工具应用上更近一步了解微服务分布式的本质,身临其境的感受如何搭建全套微服务架构的过程。

4.基础理论

4.1SOA到MSA的进化

SOA面向服务架构

由于业务发展到一定层度后,需要对服务进行解耦,进而把一个单一的大系统按逻辑拆分成不同的子系统,通过服务接口来通讯,面向服务的设计模式,最终需要总线集成服务,而且大部分时候还共享数据库,出现单点故障的时候会导致总线层面的故障,更进一步可能会把数据库拖垮,所以才有了更加独立的设计方案的出现。

MSA微服务架构

微服务是真正意义上的独立服务,从服务入口到数据持久层,逻辑上都是独立隔离的,无需服务总线来接入,但同时增加了整个分布式系统的搭建和管理难度,需要对服务进行编排和管理,所以伴随着微服务的兴起,微服务生态的整套技术栈也需要无缝接入,才能支撑起微服务的治理理念。

4.2节点与网络

节点

传统的节点也就是一台单体的物理机,所有的服务都揉进去包括服务和数据库;随着虚拟化的发展,单台物理机往往可以分成多台虚拟机,实现资源利用的最大化,节点的概念也变成单台虚拟机上面服务;近几年容器技术逐渐成熟后,服务已经彻底容器化,也就是节点只是轻量级的容器服务。总体来说,节点就是能提供单位服务的逻辑计算资源的集合。

网络

分布式架构的根基就是网络,不管是局域网还是公网,没有网络就无法把计算机联合在一起工作,但是网络也带来了一系列的问题。网络消息的传播有先后,消息丢失和延迟是经常发生的事情,我们定义了三种网络工作模式:

同步网络

•节点同步执行

•消息延迟有限

•高效全局锁

半同步网络

•锁范围放宽

异步网络

•节点独立执行

•消息延迟无上限

•无全局锁

•部分算法不可行

常用网络传输层有两大协议的特点简介:

TCP协议

•首先tcp尽管其他可以更快

•tcp解决重复和乱序问题

UDP协议

•常量数据流

•丢包不致命

4.3时间与顺序

时间

慢速物理时空中,时间独自在流淌着,对于串行的事务来说,很简单的就是跟着时间的脚步走就可以,先来后到的发生。而后我们发明了时钟来刻画以往发生的时间点,时钟让这个世界尽然有序。但是对于分布式世界来说,跟时间打交道着实是一件痛苦的事情。分布式世界里面,我们要协调不同节点之间的先来后到关系,但是不同节点本身承认的时间又各执己见,于是我们创造了网络时间协议(NTP)试图来解决不同节点之间的标准时间,但是NTP本身表现并不如人意,所以我们又构造除了逻辑时钟,最后改进为向量时钟:

NTP的一些缺点,无法完全满足分布式下并发任务的协调问题

•节点间时间不同步

•硬件时钟漂移

•线程可能休眠

•操作系统休眠

•硬件休眠

逻辑时钟

•定义事件先来后到

•t’ = max(t, t_msg + 1)

向量时钟

•t_i’ = max(t_i, t_msg_i)原子钟

顺序

有了衡量时间的工具,解决顺序问题自然就是水到渠成了。因为整个分布式的理论基础就是如何协商不同节点的一致性问题,而顺序则是一致性理论的基本概念,所以前文我们才需要花时间介绍衡量时间的刻度和工具。

4.4一致性理论

说到一致性理论,我们必须看一张关于一致性强弱对系统建设影响的对比图:

该图对比了不同一致性算法下的事务,性能,错误,延迟的平衡。

强一致性ACID

单机环境下我们对传统关系型数据库有苛刻的要求,由于存在网络的延迟和消息丢失,ACID便是保证事务的原则,这四大原则甚至我们都不需要解释出来就耳熟能详了:

•Atomicity:原子性,一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。

•Consistency:一致性,在事务开始之前和事务结束以后,数据库的完整性没有被破坏。

•Isolation:隔离性,数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

•Durabilit:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。分布式一致性CAP

分布式环境下,我们无法保证网络的正常连接和信息的传送,于是发展出了CAP/FLP/DLS 这三个重要的理论:

•CAP:分布式计算系统不可能同时确保一致性(Consistency)、可用性(Availablity)和分区容忍性(Partition)。

•FLP:在异步环境中,如果节点间的网络延迟没有上限,只要有一个恶意的节点存在,就没有算法能在有限的时间内达成共识。

•DLS:

(1)在一个部分同步网络的模型(也就是说:网络延时有界限但是我们并不知道在哪里)下运行的协议可以容忍1/3任意(换句话说,拜占庭)错误;

(2)在一个异步模型中的确定性的协议(没有网络延时上限)不能容错(不过这个论文没有提起随机化算法可以容忍1/3的错误);

(3)同步模型中的协议(网络延时可以保证小于已知d时间)可以,令人吃惊的,达到100%容错,虽然对1/2的节点出错可以发生的情况有所限制

弱一致性BASE

多数情况下,其实我们也并非一定要求强一致性,部分业务可以容忍一定程度的延迟一致,所以为了兼顾效率,发展出来了最终一致性理论BASE,BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)

•基本可用(Basically Available):基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

•软状态(Soft State):软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。

•最终一致性(Eventual Consistency):最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

一致性算法

分布式架构的核心就在一致性的实现和妥协,那么如何设计一套算法来保证不同节点之间的通信和数据达到无限趋向一致性,就非常重要了。保证不同节点在充满不确定性网络环境下能达成相同副本的一致性是非常困难的,业界对该课题也做了大量的研究。

相关文档
最新文档