一文读懂分布式架构知识体系（内含超全核心知识大图）

做者 | 晓土  阿里巴巴高级工程师

姊妹篇阅读推荐：《云原生时代，分布式系统设计必备知识图谱（内含22个知识点）》

导读：本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 进化有着立体的认识；从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感觉如何搭建全套微服务架构的过程。

关注“阿里巴巴云原生”公众号，回复“分布”，便可下载分布式系统及其知识体系清晰大图！

随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工做过渡到多机器协做，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，完全打破传统的开发方式，解放了新一代的生产力。

分布式系统知识体系大图

关注“阿里巴巴云原生”公众号，回复“分布”，便可下载分布式系统及其知识体系清晰大图！

基础理论

SOA 到 MSA 的进化

SOA 面向服务架构

因为业务发展到必定程度后，须要对服务进行解耦，进而把一个单一的大系统按逻辑拆分红不一样的子系统，经过服务接口来通信。面向服务的设计模式，最终须要总线集成服务，并且大部分时候还共享数据库，出现单点故障时会致使总线层面的故障，更进一步可能会把数据库拖垮，因此才有了更加独立的设计方案的出现。

MSA 微服务架构

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

节点与网络

节点

传统的节点也就是一台单体的物理机，全部的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机每每能够分红多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年容器技术逐渐成熟后，服务已经完全容器化，也就是节点只是轻量级的容器服务。整体来讲，节点就是能提供单位服务的逻辑计算资源的集合。

网络

分布式架构的根基就是网络，无论是局域网仍是公网，没有网络就没法把计算机联合在一块儿工做，可是网络也带来了一系列的问题。网络消息的传播有前后，消息丢失和延迟是常常发生的事情，咱们定义了三种网络工做模式：

• 同步网络

  • 节点同步执行
  • 消息延迟有限
  • 高效全局锁

• 半同步网络

  • 锁范围放宽

• 异步网络

  • 节点独立执行
  • 消息延迟无上限
  • 无全局锁
  • 部分算法不可行

经常使用网络传输层有两大协议的特色简介：

• TCP 协议

  • 首先 tcp 协议传输可靠，尽管其余的协议能够更快传输
  • tcp 解决重复和乱序问题

• UDP 协议

  • 常量数据流
  • 丢包不致命

时间与顺序

时间

慢速物理时空中，时间独自在流淌着，对于串行的事务来讲，很简单的就是跟着时间的脚步走就能够，先来后到的发生。然后咱们发明了时钟来刻画以往发生的时间点，时钟让这个世界井井有理。可是对于分布式世界来讲，跟时间打交道着实是一件痛苦的事情。

分布式世界里面，咱们要协调不一样节点之间的先来后到关系，不一样节点自己认可的时间又互不相让，因而咱们创造了网络时间协议（NTP）试图来解决不一样节点之间的标准时间，可是 NTP 自己表现并不尽如人意，因此咱们又构造出了逻辑时钟，最后改进为向量时钟：

• NTP 的一些缺点，没法彻底知足分布式下并发任务的协调问题

  • 节点间时间不一样步
  • 硬件时钟漂移
  • 线程可能休眠
  • 操做系统休眠
  • 硬件休眠

• 逻辑时钟

  • 定义事件先来后到
  • t' = max(t, t_msg + 1)

• 向量时钟

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

顺序

有了衡量时间的工具，解决顺序问题天然就是水到渠成了。由于整个分布式的理论基础就是如何协商不一样节点的一致性问题，而顺序则是一致性理论的基本概念，因此前文咱们才须要花时间介绍衡量时间的刻度和工具。

一致性理论

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

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

强一致性 ACID

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

• Atomicity：原子性，一个事务中的全部操做，要么所有完成，要么所有不完成，不会结束在中间某个环节；
• Consistency：一致性，在事务开始以前和事务结束之后，数据库的完整性没有被破坏；
• Isolation：隔离性，数据库容许多个并发事务同时对其数据进行读写和修改的能力，隔离性能够防止多个事务并发执行时，因为交叉执行而致使数据的不一致；
• Durabilit：事务处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失。

分布式一致性 CAP

分布式环境下，咱们没法保证网络的正常链接和信息的传送，因而发展出了 CAP/FLP/DLS 这三个重要的理论：

