Distribute System | Liao Lile

Kubernetes上的分布式系统

Sat, 28 May 2022 16:23:10 +0000

分布式系统不仅仅是运行时，还是开发时、构建时、运维时；分布式系统需要4个方面的能力，包括生命周期的管理、网络通讯能力、资源绑定能力以及有状态逻辑的处理。

系统的生命周期能力，我们需要一个可靠且全自动化的打包和部署、回滚、健康检查。能够实现应用在不同节点的分发，且资源隔离、扩展、配置可管理。这些能力就是第一位的基础。

网络的连接能力是分布式系统的第二要素。可靠韧性的连接到其他的服务，无论集群内还是集群外，分布式系统预期有服务发现、负载均衡等能力。同时由于不同的流量策略，需要具备流量转移的能力。服务的韧性在网络方面体现在超时重试、断路器等。围绕网络还要有安全保障，足够的监控、追踪和可观察性。

分布式系统的有能力与不同的API和端点交互，即资源绑定与其协议不同的数据格式交互，甚至从一种数据格式到另外一种数据格式的转换。对于消息数据的点对点pub/sub交互，以及数据的过滤，数据的路由；

关于依赖状态的开发人员抽象，分布式系统需要有工作流的管理能力，管理长进程以及短周期的调度任务，依赖分布式缓存，需要具有幂等性和支持回滚。这些均需要考虑系的同内部的已有状态的处理，依赖于开发人员的抽象。

技术架构的演进从单体到微服务再到云原生架构；

按照业务领域进行划分出现了微服务，容器和Kubernetes是管理这些微服务的优秀平台。Readiness和Liveness探测在kubernetes对于容器的生命周期管理至关重要，一个是确定应用在启动期间何时可以接受外部流量，一个是检查服务的健康状况；

LivenessProbe，判断容器是否存活running状态，如果不健康会kill后重启处理；
ReadinessProbe，判断容器服务是否可用ready状态，ready后的pod才接受来自外部的数据。Service同Pod Endpoint之间的关联关系基于该Pod的Ready状态进行设置；

Kubernetes 可以启动你的应用；它可以将其关闭，然后在不同的节点上移动它。为此，你必须正确执行平台在应用启动和关闭期间告诉你的事件。围绕声明式部署，声明资源需求，部署策略，应用程序同时需要执行来自环境的事件（健康检查、应用就绪度等）；实现整个部署的资源隔离、配置管理、故障隔离；

Kubernetes中的Pod有两个约束：

Pod的部署会确保所有的容器均在同一个节点；各个容器间可以通过localhost进行通信，也可以通过其他的类似文件共享/IPC机制等；
Pod中的容器生命周期可以不同，分为Init容器和应用容器，Pod启动时，Init容器按顺序一个一个运行，仅前一个成功后一个才运行；应用容器是并行运行的，在整个Pod生命周期中运行；

K8s内部依赖调谐循环来确保状态和声明一致，将期望的状态驱动到与实际状态。

REF

分布式系统的设计

Tue, 24 May 2022 12:23:10 +0000

分布式系统应该具有的架构特性（设计方向）：高并发、可扩展性、高可用性、高性能。同时分布式系统中存在的一致性问题，也需要有对应的解决方案。

高并发并不是一种技术，而是系统要面临的技术技术场景。在这个场景下，确保高并发时的用户体验，系统不应该出现错误且以极快的速度给用户响应。可用性、可扩展性、高性能就是用于定量分析高并发系统的3个视角。

分布式系统的高可用性

目标是为了让系统尽可能不发生错误，或者发生错误后的损失降到最低。系统运行时间是定量，不可用时间是变量。

发布/故障/压力/外部依赖导致可用性问题

变化数量*变化产生故障的比例*故障的影响*故障持续的时间

初始设计按照20/10/5来分别设计、开发、发布，这里说的数字是实际流量的倍数。

容错设计，单点故障、特性开关、服务分级、降级设计、超时重试

