微服务如何保障稳定性？

做者：fredalxin\
地址：https://fredal.xin/talking-ms...

当一个单体应用改形成多个微服务以后，在请求调用过程当中每每会出现更多的问题，通讯过程当中的每个环节均可能出现问题。而在出现问题以后，若是不加处理，还会出现链式反应致使服务雪崩。服务治理功能就是用来处理此类问题的。咱们将从微服务的三个角色:注册中心、服务消费者以及服务提供者一一提及。

注册中心如何保障稳定性

注册中心主要是负责节点状态的维护，以及相应的变动探测与通知操做。一方面，注册中心自身的稳定性是十分重要的。另外一方面，咱们也不能彻底依赖注册中心，须要时常进行相似注册中心彻底宕机后微服务如何正常运行的故障演练。

这一节，咱们着重讲的并非注册中心自身可用性保证，而更多的是与节点状态相关的部分。

节点信息的保障

咱们说过，当注册中心彻底宕机后，微服务框架仍然须要有正常工做的能力。这得益于框架内处理节点状态的一些机制。

本机内存

首先服务消费者会将节点状态保持在本机内存中。一方面因为节点状态不会变动得那么频繁，放在内存中能够减小网络开销。另外一方面，当注册中心宕机后，服务消费者仍能从本机内存中找到服务节点列表从而发起调用。

本地快照

咱们说，注册中心宕机后，服务消费者仍能从本机内存中找到服务节点列表。那么若是服务消费者重启了呢？这时候咱们就须要一份本地快照了，即咱们保存一份节点状态到本地文件，每次重启以后会恢复到本机内存中。

服务节点的摘除

如今不管注册中心工做与否，咱们都能顺利拿到服务节点了。可是不是全部的服务节点都是正确可用的呢？在实际应用中，这是须要打问号的。若是咱们不校验服务节点的正确性，颇有可能就调用到了一个不正常的节点上。因此咱们须要进行必要的节点管理。

对于节点管理来讲，咱们有两种手段，主要是去摘除不正确的服务节点。

注册中心摘除机制

一是经过注册中心来进行摘除节点。服务提供者会与注册中心保持心跳，而一旦超出必定时间收不到心跳包，注册中心就认为该节点出现了问题，会把节点从服务列表中摘除，并通知到服务消费者，这样服务消费者就不会调用到有问题的节点上。

服务消费者摘除机制

二是在服务消费者这边拆除节点。由于服务消费者自身是最知道节点是否可用的角色，因此在服务消费者这边作判断更合理，若是服务消费者调用出现网络异常，就将该节点从内存缓存列表中摘除。固然调用失败多少次以后才进行摘除，以及摘除恢复的时间等等细节，其实都和客户端熔断相似，能够结合起来作。

通常来讲，对于大流量应用，服务消费者摘除的敏感度会高于注册中心摘除，二者之间也不用刻意作同步判断，由于过一段时间后注册中心摘除会自动覆盖服务消费者摘除。

服务节点是能够随便摘除/变动的么

上一节咱们讲能够摘除问题节点，从而避免流量调用到该节点上。但节点是能够随便摘除的么？同时，这也包含"节点是能够随便更新的么？"疑问。

频繁变更

当网络抖动的时候，注册中心的节点就会不断变更。这致使的后果就是变动消息会不断通知到服务消费者，服务消费者不断刷新本地缓存。若是一个服务提供者有100个节点，同时有100个服务消费者，那么频繁变更的效果可能就是100*100，引发带宽打满。

这时候，咱们能够在注册中心这边作一些控制，例如通过一段时间间隔后才能进行变动消息通知，或者打开开关后直接屏蔽不进行通知，或者经过一个几率计算来判断须要向哪些服务消费者通知。

增量更新

一样是因为频繁变更可能引发的网络风暴问题，一个可行的方案是进行增量更新，注册中心只会推送那些变化的节点信息而不是所有，从而在频繁变更的时候避免网络风暴。

可用节点过少

当网络抖动，并进行节点摘除事后，极可能出现可用节点过少的状况。这时候过大的流量分配给过少的节点，致使剩下的节点难堪重负，罢工不干，引发恶化。而实际上，可能节点大多数是可用的，只不过因为网络问题与注册中心未能及时保持心跳而已。

