实现微服务的高可用：一份从0到1的必读手册

什么是高可用

在定义什么是高可用之前，我们可以先定义下什么是不可用：一个网站的内容最终呈现在用户面前需要经过若干个环节，而其中只要任何一个环节出现了故障，都可能导致网站页面不可访问，这个也就是网站不可用的情况。

参考维基百科，看看维基怎么定义高可用：

系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

这个难点或是重点在于“无中断”，要做到 7x24 小时无中断无异常的服务提供。

为什么需要高可用

一套对外提供服务的系统是需要硬件、软件相结合，但是我们的硬件总是会出故障，软件会有 Bug，硬件会慢慢老化，网络总是不稳定，软件会越来越复杂和庞大。

除了硬件软件在本质上无法做到“无中断”，外部环境也可能导致服务的中断，例如断电，地震，火灾，光纤被挖掘机挖断，这些影响的程度可能更大。

高可用的评价纬度

在业界有一套比较出名的评定网站可用性的指标，常用 N 个 9 来量化可用性，可以直接映射到网站正常运行时间的百分比上：

之前就职的一家互联网公司也是按照这个指标去界定可用性，不过在执行的过程中也碰到了一些问题。

例如，有一些服务的升级或数据迁移明明可以在深夜停机或停服务进行，然而考虑到以后的报告要显示出我们的系统达到了多少个 9 的高可用，而放弃停服务这种简单的解决方案，例如停机 2 个小时，就永远也达不到 4 个 9。

然而在一些高并发的场合，例如在秒杀或拼团，虽然服务停止了几分钟，但是这个对整个公司业务的影响可能是非常重大的，分分钟丢失的订单可能是一个庞大的数量。

所以 N 个 9 来量化可用性其实也得考虑业务的情况。

微服务高可用设计手段

高可用是一个比较复杂的命题，基本上在所有的处理中都会涉及到高可用，所有在设计高可用方案也涉及到了方方面面，如服务冗余、负载均衡、服务限流等。

这中间将会出现的细节是多种多样的，所以我们需要对这样一个微服务高可用方案进行一个顶层的设计，围绕服务高可用，先检查下我们手里有多少张牌。

服务冗余

网关不保存任何的 Session 数据，不提供会造成一致性的服务，将不一致的数据进行几种存储，借助更加擅长数据同步的中间件来完成。

这个是目前主流的方案，服务本身尽可能提供逻辑的服务，将数据的一致性保证集中式处理，这样就可以把“状态”抽取出来，让网关保持一个“无状态”。

这里仅仅是举了网关的例子，在微服务基本所有的服务，都应该按照这种思路去做。

如果服务中有状态，就应该把状态抽取出来，让更加擅长处理数据的组件来处理，而不是在微服务中去兼容有数据的状态。

数据存储高可用

之前上面说的服务冗余，可以简单的理解为计算的高可用，计算高可用只需要做到无状态既可简单的扩容缩容，但是对于需要存储数据的系统来说，数据本身就是有状态。

跟存储与计算相比，有一个本质的差别：将数据从一台机器搬到另一台机器，需要经过线路进行传输。

网络是不稳定的，特别是跨机房的网络，Ping 的延时可能是几十几百毫秒，虽然毫秒对于人来说几乎没有什么感觉，但是对于高可用系统来说，就是本质上的不同，这意味着整个系统在某个时间点上，数据肯定是不一致的。

按照“数据+逻辑=业务”的公式来看，数据不一致，逻辑一致，最后的业务表现也会不一致。

举个例子：

柔性化/异步化

• 服务端接收到请求后，服务端先回应答给客户端，再继续处理业务逻辑。

• 服务端接收到请求后，服务端把信息保存在消息队列或者数据库，回应答给客户端，服务端业务处理进程再从消息队列或者数据库上读取信息处理业务逻辑。

但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性。

兜底/容错

兜底可能是我们经常谈论的一种降级的方案，方案是用来实施，但是这里兜底可能更多是一种思想，更多的是一种预案，每个操作都可以犯错，我们也可以接受犯错。

但是每个犯错我们都必须有一个兜底的预案，这个兜底的预案其实就是我们的容错或者说最大程度避免更大伤害的措施，实际上也是一个不断降级的过程。

举个例子：