隔离策略：进程、用户、集群、租户、物理、逻辑

熔断：失败时候主动切断避免灾难发生

流控：流控算法/流控策略（在什么地方做流控）

容量预估：全链路压测明白系统的当前能力现状，而不是单接口、单业务，生产环境直接压；

故障演练：故障模式梳理以及实践验证容灾方案

数据迁移：逻辑分离/物理分离

分布式系统的高性能

目标是为了让尽可能多的用户，用尽可能少的时间得到系统的响应。任务目标是定量，任务完成耗时是变量。

内存IO时间+网络IO时间+CPU时间+磁盘IP时间+等待时间¹

响应时间/吞吐量/负载敏感度/可伸缩性

附在敏感度为系统响应是随时间变化的程度，需要可量化。用户请求过多的时候，系统响应时间是如何的一个衰减速度。

可伸缩性为系统扩容增加资源对于性能的影响，可量化衡量，即吞吐量扩1倍，需要多少服务资源的衡量；

分布式系统的可扩展性

目标是为了支撑可用性和高性能，在一些特殊情况下，不得不对系统系统进行调整时，能够以低成本的方式完成的能力。

AKF扩展立方体

可以沿着X/Y/Z轴三个方向进行扩展。

X轴扩展也叫水平扩展/横向扩展，通过复制实例（往往无状态），前端对流量进行负载均衡，分摊整体压力为目的进行扩展。

Y轴扩展依据服务或者资源扩展，依据服务拆分，各个微服务依据当前能力独立进行横向扩展，降低当前系统的复杂度

Z轴扩展依据当前的业务查询或计算结果进行拆分，即分片的思想。基于分区扩展，扩展性更强，突破单张表的数据规模上限，但是对于数据迁移复杂；

数据库的X/Y/Z轴扩展：主从复制、分库/分表、分片sharding

分布式系统的一致性设计

事务：原子性、一致性、隔离性、持久性

CAP定理：一致性/可用性/分区容错性，三选二

BASE理论：强一致性、弱一致性、最终一致性；依据业务的考量来决策，不一致性场景下时候是基本可用、不可用、可接受；

Quorum机制：强一致性的保障在写入数据的时候，所有节点成功后才算成功，此时写性能较差；转变思路为在读的阶段再决策，确保每次均能读到最新的数据。Quorum机制满足公式：备份个数N<成功写入W个+读取R个备份

租约机制Lease：为了实现一致性，确保节点中有一个leader，leader负责数据写入、follower负责数据读取，管理节点M通过心跳判断各个节点，指定Leader，Leader故障后重新选取Leader。

脑裂：Paxos、Raft、Lease算法确保

分布式系统最终体现在数据的一致性（严格一致性、顺序一致性、因果一致性）：

X轴扩展数据可以是多个副本，多个副本不同的物理存储，故障时可以访问正常的副本数据；需要解决数据写入性能问题

Z轴扩展对数据进行分区，即Sharding；

分布式系统的用户（泛化）一致性模型（需要有标识，且唯一）：

单调读一致性，单调写一致性、写后读一致性、读后写一致性

弱一致性：写入一个数据成功后，在数据副本上可能读出来，也可能读不出来，不保证每个副本的数据一定一致；

最终一致性：写入一个数据后，在其他副本有可能读不到最新值，单在某个时间窗口之后保证能最终读到；（重试机制、本地日志复制如binglog、可靠事件模式、Saga事务模型，TCC事务模型）

强一致性：数据一旦写入成功，任何副本上在写入后的任意时刻都能读到最新值；实现模型：两阶段提交/三阶段提交

分布式系统中的八大谬误

网络是可靠的

实际不是可靠的，应用系统中需要做的事情可能有：retry，acknowledge import messages, identify/ignore duplicates, record messages, verifiy message integrity。
传输是无延迟

延迟指数据从一个地方传递到另一个地方需要的时间，这中间带宽决定了同时可以传输多少数据。
带宽是无限的