这时候，就须要在服务消费者这边设置一个开关比例阈值，当注册中心通知节点摘除，但缓存列表中剩下的节点数低于必定比例后（与以前一段时间相比），再也不进行摘除，从而保证有足够的节点提供正常服务。

这个值其实能够设置的高一些，例如百分之70，由于正常状况下不会有频繁的网络抖动。固然，若是开发者确实须要下线多数节点，能够关闭该开关。

服务消费者如何保障稳定性

一个请求失败了，最直接影响到的是服务消费者，那么在服务消费者这边，有什么能够作的呢？

超时

若是调用一个接口，但迟迟没有返回响应的时候，咱们每每须要设置一个超时时间，以防本身被远程调用拖死。超时时间的设置也是有讲究的，设置的太长起的做用就小，本身被拖垮的风险就大，设置的过短又有可能误判一些正常请求，大幅提高错误率。

在实际使用中，咱们能够取该应用一段时间内的P999的值，或者取p95的值*2。具体状况须要自行定夺。

在超时设置的时候，对于同步与异步的接口也是有区分的。对于同步接口，超时设置的值不只须要考虑到下游接口，还须要考虑上游接口。而对于异步来讲，因为接口已经快速返回，能够不用考虑上游接口，只需考虑自身在异步线程里的阻塞时长，因此超时时间也放得更宽一些。

容错机制

请求调用永远不能保证成功，那么当请求失败时候，服务消费者能够如何进行容错呢？一般容错机制分为如下这些:

• FailTry：失败重试。就是指最多见的重试机制，当请求失败后视图再次发起请求进行重试。这样从几率上讲，失败率会呈指数降低。对于重试次数来讲，也须要选择一个恰当的值，若是重试次数太多，就有可能引发服务恶化。另外，结合超时时间来讲，对于性能有要求的服务，能够在超时时间到达前的一段提早量就发起重试，从而在几率上优化请求调用。固然，重试的前提是幂等操做。
• FailOver：失败切换。和上面的策略相似，只不过FailTry会在当前实例上重试。而FailOver会从新在可用节点列表中根据负载均衡算法选择一个节点进行重试。
• FailFast：快速失败。请求失败了就直接报一个错，或者记录在错误日志中，这没什么好说的。

另外，还有不少形形色色的容错机制，大可能是基于本身的业务特性定制的，主要是在重试上作文章，例如每次重试等待时间都呈指数增加等。

第三方框架也都会内置默认的容错机制，例如Ribbon的容错机制就是由retry以及retry next组成，即重试当前实例与重试下一个实例。这里要多说一句，ribbon的重试次数与重试下一个实例次数是以笛卡尔乘积的方式提供的噢！

熔断

上一节将的容错机制，主要是一些重试机制，对于偶然因素致使的错误比较有效，例如网络缘由。但若是错误的缘由是服务提供者自身的故障，那么重试机制反而会引发服务恶化。这时候咱们须要引入一种熔断的机制，即在必定时间内再也不发起调用，给予服务提供者必定的恢复时间，等服务提供者恢复正常后再发起调用。这种保护机制大大下降了链式异常引发的服务雪崩的可能性。

在实际应用中，熔断器每每分为三种状态，打开、半开以及关闭。引用一张martinfowler画的原理图:

在普通状况下，断路器处于关闭状态，请求能够正常调用。当请求失败达到必定阈值条件时，则打开断路器，禁止向服务提供者发起调用。当断路器打开后一段时间，会进入一个半开的状态，此状态下的请求若是调用成功了则关闭断路器，若是没有成功则从新打开断路器，等待下一次半开状态周期。

断路器的实现中比较重要的一点是失败阈值的设置。能够根据业务需求设置失败的条件为连续失败的调用次数，也能够是时间窗口内的失败比率，失败比率经过必定的滑动窗口算法进行计算。另外，针对断路器的半开状态周期也能够作一些花样，一种常见的计算方法是周期长度随着失败次数呈指数增加。

具体的实现方式能够根据具体业务指定，也能够选择第三方框架例如Hystrix。

隔离

隔离每每和熔断结合在一块儿使用，仍是以Hystrix为例，它提供了两种隔离方式：