例如我们首页请求的用户个性化推荐商品的接口，发现推荐系统出错，我们不应该去扩大（直接把异常抛给用户）或保持调用接口的错误，而是应该兼容调用接口的错误，做到更加柔性化。

这时候可以选择获取之前没有失败接口的缓存数据，如果没有则可以获取通用商品不用个性化推荐，如果也没有可以读取一些静态文字进行展示。

由于我们架构进行了分层，分层 App，网关，业务逻辑层，数据访问层等等，在组织结构也进行了划分，与之对应的是前端组，后端业务逻辑组，甚至有中台组等等。

既然有代码和人员架构的层级划分，那么每一层都必须有这样的思想：包容下一层的错误，为上一层提供尽可能无错的服务。

举个例子：

商品的美元售价假设要用商品人民币售价/汇率，这个时候错误发生在低层的数据层，上一层如果直接进行除，肯定就抛出 java.lang.ArithmeticException: / by zero。

本着我们对任何一层调用服务都不可信的原则，应该对其进行容错处理，不能让异常扩散，更要保证我们这一层对上一次尽可能的作出最大努力确定的服务。

负载均衡

在使用 zookeeper作为注册中心时，故障的发现是由 ZK 去进行发现，业务逻辑层通过 Watch 的心跳机制将自己注册到 ZK 上，网关对 ZK 进行订阅就可以知道有多少可以调用的列表。

当业务逻辑层在重启或者被关闭时就会跟 ZK 断了心跳，ZK 会更新可调用列表。

使用 ZK 作为负载均衡的协调器，最大的问题是 ZK 对于服务是否可用是基于 Pingpong 的方式。

只要服务心跳存在，ZK 就认为服务是处在可用状态，但是服务如果处在假死的状态，ZK 是无从得知的。这个时候，业务逻辑服务是否真正可用只能够由网关知道。

幂等设计：为何会牵出幂等设计的问题，主要是因为负载均衡的 Failover 策略，就是对失败的服务会进行重试。

一般来说，如果是读操作的服务，重复执行也不会出问题，但想象一下，如果是一个创建订单减库存的操作，第一次调用也 Tomcat1 超时，再重新调用了 Tomcat2。

这个时候我们都不能确认超时调用的 Tomcat1 是否真的被调用，有可能根本就调用不成功，有可能已经调用成功但是因为某些原因返回超时而已。

所以，很大程度这个接口会被调用 2 次。如果我们没有保证幂等性，就有可能一个订单导致了减少 2 次的库存。

所谓的幂等性，就是得保证在同一个业务中，一个接口被调用了多次，其导致的结果都是一样的。

服务限流降级熔断

先来讲讲微服务中限流/熔断的目的是什么，微服务后，系统分布式部署，系统之间通过 RPC 框架通信，整个系统发生故障的概率随着系统规模的增长而增长，一个小的故障经过链路的传递放大，有可能会造成更大的故障。

限流跟高可用的关系是什么？假定我们的系统最多只能承受 500 个人的并发访问，但某个时候突然增加到 1000 个人进来，一下子就把整个系统给压垮了。

本来还有 500 个人能享受到我们系统的服务，突然间变成了所有人都无法得到服务。

与其让 1000 人都无法得到服务，不如就让 500 个人得到服务，拒绝掉另外 500 个人。限流是对访问的隔离，是保证了部门系统承受范围内用户的可用性。

熔断跟高可用的关系是什么？上面说了微服务是一个错综复杂的调用链关系，假设模块 A 调用模块 B，模块 B 又调用了模块 C，模块 C 调用了模块 D。

这个时候，模块 D 出了问题出现严重的时延，这个时候，整个调用链就会被模块 D 给拖垮。

A 等 B，B 等 C，C 等 D，而且 A B C D 的资源被锁死得不到释放，如果流量大的话还容易引起雪崩。

熔断，主动丢弃模块 D 的调用，并在功能上作出一些降级才能保证到我们系统的健壮性。熔断是对模块的隔离，是保证了最大功能的可用性。

服务治理

基础设施监控：例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性。 所以需要对网络的流量，丢包情况，错包情况，连接数等等这些基础设施的核心指标进行监控。

系统层监控：涵盖了物理机，虚拟机，操作系统这些都是属于系统级别监控的方面，对几个核心指标监控，如 CPU 使用率，内存占用率，磁盘 IO 和网络带宽情况。