其实不是，随着带宽的增长，我们传输的数据量也在增加，同时传输就存在丢包的问题。在信息的传递和延迟之间是要trade-off。
网络是安全的

通往网络的安全是多层的，包括基础设施、网络传输和应用层等；
拓扑是不变的

系统中不应该依赖特定的路由或节点，需要同时提供位置透明性和发现服务
传输是无成本的

我们从应用层到传输层的数据传递，需要对数据进行编码，这需要消耗时间和计算资源。而设置和运行网络都是需要代价，需要金钱购买。
网络是同构的

不应该在应用层去依赖一些自营的协议，而是通用的协议。
只有一个管理员

当没有出现问题的时候，我们不需要管理员。但是一旦问题发生，就会抓狂的需要。

REF

Latency Numbers Every Programmer Should Know (github.com) ↩︎

说说缓存

Mon, 04 Oct 2021 23:23:10 +0000

缓存使用场景：

从硬件的角度来说，缓存就是可以进行高速数据交换的存储器。最经典例子就是CPU层面的多级缓存：性能最高的寄存器、多级缓存L1/L2/L3、主存，外部的机械硬盘。计算机总是优先从读写性能最好的存储器中来读写数据。

从中间件的角度来看，缓存在数据库中应用，如Mysql拿到一个查询请求后，先会查询缓存是否命中（key为查询语句，value为查询的结果），如果命中则返回；实际中不建议，对于业务表查询缓存失效的概率极高；

RocketMQ中的缓存，是在Page Cache机制的预读作用下使得Consumer queue文件的读性能几乎接近内存。Page Cache是操作系统对文件的缓存，使用一部分内存用作Page Cache。对于数据的写入，操作系统会先写入至Cache中，随后异步的方式由pdflush¹内核线程将Cache内的数据刷盘。对于数据读取，如果未出现命中Page Cache，操作系统从屋里磁盘上访问读取文件同时，会顺序对其相邻块数据文件进行预读取Read Ahead。Page Cache利用的是时间局部性原理，最近访问的数据接下来再次访问当。预读取数据放入Page Cache利用的是空间局部性原理，依据数据往往是连续访问。

Elastic Search中的缓存²包括Query Cache/Filter Cache、Request Cache、Field Data Cache。Query Cache就是对一个查询中包含的过滤器执行结果进行缓存；Request Cache模块就是为了缓存这些“分片级”的本地结果集，一个面向请求的缓存，缓存的key是查询DSL字符串。Fielddata是专门针对分词的字段在query-time（查询期间）的数据结构的缓存。

常见主流的缓存算法：

LRU(Least-Recently-Used): 替换掉最近请求最少的对象，实际中使用最广。cpu缓存淘汰和虚拟内存效果好，web应用欠佳
LFU(Least-Frequently-Used): 缓存污染问题(一个先前流行的缓存对象会在缓存中驻留很长时间)
LRU2(Least Recently Used 2): 为什么LRU2优于LRU：当一次访问过来的时候，在缓存系统中找出最少最近使用的对象是一项时间复杂度非常高的运算，这就是为什么LRU2是最好的选择。
2Q(two queues)。多级缓存
SIZE：替换占用空间最大的。也会有缓存污染
LRU-Threashold：不超过某一个size 的，其他与 LRU 相同
Log(Size) + LRU: 替换 size 最大的对象，当size相同按 LRU 替换
Hyper-G: LFU 改进版，同时考虑上次访问时间和对象 size
Pitkow/Recker: 替换最近最少使用对象，除非所有对象都是今天访问过的。如果是，替换调最大的对象
Lowest-Latency-First: 替换下载时间最少的，最小化平均延迟
Hybrid Hybrid: 保留效用最低的会被替换掉
Lowest Relative Value(LRV): 替换保留效用最低的
Adaptive Replacement Cache(ARC)
Most Recently Used(MRU)
First in First out(FIFO)
Random Cache