• CAP：分布式计算系统不可能同时确保一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition）；
• FLP：在异步环境中，若是节点间的网络延迟没有上限，只要有一个恶意的节点存在，就没有算法能在有限的时间内达成共识；

• DLS：

  • 在一个部分同步网络的模型（也就是说：网络延时有界限可是咱们并不知道在哪里）下运行的协议能够容忍 1/3 任意（换句话说，拜占庭）错误；
  • 在一个异步模型中的肯定性的协议（没有网络延时上限）不能容错（不过这个论文没有提起随机化算法能够容忍 1/3 的错误）；
  • 同步模型中的协议（网络延时能够保证小于已知 d 时间），能够使人吃惊的达到 100% 容错，虽然对 1/2 的节点出错能够发生的状况有所限制。

弱一致性 BASE

多数状况下，其实咱们也并不是必定要求强一致性，部分业务能够容忍必定程度的延迟一致，因此为了兼顾效率，发展出来了最终一致性理论 BASE。BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）：

• 基本可用（Basically Available）：基本可用是指分布式系统在出现故障的时候，容许损失部分可用性，即保证核心可用；
• 软状态（Soft State）：软状态是指容许系统存在中间状态，而该中间状态不会影响系统总体可用性。分布式存储中通常一份数据至少会有三个副本，容许不一样节点间副本同步的延时就是软状态的体现；
• 最终一致性（Eventual Consistency）：最终一致性是指系统中的全部数据副本通过必定时间后，最终可以达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊状况。

一致性算法

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

首先咱们要了解一致性的大前提原则 (CALM):
CALM 原则的全称是 Consistency and Logical Monotonicity ，主要描述的是分布式系统中单调逻辑与一致性的关系，它的内容以下，参考 consistency as logical monotonicity。

• 在分布式系统中，单调的逻辑都能保证 “最终一致性”，这个过程当中不须要依赖中心节点的调度；
• 任意分布式系统，若是全部的非单调逻辑都有中心节点调度，那么这个分布式系统就能够实现最终“一致性”。

而后再关注分布式系统的数据结构 CRDT(Conflict-Free Replicated Data Types)：
咱们了解到分布式一些规律原则以后，就要着手考虑如何来实现解决方案，一致性算法的前提是数据结构，或者说一切算法的根基都是数据结构，设计良好的数据结构加上精妙的算法能够高效的解决现实的问题。通过前人不断的探索，咱们得知分布式系统被普遍采用的数据结构 CRDT。
参考《谈谈 CRDT》,A comprehensive study of Convergent and Commutative Replicated Data Types

• 基于状态（state-based）：即将各个节点之间的 CRDT 数据直接进行合并，全部节点都能最终合并到同一个状态，数据合并的顺序不会影响到最终的结果；
• 基于操做（operation-based）：将每一次对数据的操做通知给其余节点。只要节点知道了对数据的全部操做（收到操做的顺序能够是任意的），就能合并到同一个状态。

了解数据结构后，咱们须要来关注一下分布式系统的一些重要的协议HATs(Highly Available Transactions)，ZAB(Zookeeper Atomic Broadcast)：
参考《高可用事务》，《ZAB 协议分析》

最后要学习的是业界主流的一致性算法 ：
说实话具体的算法我也还没彻底搞懂，一致性算法是分布式系统最核心本质的内容，这部分的发展也会影响架构的革新，不一样场景的应用也催生不一样的算法。

• Paxos：《优雅的Paxos算法》
• Raft ：《Raft 一致性算法》
• Gossip：《Gossip Visualization》

这一节咱们说完分布式系统里面核心理论基础，如何达成不一样节点之间的数据一致性，下面咱们将会讲到目前都有哪些主流的分布式系统。

场景分类

文件系统

单台计算机的存储始终有上限，随着网络的出现，多台计算机协做存储文件的方案也相继被提出来。最先的分布式文件系统其实也称为网络文件系统，第一个文件服务器在 1970 年代被发展出来。在 1976 年迪吉多公司设计出 File Access Listener（FAL），而现代分布式文件系统则出自赫赫有名的 Google 的论文，《The Google File System》奠基了分布式文件系统的基础。现代主流分布式文件系统参考《分布式文件系统对比》,下面列举几个经常使用的文件系统：

• HDFS
• FastDFS
• Ceph
• mooseFS

数据库