• 信号量隔离：使用信号量来控制隔离线程，你能够为不一样的资源设置不一样的信号量以控制并发，并相互隔离。固然实际上，使用原子计数器也没什么不同。
• 线程池隔离：经过提供相互隔离的线程池的方式来隔离资源，相对来讲消耗资源更多，但能够更好地应对突发流量。

降级

降级一样大多和熔断结合在一块儿使用，当服务调用者这方断路器打开后，没法再对服务提供者发起调用了，这时候能够经过返回降级数据来避免熔断形成的影响。

降级每每用于那些错误容忍度较高的业务。同时降级的数据如何设置也是一门学问。一种方法是为每一个接口预先设置好可接受的降级数据，但这种静态降级的方法适用性较窄。还有一种方法，是去线上日志系统/流量录制系统中捞取上一次正确的返回数据做为本次降级数据，但这种方法的关键是提供可供稳定抓取请求的日志系统或者流量采样录制系统。

另外，针对降级咱们每每还会设置操做开关，对于一些影响不大的采起自动降级，而对于一些影响较大的则需进行人为干预降级。

服务提供者如何保障稳定性

限流

限流就是限制服务请求流量，服务提供者能够根据自身状况(容量)给请求设置一个阈值，当超过这个阈值后就丢弃请求，这样就保证了自身服务的正常运行。

阈值的设置能够针对两个方面考虑，一是QPS即每秒请求数，二是并发线程数。从实践来看，咱们每每会选择后者，由于QPS高每每是因为处理能力高，并不能反映出系统"不堪重负"。

除此以外，咱们还有许多针对限流的算法。例如令牌桶算法以及漏桶算法，主要针对突发流量的情况作了优化。第三方的实现中例如guava rateLimiter就实现了令牌桶算法。在此就不就细节展开了。

重启与回滚

限流更多的起到一种保障的做用，但若是服务提供者已经出现问题了，这时候该怎么办呢？

这时候就会出现两种情况。一是自己代码有bug，这时候一方面须要服务消费者作好熔断降级等操做，一方面服务提供者这边结合DevOps须要有快速回滚到上一个正确版本的能力。

更多的时候，咱们可能仅仅碰到了与代码无强关联的单机故障，一个简单粗暴的办法就是自动重启。例如观察到某个接口的平均耗时超出了正常范围必定程度，就将该实例进行自动重启。固然自动重启须要有不少注意事项，例如重启时间是否放在晚上，以及自动重启引发的与上述节点摘除同样的问题，都须要考虑和处理。

在过后复盘的时候，若是当时没有保护现场，就很难定位到问题缘由。因此每每在一键回滚或者自动重启以前，咱们每每须要进行现场保护。现场保护能够是自动的，例如一开始就给jvm加上打印gc日志的参数-XX:+PrintGCDetails，或者输出oom文件-XX:+HeapDumpOnOutOfMemoryError，也能够配合DevOps自动脚本完成，固然手动也能够。通常来讲咱们会以下操做:

• 打印堆栈信息，jstak -l 'java进程PID'
• 打印内存镜像，jmap -dump:format=b,file=hprof 'java进程PID'
• 保留gc日志，保留业务日志

调度流量

除了以上这些措施，经过调度流量来避免调用到问题节点上也是很是经常使用的手段。

当服务提供者中的一台机器出现问题，而其余机器正常时，咱们能够结合负载均衡算法迅速调整该机器的权重至0，避免流量流入，再去机器上进行慢慢排查，而不用着急第一时间重启。

若是服务提供者分了不一样集群/分组，当其中一个集群出现问题时，咱们也能够经过路由算法将流量路由到正常的集群中。这时候一个集群就是一个微服务分组。

而当机房炸了、光缆被偷了等IDC故障时，咱们又部署了多IDC，也能够经过一些方式将流量切换到正常的IDC，以供服务继续正常运行。切换流量一样能够经过微服务的路由实现，但这时候一个IDC对应一个微服务分组了。除此以外，使用DNS解析进行流量切换也是能够的，将对外域名的VIP从一个IDC切换到另外一个IDC。
近期热文推荐：

1.600+ 道 Java面试题及答案整理(2021最新版)

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上全部 Mock 工具！

4.Spring Cloud 2020.0.0 正式发布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

以为不错，别忘了随手点赞+转发哦！