缓存的应用：

以web应用为例说明，用户请求到后台，会先从缓存中取数据，如果在缓存中取到数据，就直接返回结果，如果取不到数据就需要查询数据库，从数据库中取数据，从数据库中取到数据后会同步更新到缓存，并返回结果。下一个用户就可以直接从缓存中取值了。那如果在数据库也没有取到，就只能直接返回空结果。在该场景下，缓存主要是为了缓解数据库访问压力，提升请求响应；

flowchart LR id1[用户请求] id2{Redis中请求特征Key是否存在} id3[获取redis中数据] id4{数据库中请求特征key是否存在} id5[更新Redis数据] id6[返回空] id7[返回Redis数据] E[结束] id1[用户请求] -->id2 id2 -->|Yes|id3 id2 -->|No| id4 id3 --> id7 id7 --> E id4 --> |Yes|id5 id4 --> |No| id6 id5--> id7 id6--> E

缓存失效或者异常，导致访问压力流转到数据库，使得数据库负载过高；归于提升缓存命中率，同时数据库需要限流；

缓存穿透:

外部可以非法请求一个缓存和数据库中必定不存在的数据，让其击穿缓存直接打到数据库，不断的大流量攻击就可以让数据库瘫痪。应对这种情况的发生，使用布隆过滤器进行过滤避免击穿，布隆过滤器存储空间小，可以存储大量的key。但是存在误判：布隆过滤器中没有的元素一定没有，但是布隆过滤器提示有的元素不一定有。
缓存击穿：

当缓存数据失效的瞬间，大量的请求打入而没有命中导致直接打入数据库；需要通过互斥锁让线程回写缓存，其他线程等待回写缓存后再读取，这种方案缺点是吞吐量不够；另外可以设置热点数据不过期，或者异步线程基于要过期的数据缓存重构建；
缓存雪崩：

缓存中数据大批量到过期时间，而查询数据量大落在数据库上，引起数据库压力大而宕机。缓存击穿是并发查询同一条数据，缓存雪崩是不同数据都过期了，很多数据查不到而查数据库。需要结合业务分析进行缓存预热，针对热key的失效点均衡分布。
缓存预热异常

系统上线后，不需要用户访问后才加载缓存数据，而是先查数据库构建好缓存；
缓存降级异常

缓存降级是指缓存失效的或者缓存服务器宕机后，不去访问数据库，而是直接返回默认数据或者访问服务的内存数据。降级一般是有损的，需要考虑其对业务的影响；

分布式系统中的概念

Sat, 18 Jul 2020 13:23:10 +0000

[toc]

分布式技术理论涉及范围广，包括系统开发、架构设计、网络通信等，本篇聚焦介绍在分布式系统中大家需要理解的一些概念。

该篇文章会持续的更新，以期覆盖更全的内容概念。

1、系统开发

高内聚/低耦合

软件模块是由相关性强的代码组成，软件模块需要做到内聚，反映的是模块内部联系紧密。模块应该是单一责任原则，各个模块之间独立。同时模块间要低耦合，这取决于模块间接口定义的复杂性、调用的方式以及传递的消息。模块高内聚后，往往模块间也会是低耦合。
过度设计

过多的面向未来的设计(把简单的事情想复杂了)，过度追求模块化、可扩展性、设计模式等而引入了系统的复杂性；
过早优化

开发过程的早期，未来需求的变化走向未清洗的时候，优化导致新的需求无法很好实现，而且优化的预期可能是错的，而简介把代码弄得复杂。
重构

通过调整代码改善软件的质量、性能，使程序的设计模式和架构更加合理，软件的可扩展性和维护性也得到提高。
破窗效应

系统代码或者架构设计的隐患存在的时候，那这个隐患在将来的时候已经会出现，同时随着事件的推移隐患会越越重，因此需要尽早的消除当前的隐患.
零信任原则

程序运行的上下游整个链路中，任何一个节点不能保证绝对可靠，任何一个点都可能随时发生故障或者不可预期的行为。
持久化