数据库固然也属于文件系统，主数据增长了事务、检索、擦除等高级特性，因此复杂度又增长了，既要考虑数据一致性也得保证足够的性能。传统关系型数据库为了兼顾事务和性能的特性，在分布式方面的发展有限，非关系型数据库摆脱了事务的强一致性束缚，达到了最终一致性的效果，从而有了飞跃的发展，NoSql(Not Only Sql) 也产生了多个架构的数据库类型，包括 KV、列式存储、文档类型等。

• 列式存储：Hbase
• 文档存储：Elasticsearch，MongoDB
• KV 类型：Redis
• 关系型：Spanner

计算

分布式计算系统构建在分布式存储的基础上，充分发挥分布式系统的数据冗余灾备，多副本高效获取数据的特性，进而并行计算，把本来须要长时间计算的任务拆分红多个任务并行处理，从而提升了计算效率。分布式计算系统在场景上分为离线计算、实时计算和流式计算。

• 离线：Hadoop
• 实时：Spark
• 流式：Storm，Flink/Blink

缓存

缓存做为提高性能的利器无处不在，小到 CPU 缓存架构，大到分布式应用存储。分布式缓存系统提供了热点数据的随机访问机制，大大了提高了访问时间，可是带来的问题是如何保证数据的一致性，引入分布式锁来解决这个问题，主流的分布式存储系统基本就是 Redis 了。

• 持久化：Redis
• 非持久化：Memcache

消息

分布式消息队列系统是消除异步带来的一系列复杂步骤的一大利器，在多线程高并发场景下，咱们经常须要谨慎设计业务代码，来保证多线程并发状况下不出现资源竞争致使的死锁问题。而消息队列以一种延迟消费的模式将异步任务都存到队列，而后再逐个消化。

• Kafka
• RabbitMQ
• RocketMQ
• ActiveMQ

监控

分布式系统从单机到集群的形态发展，复杂度也大大提升，因此对整个系统的监控也是必不可少。

• Zookeeper

应用

分布式系统的核心模块就是在应用如何处理业务逻辑，应用直接的调用依赖于特定的协议来通讯，有基于 RPC 协议的，也有基于通用的 HTTP 协议。

• HSF
• Dubbo

日志

错误对应分布式系统是屡见不鲜，并且咱们设计系统的时候，自己就须要把容错做为广泛存在的现象来考虑。那么当出现故障的时候，快速恢复和排查故障就显得很是重要了。分布式日志采集存储和检索则能够给咱们提供有力的工具来定位请求链路中出现问题的环节。

• 日志采集：flume
• 日志存储：ElasticSearch/Solr，SLS
• 日志定位：Zipkin

帐本

前文咱们提到所谓分布式系统，是迫于单机的性能有限，而堆硬件却又没法无休止的增长，单机堆硬件最终也会遇到性能增加曲线的瓶颈。因而咱们才采用了多台计算机来干一样的活，可是这样的分布式系统始终须要中心化的节点来监控或者调度系统的资源，即便该中心节点也多是多节点组成。区块链则是真正的区中心化分布式系统，系统里面只有 P2P 网络协议各自通讯，没有真正意义的中心节点，彼此按照区块链节点的算力、权益等机制来协调新区块的产生。

• 比特币
• 以太坊

设计模式

上节咱们列举了不一样场景下不一样分布式系统架构扮演的角色和实现的功能，本节咱们更进一步概括分布式系统设计的时候是如何考虑架构设计的、不一样设计方案直接的区别和侧重点、不一样场景须要选择合做设计模式，来减小试错的成本，设计分布式系统须要考虑如下的问题。

可用性

可用性是系统运行和工做的时间比例，一般以正常运行时间的百分比来衡量。它可能受系统错误、基础架构问题、恶意攻击和系统负载的影响。分布式系统一般为用户提供服务级别协议（SLA），所以应用程序必须设计为最大化可用性。

• 健康检查：系统实现全链路功能检查，外部工具按期经过公开端点访问系统
• 负载均衡：使用队列起到削峰做用，做为请求和服务之间的缓冲区，以平滑间歇性的重负载
• 节流：限制应用级别、租户或整个服务所消耗资源的范围

数据管理

数据管理是分布式系统的关键要素，并影响大多数质量的属性。因为性能，可扩展性或可用性等缘由，数据一般托管在不一样位置和多个服务器上，这可能带来一系列挑战。例如，必须维护数据一致性，而且一般须要跨不一样位置同步数据。