应用层监控：例如对 URL 访问的性能，访问的调用数，访问的延迟，还有对服务提供性能进行监控，服务的错误率。 对 SQL 也需要进行监控，查看是否有慢 SQL，对于 Cache 来说，需要监控缓存的命中率和性能，每个服务的响应时间和 QPS 等等。

业务监控：比方说一个电商网站，需要关注它的用户登录情况，注册情况，下单情况，支付情况。 这些直接影响到实际触发的业务交易情况，这个监控可以提供给运营和公司高管他们需要关注的数据，直接可能对公司战略产生影响。

端用户监控：用户通过浏览器，客户端打开连到到我们的服务，那么在用户端用户的体验是怎么样，用户端的性能是怎么样，有没有产生错误，这些信息也是需要进行监控并记录下来。 如果没有监控，有可能用户因为某些原因出错或者性能问题造成体验非常的差，而我们并没有感知。

这里面包括了，监控用户端的使用性能，返回码，在哪些城市地区他们的使用情况是怎么样，还有运营商的情况，包括电信，联通用户的连接情况。

我们需要进一步去知道是否有哪些渠道哪些用户接入的时候存在着问题，包括我们还需要知道客户端使用的操作系统浏览器的版本。

总  结

出了那么多张牌，出牌只是术，真正的道还是得静下心来看看整个服务高可用的本质是什么。

随着微服务架构的相互调用越来越复杂，环节只会越来越多，只有建立清晰的架构和层次才能理清楚每个环节高可用的保障，保持简单。

从手段看高可用

主要使用的技术手段是服务和数据的冗余备份和失效转移，一组服务或一组数据都能在多节点上，之间相互备份。

当一台机器宕机或出现问题的时候，可以从当前的服务切换到其他可用的服务，不影响系统的可用性，也不会导致数据丢失。

从架构看高可用

保持简单的架构，目前多数网站采用的是比较经典的分层架构，应用层，服务层，数据层。

应用层是处理一些业务逻辑，服务层提供一些数据和业务紧密相关服务，数据层负责对数据进行读写。

简单的架构可以使应用层，服务层可以保持无状态化进行水平扩展，这个属于计算高可用。

相比计算高可用，在数据层思考的高可用则属于数据高可用，数据高可用相比计算高可用需要考虑到数据的一致性问题会更加的复杂。

这个时候 CAP 理论在里面会发挥关键的作用，究竟是选择 AP 或 CP，这个得根据业务去选择模型。

从硬件看高可用

首先得确认硬件总是可能坏的，网络总是不稳定的。解决它的方法也是一个服务器不够就来多几个，一个机柜不够就来几个，一个机房不够就来几个。

从软件看高可用

软件的开发不严谨，发布不规范也是导致各种不可用出现，通过控制软件开发过程质量监控，通过测试，预发布，灰度发布等手段也是减少不可用的措施。

从治理看高可用

一个系统在线上跑的好好的，但我们也不能确保它在下一秒会不会出现不可用状态。

将服务规范化，事前做好服务分割，做好服务监控，预判不可用的出现，在不可用出现之前发现问题，解决问题。

【注：文章部分内容参考 李云华《从 0 开始学架构》杨波老师《微服务》】

作者：陈于喆

简介：十余年的开发和架构经验，国内较早一批微服务开发实施者。曾任职国内互联网公司网易和唯品会高级研发工程师，后在创业公司担任技术总监/架构师，目前在洋葱集团任职技术研发副总监。

推荐阅读

实例演示：如何构建高可用的微服务架构

关于高可用负载均衡的探索

30+微服务构建的顶级工具清单

About Rancher Labs

Rancher Labs由CloudStack之父梁胜创建。旗舰产品Rancher是一个开源的企业级Kubernetes管理平台，实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐，被Forrester评为2018年全球容器管理平台领导厂商，被Gartner评为2017年全球最酷的云基础设施供应商。

目前Rancher在全球拥有超过一亿的下载量，并拥有包括中国人寿、华为、中国平安、兴业银行、民生银行、平安证券、海航科技、厦门航空、上汽集团、海尔、米其林、丰田、本田、中船重工、中联重科、迪斯尼、IBM、Cisco、Nvidia、辉瑞制药、西门子、CCTV、中国联通等全球著名企业在内的共25000家企业客户。