程序对于由状态的数据需要进行存储，也就是临时状态和持久状态间的转化，比如内存的中的数据持久化到磁盘。
临界区

表示一种公共资源或者共享数据，可以被多个线程或进程使用，但是每次只能允许其中一个使用。临界资源一但被占用，其他的使用者就需要等待。
阻塞/非阻塞

临界区资源的等待就是阻塞。如果占用资源的线程一直不释放资源，那么所有阻塞在临界区上的线程都不能工作。而非阻塞即允许多个线程同时进入临界区。
同步/异步

具体指应用对于请求的处理，同步时在收到请求/调用时候在没有得到结果之前，就不会返回结果。而异步调用会瞬间返回，但是异步返回的内容并不代表任务处理完成了，往往需要回调或者其他方式在任务完成后通知调用防。如WebFlux框架支持的异步；
并发/并行

并行是指同一时刻，由多条指令在多个处理器上同时执行；无论宏观和微观都是一起执行；并发是指同一时刻只有一条指令执行，但多个进程指令被快速的轮转执行，在时间上分成若干段，多个进程快速交替执行；

2、架构设计

高并发

通过设计保证系统能够同时并行处理很多请求。也就是同时间点，很多用户同时访问系统的能力。常用的指标如TPS/QPS来衡量。
高可用

经过设计能够达到系统停工时间的减少，确保系统在任何时候都能够正常的对外提供服务。
读写分离

往往是为了确保如数据库产品的稳定性，往往把系统做拆分，其中某个节点提供增删改的业务，其他的节点主要提供读的操作；
冷备/热备

冷备为一台运行，另一台不运行作为备份，应对其中一台宕机后使用。冷备需要主动切换服务。而热备是active/standby，当active服务出现故障，通过检测手段发现后激活standby，确保短时间内服务完全恢复正常使用。
异地多活

不同城市建设独立的数据中心，如三地二中心的容灾模式。活是相对于冷备份而言，冷备份是全量数据备份，平时不支撑业务需求，只在主机房出现故障的时候才切换到备用机房。多活是指这些机房在日常的业务中也需要走流量做业务支撑。
负载均衡

使用堕胎服务器进行流量分发的负载均衡服务。可以在多个实例间分配应用程序的对外服务能力，消除单点故障。实现应用程序的更高的容错能力。
动静分离

web服务器架构中，静态页面和动态页面，静态内容接口和动态内容接口分开不同系统访问的架构设计方法，进而提升整个服务访问性能和可维护性。
集群

单台服务器对于并发的承载有限，通过横向扩容，突破单台服务器的瓶颈，将堕胎服务器组合起来提供服务，即为集群服务，可以成倍的提升整个系统的并发处理能力。
分布式

一个完整的系统拆分成多个独立的子系统，每个子系统称为服务，分布式系统将请求分发到不同的子系统，让不同的服务来处理不同的请求。分布式系统中，子系统独立的运行，通过网络通信连接起来实现数据互通和组合服务。
CAP理论

在分布式系统中，Consistency、Availability、Partition Tolerance不能同时成立。一致性要求同一时刻点，分布式系统的所有的数据备份都相同或处于同一状态；可用性要求系统集群一部分节点宕机后，系统依然能够正确的响应用户的请求。分区容错性是需要系统能够容忍节点之间网络通信的故障。由于分布式系统分区是存在的，往往在一致性和可用性之间做出选择；
BASE理论

Basically Available/Soft State/Eventually consisitence，对于CAP理论的扩充，对一致性和可用性进行权衡的结果。我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式使系统达到最终一致性。
水平扩展/垂直扩展/Z轴扩展

水平扩展就是scale out更多的实例来分散负载，提升存储能力和计算能力。垂直扩展scale up通过提升单机硬件性能或者软件/架构性能来达到；Z轴扩展时依据sharding对于数据进行分片，让其路由到对应的sharding上进行数据的获取。或者说时Cell架构的扩容；
平行扩容