• 缓存：根据须要将数据从数据存储层加载到缓存
• CQRS(Command Query Responsibility Segregation)： 命令查询职责分离
• 事件溯源：仅使用追加方式记录域中完整的系列事件
• 索引表：在常常查询引用的字段上建立索引
• 物化视图：生成一个或多个数据预填充视图
• 拆分：将数据拆分为水平的分区或分片

设计与实现

良好的设计包括诸如组件设计和部署的一致性、简化管理和开发的可维护性、以及容许组件和子系统用于其余应用程序和其余方案的可重用性等因素。在设计和实施阶段作出的决策对分布式系统和服务质量和整体拥有成本产生巨大影响。

• 代理：反向代理
• 适配器： 在现代应用程序和遗留系统之间实现适配器层
• 先后端分离： 后端服务提供接口供前端应用程序调用
• 计算资源整合：将多个相关任务或操做合并到一个计算单元中
• 配置分离：将配置信息从应用程序部署包中移出到配置中心
• 网关聚合：使用网关将多个单独的请求聚合到一个请求中
• 网关卸载：将共享或专用服务功能卸载到网关代理
• 网关路由：使用单个端点将请求路由到多个服务
• 领导人选举：经过选择一个实例做为负责管理其余实例管理员，协调分布式系统的云
• 管道和过滤器：将复杂的任务分解为一系列能够重复使用的单独组件
• 边车：将应用的监控组件部署到单独的进程或容器中，以提供隔离和封装
• 静态内容托管：将静态内容部署到 CDN，加速访问效率

消息

分布式系统须要一个链接组件和服务的消息传递中间件，理想状况是以松散耦合的方式，以便最大限度地提升可伸缩性。异步消息传递被普遍使用，并提供许多好处，但也带来了诸如消息排序，幂等性等挑战

• 竞争消费者：多线程并发消费
• 优先级队列： 消息队列分优先级，优先级高的先被消费

管理与监控

分布式系统在远程数据中心运行，没法彻底控制基础结构，这使管理和监视比单机部署更困难。应用必须公开运行时信息，管理员可使用这些信息来管理和监视系统，以及支持不断变化的业务需求和自定义，而无需中止或从新部署应用。

性能与扩展

性能表示系统在给定时间间隔内执行任何操做的响应性，而可伸缩性是系统处理负载增长而不影响性能或容易增长可用资源的能力。分布式系统一般会遇到变化的负载和活动高峰，特别是在多租户场景中，几乎是不可能预测的。相反，应用应该可以在限制范围内扩展以知足需求高峰，并在需求减小时进行扩展。可伸缩性不只涉及计算实例，还涉及其余元素，如数据存储、消息队列等。

弹性

弹性是指系统可以优雅地处理故障并从故障中恢复。分布式系统一般是多租户，使用共享平台服务、竞争资源和带宽，经过 Internet 进行通讯，以及在商用硬件上运行，意味着出现瞬态和更永久性故障的可能性增长。为了保持弹性，必须快速有效地检测故障并进行恢复。

• 隔离：将应用程序的元素隔离到池中，以便在其中一个失败时，其余元素将继续运行
• 断路器：处理链接到远程服务或资源时可能须要不一样时间修复的故障
• 补偿交易：撤消一系列步骤执行的工做，这些步骤共同定义最终一致的操做
• 健康检查：系统实现全链路功能检查，外部工具按期经过公开端点访问系统
• 重试：经过透明地重试先前失败的操做，使应用程序在尝试链接到服务或网络资源时处理预期的临时故障

安全

安全性是系统可以防止在设计使用以外的恶意或意外行为，并防止泄露或丢失信息。分布式系统在受信任的本地边界以外的 Internet 上运行，一般向公众开放，而且能够为不受信任的用户提供服务。必须以保护应用程序免受恶意攻击，限制仅容许对已批准用户的访问，并保护敏感数据。

• 联合身份：将身份验证委派给外部身份提供商
• 看门人： 经过使用专用主机实例来保护应用程序和服务，该实例充当客户端与应用程序或服务之间的代理，验证和清理请求，并在它们之间传递请求和数据
• 代客钥匙：使用为客户端提供对特定资源或服务的受限直接访问的令牌或密钥

工程应用

