一文读懂分布式架构知识体系(内含超全核心知识大图)
Posted 阿里巴巴云原生
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一文读懂分布式架构知识体系(内含超全核心知识大图)相关的知识,希望对你有一定的参考价值。
导读:本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面,介绍基于 MSA(微服务架构)的分布式知识体系大纲,从而对 SOA 到 MSA 进化有着立体的认识;从概念上和工具应用上更近一步了解微服务分布式的本质,身临其境的感受如何搭建全套微服务架构的过程。
随着移动互联网的发展和智能终端的普及,计算机系统早就从单机独立工作过渡到多机器协作,集群按照分布式理论构建出庞大复杂的应用服务,在分布式的基础上正进行一场云原生的技术革命,彻底打破传统的开发方式,解放了新一代的生产力。
分布式系统知识体系大图
基础理论
SOA 到 MSA 的进化
SOA 面向服务架构
MSA 微服务架构
节点与网络
节点
网络
-
同步网络
-
节点同步执行
-
消息延迟有限
-
高效全局锁
-
半同步网络
-
锁范围放宽
-
异步网络
-
节点独立执行
-
消息延迟无上限
-
无全局锁
-
部分算法不可行
-
TCP 协议
-
首先 tcp 协议传输可靠,尽管其他的协议可以更快传输
-
tcp 解决重复和乱序问题
-
UDP 协议
-
常量数据流
-
丢包不致命
时间与顺序
时间
-
NTP 的一些缺点,无法完全满足分布式下并发任务的协调问题
-
节点间时间不同步
-
硬件时钟漂移
-
线程可能休眠
-
操作系统休眠
-
硬件休眠
-
逻辑时钟
-
定义事件先来后到
-
t' = max(t, t_msg + 1) -
-
向量时钟
-
t_i' = max(t_i, t_msg_i)
-
原子钟
顺序
一致性理论
强一致性 ACID
-
Atomicity:原子性,一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节; -
Consistency:一致性,在事务开始之前和事务结束以后,数据库的完整性没有被破坏; -
Isolation:隔离性,数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时,由于交叉执行而导致数据的不一致; -
Durabilit:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
分布式一致性 CAP
-
CAP:分布式计算系统不可能同时确保一致性(Consistency)、可用性(Availablity)和分区容忍性(Partition);
-
FLP:在异步环境中,如果节点间的网络延迟没有上限,只要有一个恶意的节点存在,就没有算法能在有限的时间内达成共识;
-
DLS:
-
在一个部分同步网络的模型(也就是说:网络延时有界限但是我们并不知道在哪里)下运行的协议可以容忍 1/3 任意(换句话说,拜占庭)错误; -
在一个异步模型中的确定性的协议(没有网络延时上限)不能容错(不过这个论文没有提起随机化算法可以容忍 1/3 的错误); -
同步模型中的协议(网络延时可以保证小于已知 d 时间),可以令人吃惊的达到 100% 容错,虽然对 1/2 的节点出错可以发生的情况有所限制。
弱一致性 BASE
-
基本可用(Basically Available):基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用; -
软状态(Soft State):软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现; -
最终一致性(Eventual Consistency):最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。
一致性算法
-
在分布式系统中,单调的逻辑都能保证 “最终一致性”,这个过程中不需要依赖中心节点的调度;
-
任意分布式系统,如果所有的非单调逻辑都有中心节点调度,那么这个分布式系统就可以实现最终“一致性”。
-
基于状态(state-based):即将各个节点之间的 CRDT 数据直接进行合并,所有节点都能最终合并到同一个状态,数据合并的顺序不会影响到最终的结果; -
基于操作(operation-based):将每一次对数据的操作通知给其他节点。只要节点知道了对数据的所有操作(收到操作的顺序可以是任意的),就能合并到同一个状态。
-
Paxos: -
Raft : -
Gossip:
场景分类
文件系统
-
HDFS -
FastDFS -
Ceph -
mooseFS
数据库
-
列式存储:Hbase -
文档存储:Elasticsearch,MongoDB -
KV 类型:Redis -
关系型:Spanner
计算
-
离线:Hadoop -
实时:Spark -
流式:Storm,Flink/Blink
缓存
-
持久化:Redis -
非持久化:Memcache
消息
-
Kafka -
RabbitMQ -
RocketMQ -
ActiveMQ
监控
-
Zookeeper
应用
-
HSF -
Dubbo
日志
-
日志采集:flume -
日志存储:ElasticSearch/Solr,SLS -
日志定位:Zipkin
账本
-
比特币
-
以太坊
设计模式
可用性
-
健康检查:系统实现全链路功能检查,外部工具定期通过公开端点访问系统 -
负载均衡:使用队列起到削峰作用,作为请求和服务之间的缓冲区,以平滑间歇性的重负载 -
节流:限制应用级别、租户或整个服务所消耗资源的范围
数据管理
-
缓存:根据需要将数据从数据存储层加载到缓存 -
CQRS(Command Query Responsibility Segregation):命令查询职责分离 -
事件溯源:仅使用追加方式记录域中完整的系列事件 -
索引表:在经常查询引用的字段上创建索引 -
物化视图:生成一个或多个数据预填充视图 -
拆分:将数据拆分为水平的分区或分片
设计与实现
-
代理:反向代理 -
适配器:在现代应用程序和遗留系统之间实现适配器层 -
前后端分离:后端服务提供接口供前端应用程序调用 -
计算资源整合:将多个相关任务或操作合并到一个计算单元中 -
配置分离:将配置信息从应用程序部署包中移出到配置中心 -
网关聚合:使用网关将多个单独的请求聚合到一个请求中 -
网关卸载:将共享或专用服务功能卸载到网关代理 -
网关路由:使用单个端点将请求路由到多个服务 -
领导人选举:通过选择一个实例作为负责管理其他实例管理员,协调分布式系统的云 -
管道和过滤器:将复杂的任务分解为一系列可以重复使用的单独组件 -
边车:将应用的监控组件部署到单独的进程或容器中,以提供隔离和封装 -
静态内容托管:将静态内容部署到 CDN,加速访问效率
消息
-
竞争消费者:多线程并发消费 -
优先级队列:消息队列分优先级,优先级高的先被消费
管理与监控
性能与扩展
弹性
-
隔离:将应用程序的元素隔离到池中,以便在其中一个失败时,其他元素将继续运行 -
断路器:处理连接到远程服务或资源时可能需要不同时间修复的故障 -
补偿交易:撤消一系列步骤执行的工作,这些步骤共同定义最终一致的操作 -
健康检查:系统实现全链路功能检查,外部工具定期通过公开端点访问系统 -
重试:通过透明地重试先前失败的操作,使应用程序在尝试连接到服务或网络资源时处理预期的临时故障
安全
-
联合身份:将身份验证委派给外部身份提供商 -
看门人:通过使用专用主机实例来保护应用程序和服务,该实例充当客户端与应用程序或服务之间的代理,验证和清理请求,并在它们之间传递请求和数据 -
代客钥匙:使用为客户端提供对特定资源或服务的受限直接访问的令牌或密钥
工程应用
资源调度
弹性伸缩
-
应用扩容:用户激增需要对服务进行扩展,包括自动化扩容,峰值过后的自动缩容
-
机器下线:对于过时应用,进行应用下线,云平台收回容器宿主资源
-
机器置换:对于故障机器,可供置换容器宿主资源,服务自动启动,无缝切换
网络管理
-
域名申请:应用申请配套域名资源的申请,多套域名映射规则的规范
-
域名变更:域名变更统一平台管理
-
负载管理:多机应用的访问策略设定
-
安全外联:基础访问鉴权,拦截非法请求
-
统一接入:提供统一接入的权限申请平台,提供统一的登录管理
故障快照
-
现场保留:内存分布,线程数等资源现象的保存,如 JavaDump 钩子接入
-
调试接入:采用字节码技术无需入侵业务代码,可以供生产环境现场日志打点调试
流量调度
负载均衡
-
交换机 -
F5 -
LVS/ALI-LVS -
nginx/Tengine -
VIPServer/ConfigServer
网关设计
-
高性能:网关设计第一需要考虑的是高性能的流量转发,网关单节点通常能达到上百万的并发流量
-
分布式:出于流量压力分担和灾备考虑,网关设计同样需要分布式
-
业务筛选:网关同设计简单的规则,排除掉大部分的恶意流量
流量管理
-
请求校验:请求鉴权可以把多少非法请求拦截,清洗
-
数据缓存:多数无状态的请求存在数据热点,所以采用 CDN 可以把相当大一部分的流量消费掉
流控控制
-
流量分配
-
计数器 -
队列 -
漏斗 -
令牌桶 -
动态流控
-
流量限制在流量激增的时候,通常我们需要有限流措施来防止系统出现雪崩,那么就需要预估系统的流量上限,然后设定好上限数,但流量增加到一定阈值后,多出来的流量则不会进入系统,通过牺牲部分流量来保全系统的可用性。
-
限流策略 -
QPS 粒度 -
线程数粒度 -
RT 阈值 -
限流工具 - Sentinel
服务调度
注册中心
-
状态类型:第一好应用服务的状态,通过注册中心就可以检测服务是否可用
-
生命周期:应用服务不同的状态组成了应用的生命周期
版本管理
-
集群版本:集群不用应用有自身对应的版本号,由不同服务组成的集群也需要定义大的版本号
-
版本回滚:在部署异常的时候可以根据大的集群版本进行回滚管理
服务编排
-
K8s -
Spring Cloud
-
HSF -
ZK+Dubbo
服务控制
-
发现资源管理那节我们介绍了从云平台申请了容器宿主资源后,通过自动化脚本就可以启动应用服务,启动后服务则需要发现注册中心,并且把自身的服务信息注册到服务网关,即是网关接入。注册中心则会监控服务的不同状态,做健康检查,把不可用的服务归类标记。
-
网关接入 -
健康检查
-
降级:当用户激增的时候,我们首先是在流量端做手脚,也就是限流。当我们发现限流后系统响应变慢了,有可能导致更多的问题时,我们也需要对服务本身做一些操作。服务降级就是把当前不是很核心的功能关闭掉,或者不是很要紧的准确性放宽范围,事后再做一些人工补救。
-
降低一致性约束 -
关闭非核心服务 -
简化功能
-
熔断:当我们都做了以上的操作后,还是觉得不放心,那么就需要再进一步操心。熔断是对过载的一种自身保护,犹如我们开关跳闸一样。比如当我们服务不断对数据库进行查询的时候,如果业务问题造成查询问题,这是数据库本身需要熔断来保证不会被应用拖垮,并且访问友好的信息,告诉服务不要再盲目调用了。
-
闭合状态 -
半开状态 -
断开状态 -
熔断工具- Hystrix
-
幂等:我们知道,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。那么就需要对单次操作赋予一个全局的 id 来做标识,这样多次请求后我们可以判断来源于同个客户端,避免出现脏数据。
-
全局一致性 ID -
Snowflake
数据调度
状态转移
分库分表
分片分区
自动化运维
配置中心
-
switch -
diamend
部署策略
-
停机部署 -
滚动部署 -
蓝绿部署 -
灰度部署 -
A/B 测试
作业调度
-
SchedulerX -
Spring 定时任务
应用管理
-
应用重启 -
应用下线 -
日志清理
容错处理
-
主动是在错误出现的时候,我们试图再试试几次,说不定就成功了,成功的话就可以避免了该次错误 -
被动方式是错误的事情已经发生了,为了挽回,我们只是做时候处理,把负面影响降到最小
重试设计
事务补偿
全栈监控
基础层
-
CPU、IO、内存、线程、吞吐
中间件
应用层
-
性能监控:应用层面的需要对每个应用服务的实时指标(qps,rt),上下游依赖等进行监控
-
业务监控:除了应用本身的监控程度,业务监控也是保证系统正常的一个环节,通过设计合理的业务规则,对异常的情况做报警设置
监控链路
-
zipkin/eagleeye -
sls -
goc -
Alimonitor
故障恢复
应用回滚
基线回退
版本回滚
性能调优
分布式锁
高并发
异步
总结
正在报名活动推荐
以上是关于一文读懂分布式架构知识体系(内含超全核心知识大图)的主要内容,如果未能解决你的问题,请参考以下文章