类似水平扩展，集群服务器中的节点均为平行对等节点，一般来说关键路径（登录，关键业务逻辑等）都需要支持运行时动态平行扩容。
弹性扩容

对部署的集群进行动态在线扩容，根据实际业务环境按照一定策略自动的添加更多的节点（包括存储节点、计算节点、网络节点）来增加系统容量、提高系统性能和可靠性。

3、网络通信

连接池

预先建立连接缓冲池，并提供一套连接使用、分配、管理策略，使得该连接池中的连接可以得到高效、安全的服用，避免频繁建立和关闭连接的开销。
断线重连

由于网络波动造成用户间接性断开与服务器的连接，待网络恢复之后服务器尝试将用户连接到上次断开时的状态和数据。
会话保持

识别客户端和服务端之间交互过程的关联性，在做负载均衡的同时保证相关联的访问都会分配到一台机器上，即一次会话过程中发起的多个请求都会落到同一台机器上。
长连接/短连接

均值TCP连接，长连接就是建立TCP连接后，一直保持这个连接，在此期间通过发送心跳来确认双方的存在，中间会做多次业务数据传输，一般不会主动断开连接。短连接一般就指连接建立后，执行一次事务后，然后关掉这个连接。
流量控制/拥塞控制

流量控制为了防止发送方太快，而接收方因为资源受限处理不了；拥塞控制是避免网络来不及处理而产生拥塞，进而引起整个网络性能下降的现象；
惊群效应

多进程在同时阻塞等待同一个事件的时候，如果等待的这个事件发生，他们他就会唤醒等待的所有进程。但是最终只有一个进程获得这个时间的控制权。对于没有获取到控制权的进程只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。
NAT

网络地址转换，替换IP报文头部的地址信息。NAT通常部署在网络出口位置，通过内部IP地址替换为出口IP地址提供公网可达性和上层协议的连接能力。

4、故障异常

宕机

计算机出现意外故障而死机，对应的服务不能对外提供。
coredump

程序出现异常而中断的时，OS会把程序的当前工作状态存储为一个coredump文件，通常情况下，该文件包含了程序运行时的内存、寄存器状态、堆栈指针，内存管理信息等。
缓存穿透/击穿/雪崩

穿透指查询一个一定不存在的数据，而导致流量积压到数据库上上旬；击穿指某个热点key过期时候，而这个时候大量该key的并发请求而导致流量也聚集到数据库上；雪崩指缓存中大批量到过期时间，而查询数据量大导致数据库压力过大的情况；
内存溢出/内存泄漏

内存溢出指程序申请内存时，没有足够的内存供申请者使用，此时回报OOM的失败；内存泄露指的时动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至崩溃。
句柄泄露

进程在调用系统文件后，没有释放已经发开的文件句柄。操作系统的交互是通过获取文件句柄来实现的，一般泄露后，机器变慢，CPU飙升；
死锁

两个或两个以上的线程执行过程中，由于竞争资源或者彼此通信而造成阻塞的现网。互相等待对方的资源。
软中断/硬中断

一般中断即指硬中断，主要用来通知操作系统系统外设状态的变化。软中断是硬中断服务程序对内核的中断，为了满足实时系统的要求，中断处理应该是越快越好。在发生中断时候，硬中断处理那些短时间就可以完成的工作，而将那些处理时间比较长的工作，当道中断之后来完成，也就是软中断来完成。
毛刺

短暂某一时刻，服务器性能的指标比如IO/CPU远大于该时刻前后时间段。毛刺的出现代表服务器资源利用不均匀，不充分容易诱发其他更严重的问题。
重放攻击

攻击者发送一个目的主机已经接受过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。该攻击下会不断恶意或欺诈性的重复一个有效的数据传输，可以由攻击发起者也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式获取的凭证，之后再把它重新发给认证服务器。
网络孤岛