前文咱们介绍了分布式系统的核心理论，面临的一些难题和解决问题的折中思路，罗列了现有主流分布式系统的分类，并且概括了建设分布式系统的一些方法论，那么接下来咱们将从工程角度来介绍真刀真枪搭建分布式系统包含的内容和步骤。

资源调度

巧妇难为无米之炊，咱们一切的软件系统都是构建在硬件服务器的基础上。从最开始的物理机直接部署软件系统，到虚拟机的应用，最后到了资源上云容器化，硬件资源的使用也开始了集约化的管理。本节对比的是传统运维角色对应的职责范围，在 devops 环境下，开发运维一体化，咱们要实现的也是资源的灵活高效使用。

[](https://open.atatech.org/arti...

过去软件系统随着用户量增长须要增长机器资源的话，传统的方式就是找运维申请机器，而后部署好软件服务接入集群，整个过程依赖的是运维人员的人肉经验，效率低下并且容易出错。微服务分布式则无需人肉增长物理机器，在容器化技术的支撑下，咱们只须要申请云资源，而后执行容器脚本便可。

• 应用扩容：用户激增须要对服务进行扩展，包括自动化扩容，峰值事后的自动缩容
  
• 机器下线：对于过期应用，进行应用下线，云平台收回容器宿主资源
  
• 机器置换：对于故障机器，可供置换容器宿主资源，服务自动启动，无缝切换

网络管理

有了计算资源后，另外最重要的就是网络资源了。在现有的云化背景下，咱们几乎不会直接接触到物理的带宽资源，而是直接由云平台统一管理带宽资源。咱们须要的是对网络资源的最大化应用和有效的管理。

• 域名申请：应用申请配套域名资源的申请，多套域名映射规则的规范
• 域名变动：域名变动统一平台管理
• 负载管理：多机应用的访问策略设定
• 安全外联：基础访问鉴权，拦截非法请求
• 统一接入：提供统一接入的权限申请平台，提供统一的登陆管理

故障快照

在系统故障的时候咱们第一要务是系统恢复，同时保留案发现场也是很是重要的，资源调度平台则须要有统一的机制保存好故障现场。

• 现场保留：内存分布，线程数等资源现象的保存，如 JavaDump 钩子接入
• 调试接入：采用字节码技术无需入侵业务代码，能够供生产环境现场日志打点调试

流量调度

在咱们建设好分布式系统后，最早受到考验的关口就是网关了，进而咱们须要关注系统流量的状况，也就是如何对流量的管理，咱们追求的是在系统可容纳的流量上限内，把资源留给最优质的流量使用、把非法恶意的流量挡在门外，这样节省成本的同时确保系统不会被冲击崩溃。

负载均衡

负载均衡是咱们对服务如何消化流量的通用设计，一般分为物理层的底层协议分流的硬负载均衡和软件层的软负载。负载均衡解决方案已是业界成熟的方案，咱们一般会针对特定业务在不一样环境进行优化，经常使用有以下的负载均衡解决方案

• 交换机
• F5
• LVS/ALI-LVS
• Nginx/Tengine
• VIPServer/ConfigServer

网关设计

负载均衡首当其冲的就是网关，由于中心化集群流量最早打到的地方就是网关了，若是网关扛不住压力的话，那么整个系统将不可用。

• 高性能：网关设计第一须要考虑的是高性能的流量转发，网关单节点一般能达到上百万的并发流量
• 分布式：出于流量压力分担和灾备考虑，网关设计一样须要分布式
• 业务筛选：网关同设计简单的规则，排除掉大部分的恶意流量

流量管理

• 请求校验：请求鉴权能够把多少非法请求拦截，清洗
• 数据缓存：多数无状态的请求存在数据热点，因此采用 CDN 能够把至关大一部分的流量消费掉

流控控制

剩下的真实流量咱们采用不一样的算法来分流请求。

• 流量分配

  • 计数器
  • 队列
  • 漏斗
  • 令牌桶
  • 动态流控

• 流量限制在流量激增的时候，一般咱们须要有限流措施来防止系统出现雪崩，那么就须要预估系统的流量上限，而后设定好上限数，但流量增长到必定阈值后，多出来的流量则不会进入系统，经过牺牲部分流量来保全系统的可用性。

  • 限流策略
  • QPS 粒度
  • 线程数粒度
  • RT 阈值
  • 限流工具 - Sentinel

服务调度

所谓打铁还需自身硬，流量作好了调度管理后，剩下的就是服务自身的健壮性了。分布式系统服务出现故障是常有的事情，甚至咱们须要把故障自己当作是分布式服务的一部分。

注册中心

咱们网络管理一节中介绍了网关，网关是流量的集散地，而注册中心则是服务的根据地。

• 状态类型：第一好应用服务的状态，经过注册中心就能够检测服务是否可用
• 生命周期：应用服务不一样的状态组成了应用的生命周期

版本管理

• 集群版本：集群不用应用有自身对应的版本号，由不一样服务组成的集群也须要定义大的版本号
• 版本回滚：在部署异常的时候能够根据大的集群版本进行回滚管理

服务编排

服务编排的定义是：经过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。微服务环境下服务众多咱们须要有一个总的协调器来协议服务之间的依赖，调用关系，K8s 则是咱们的不二选择。

• K8s

• Spring Cloud

  • HSF
  • ZK+Dubbo

服务控制

前面咱们解决了网络的健壮性和效率问题，这节介绍的是如何使咱们的服务更加健壮。

• 发现资源管理那节咱们介绍了从云平台申请了容器宿主资源后，经过自动化脚本就能够启动应用服务，启动后服务则须要发现注册中心，而且把自身的服务信息注册到服务网关，便是网关接入。注册中心则会监控服务的不一样状态，作健康检查，把不可用的服务归类标记。

  • 网关接入
  • 健康检查

• 降级：当用户激增的时候，咱们首先是在流量端作手脚，也就是限流。当咱们发现限流后系统响应变慢了，有可能致使更多的问题时，咱们也须要对服务自己作一些操做。服务降级就是把当前不是很核心的功能关闭掉，或者不是很要紧的准确性放宽范围，过后再作一些人工补救。

  • 下降一致性约束
  • 关闭非核心服务
  • 简化功能

• 熔断：当咱们都作了以上的操做后，仍是以为不放心，那么就须要再进一步操心。熔断是对过载的一种自身保护，犹如咱们开关跳闸同样。好比当咱们服务不断对数据库进行查询的时候，若是业务问题形成查询问题，这是数据库自己须要熔断来保证不会被应用拖垮，而且访问友好的信息，告诉服务不要再盲目调用了。

  • 闭合状态
  • 半开状态
  • 断开状态
  • 熔断工具- Hystrix

• 幂等：咱们知道，一个幂等操做的特色是其任意屡次执行所产生的影响均与一次执行的影响相同。那么就须要对单次操做赋予一个全局的 id 来作标识，这样屡次请求后咱们能够判断来源于同个客户端，避免出现脏数据。

  • 全局一致性 ID
  • Snowflake

数据调度

数据存储最大的挑战就是数据冗余的管理，冗余多了效率变低并且占用资源，副本少了起不到灾备的做用，咱们一般的作法是把有转态的请求，经过转态分离，转化为无状态请求。

状态转移

分离状态至全局存储，请求转换为无状态流量，好比咱们一般会将登录信息缓存至全局 redis 中间件，而不须要在多个应用中去冗余用户的登录数据。

分库分表

数据横向扩展。

分片分区

多副本冗余。

自动化运维

咱们从资源申请管理的时候就介绍到 devops 的趋势，真正作到开发运维一体化则须要不一样的中间件来配合完成。

配置中心

全局配置中心按环境来区分，统一管理，减小了多处配置的混乱局面。

• switch
• diamend

部署策略

微服务分布式部署是屡见不鲜，如何让咱们的服务更好地支撑业务发展，稳健的部署策略是咱们首先须要考虑的，以下的部署策略适合不一样业务和不一样的阶段。

• 停机部署
• 滚动部署
• 蓝绿部署
• 灰度部署
• A/B 测试

做业调度

任务调度是系统必不可少的一个环节，传统的方式是在 Linux 机器上配置 crond 定时任务或者直接在业务代码里面完成调度业务，如今则是成熟的中间件来代替。

• SchedulerX
• Spring 定时任务

应用管理

运维工做中很大一部分时间须要对应用进行重启，上下线操做，还有日志清理。

• 应用重启
• 应用下线
• 日志清理

容错处理

既然咱们知道分布式系统故障是屡见不鲜，那么应对故障的方案也是不可或缺的环节。一般咱们有主动和被动的方式来处理：

• 主动是在错误出现的时候，咱们试图再试试几回，说不定就成功了，成功的话就能够避免了该次错误
• 被动方式是错误的事情已经发生了，为了挽回，咱们只是作时候处理，把负面影响降到最小

重试设计

重试设计的关键在于设计好重试的时间和次数，若是超太重试次数，或是一段时间，那么重试就没有意义了。开源的项目 spring-retry 能够很好地实现咱们重试的计划。

事务补偿

事务补偿符合咱们最终一致性的理念。补偿事务不必定会将系统中的数据返回到原始操做开始时其所处的状态。 相反，它补偿操做失败前由已成功完成的步骤所执行的工做。补偿事务中步骤的顺序不必定与原始操做中步骤的顺序彻底相反。 例如，一个数据存储可能比另外一个数据存储对不一致性更加敏感，于是补偿事务中撤销对此存储的更改的步骤应该会首先发生。对完成操做所需的每一个资源采用短时间的基于超时的锁并预先获取这些资源，这样有助于增长整体活动成功的可能性。 仅在获取全部资源后才应执行工做。 锁过时以前必须完成全部操做。

全栈监控

因为分布式系统是由众多机器共同协做的系统，并且网络也没法保证彻底可用，因此咱们须要建设一套对各个环节都能监控的系统，这样咱们才能从底层到业务各个层面进行监控，出现意外的时候能够及时修复故障，避免更多的问题出现。

基础层

基础层面是对容器资源的监测，包含各个硬件指标的负载状况

• CPU、IO、内存、线程、吞吐

中间件

分布式系统接入了大量的中间件平台，中间件自己的健康状况也须要监控。

应用层

• 性能监控：应用层面的须要对每一个应用服务的实时指标（qps，rt），上下游依赖等进行监控
• 业务监控：除了应用自己的监控程度，业务监控也是保证系统正常的一个环节，经过设计合理的业务规则，对异常的状况作报警设置

监控链路

• zipkin/eagleeye
• sls
• goc
• Alimonitor

故障恢复

当故障已经发生后，咱们第一个要作的就是立刻消除故障，确保系统服务正常可用，这个时候一般作回滚操做。

应用回滚

应用回滚以前须要保存好故障现场，以便排查缘由。

基线回退

应用服务回滚后，代码基线也须要 revert 到前一版本。

版本回滚

总体回滚须要服务编排，经过大版本号对集群进行回滚。

性能调优

性能优化是分布式系统的大专题，涉及的面很是广，这块简直能够单独拿出来作一个系列来说，本节就先不展开。自己咱们作服务治理的过程也是在性能的优化过程。
参考《高并发编程知识体系》

分布式锁

缓存是解决性能问题的一大利器，理想状况下，每一个请求不须要额外计算就马上能获取到结果时最快。小到 CPU 的三级缓存，大到分布式缓存，缓存无处不在，分布式缓存须要解决的就是数据的一致性，这个时候咱们引入了分布式锁的概念，如何处理分布式锁的问题将决定咱们获取缓存数据的效率。

高并发

多线程编程模式提高了系统的吞吐量，但也同时带来了业务的复杂度。

异步

事件驱动的异步编程是一种新的编程模式，摒弃了多线程的复杂业务处理问题，同时可以提高系统的响应效率。

总结

最后总结一下，若是有可能的话，请尝试使用单节点方式而不是分布式系统。分布式系统伴随着一些失败的操做，为了处理灾难性故障，咱们使用备份；为了提升可靠性，咱们引入了冗余。

分布式系统本质就是一堆机器的协同，而咱们要作的就是搞出各类手段来然机器的运行达到预期。这么复杂的系统，须要了解各个环节、各个中间件的接入，是一个很是大的工程。庆幸的是，在微服务背景下，多数基础性的工做已经有人帮咱们实现了。前文所描述的分布式架构，在工程实现了是须要用到分布式三件套 (Docker+K8S+Srping Cloud) 基本就能够构建出来了。

分布式架构核心技术分布图以下：

原图来源：https://dzone.com/articles/de...

分布式技术栈使用中间件：

原图来源：https://dzone.com/articles/de...

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术公众号。”

搜索「阿里巴巴云原生公众号」获取更多K8s容器技术内容