网络孤岛是指分布式系统中，部分机器与整个集群失去网络连接，而分裂为一个小集群而且发生数据不一致的状况；
数据倾斜

对于集群系统，数据的分布也是分布式的，即不同的节点负责一定范围的数据。由于数据分散度不够，导致大量的数据集中到了一台或者几台服务节点上，称为数据倾斜，一般来说数据倾斜是由于负载均衡实时效果不好引起的。
脑裂

集群系统中，部分节点之间网络不可达而引起的系统分裂，不同分裂的小集群会按照各自的状态提供服务，原本集群会同时存在不一致的反应，造成节点间互相争抢资源、系统混乱、数据损坏。

5、监控告警

服务监控

主要目的是服务出现故障或问题时候能够准确快速的发现，避免产生更大范围的影响。可以分为系统层包括主机的一些CPU\磁盘等指标，应用层包括进程状态、吞吐量，业务层包括业务自定义的指标，服务响应类等，用户层关注在用户行为、舆情监控等；
服务拨测

拨测是探测服务可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常由异地多个。
节点探测

用来发现和追踪不同的机房节点之间网络可用性和通畅性的架空方式，主要通过响应时间、丢包率、跳数来度量。
告警去重

当告警恢复之前，不会有相同的告警持续产生；
告警抑制

为了减少系统抖动带来的干扰，还需要实现告警的抑制，比如服务器瞬间高负载可能是正常的，只有持续一段时间的高复杂才需要得到重视。这个往往可以通过连续告警探测次数来达到。
告警恢复

开发/运维人员不仅需要收到告警通知，还需要收到告警消除和告警恢复正常的通知。
告警合并

对同一时刻产生的多条相同告警进行合并，如某个集群服务同时出现多个子服务负载过高的告警，需要合并为一条告警；
告警收敛

某个告警产生时候，往往也会产生其他的告警，这时只对更笨原因产生告警，其他告警收敛为自告警一并发送原因。如某个主机网络不通的时候，可能伴随也是服务不可用的告警；
故障自愈

实时发现告警、预诊断分析自动恢复故障，并且打通周边系统实现整个流程的闭环。

6、服务治理

微服务

架构模式，单一应用划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值；服务间提供轻量级的通信机制。
服务发现

使用注册中心来记录分布式系统中全部的服务信息，以便其他依赖该服务的服务能够找到。
流量雪峰

流量的峰值可能是短暂的，为了节省机器资源，不能按照对大话资源的能力来支持短时间的高峰请求。需要有一定的手段进行高峰流量的削弱，让系统吞吐量在高峰请求下可控。常见的策略有队列、限频、分层过滤、多级缓存等；

限频指的是在同一时刻内，并发请求数不能超过某个值。
版本兼容

升级版本过程中，需要考虑版本升级后，新的数据结构是否能够兼容旧的数据结构，新修改的协议是否能够理解旧的协议。以及版本的升级依赖问题。
过载保护

当前负载已经超出了系统的最大处理能力，过载的出现，会导致部分服务不可用，如果处理不当可能造成整个服务的不可用，雪崩。针对这种异常的场景，需要做的保护措施，避免整个服务的不可用。
服务熔断

当出现服务不可用或响应超时的情况，为了防止整个系统出现雪崩，暂停对该服务的调用，往往熔断的是不重要的系统，避免影响核心业务。
服务降级

当服务器压力剧增的时候，更具业务情况及流量对服务有策略的降级，以释放资源保证核心任务的正常运行。降级的方式可以优雅，依据服务方式拒收请求或者延迟服务，或者依据服务范围砍掉某个功能。
熔断和降级

目标都是基于可用性和可靠性出发，防止系统崩溃，最终让用户体验到的是某些功能暂时不可用。服务熔断一般是某个下游服务故障引起，而服务降级一般是从整体负荷考虑；
故障屏蔽

把故障的机器，或者故障的服务从当前的集群剔除，确保新的请求不会进入到故障机器。