关于后端:浅谈服务接口的高可用设计

作者：京东批发 王磊

前言

作为一个后端研发人员，开发服务接口是我失常不过的工作了，这些接口不论是面向前端 HTTP 或者是供其余服务 RPC 近程调用的，都绕不开一个独特的话题就是“高可用”，接口开发往往看似简略，但保障高可用这块实现起来却不并没有想想的那么容易，接下来咱们就看一下，一个高可用的接口是该思考哪些内容，同时文中有有余的欢送批评指正。

到底啥是高可用

 用一句简略的话来概就是咱们的零碎具不具备应答和躲避危险的能力。

为啥做高可用

1. 程序都是有人开发的，在开发过程中会犯错从而导致线上事变的产生
2. 零碎运行依赖各种运行环境：CPU、内存、硬盘、网络等等，而这些都有可能损坏
3. 业务拉新用户正在注册账号，后果注册接口挂了用户体验受影响
4. 双十一、618 等大促大量用户下单，后果下单服务接口挂了 GMV 受影响等等
5. 其余未知因素等等
总之为了应答这些不可控因素的产生，咱们必须要做高可用 

高可用的关键点

咱们说过高可用的实质是零碎是否具备应答和躲避危险的能力，那么从这个角度登程来设计高可用接口的有以下几个关键因素：Dependence（依赖）、Probability（概率）、Time（时长）、Scope（范畴）

1. 依赖的资源绝对少
2. 危险的概率足够低
3. 影响的范畴足够小
4. 影响时长足够短 

接口高可用设计的几个准则

联合这些关键点，咱们来看一下具体具体注意事项

1、管制依赖

能少依赖就少依赖，能不强依赖就不强依赖

 少依赖
例如：日常每分钟 10 个申请，查问 Mysql 数据即可满足，此时自觉引入 Redis 中间件，不仅浪费资源而且减少零碎复杂性

弱依赖
例如：用户注册服务强依赖新用户优惠券发放服务，当优惠券发放服务故障后，整个注册不可用，好的形式是采纳弱依赖，应用异步化的
形式，这样优惠券发送服务不可用时，不会影响注册链路。

2、防止单点

防止单点故障的外围是通过备份或者冗余疾速的进行容错

1. 咱们采纳多机房多实力部署咱们利用来保障故障危险摊派，一旦有一台服务器呈现问题，其余服务依然可能持续撑持咱们的服务
2. 每次上线咱们都会保留上一次上线公布版本，这样一旦上线的程序呈现问题咱们可能疾速回滚到上一版本
3. 每个接口至多保障 2 人晓得相干业务，一旦线上服务呈现问题，其中任何一人一个可能疾速解决相干线上问题
4. 不论是 Mysql 还是 Redis 等中间件都反对数据主备机群部署

相似的例子很多这里就不再一一列举了 

3、负载平衡

将危险进行摊派防止分险扩散

 例如：无论是 Ngnix 或者 JSF 的，其负载平衡目标就是尽量的将流量扩散到不同的服务器节点上，这样能够无效的保障单节点因零碎瓶颈
问题而引发一系列的危险。像下面这个例子我想每个研发人员都晓得也都会这么做，然而是不是所有的场景咱们都思考到平衡这个问题？例如：通常为了进步读并发的能力，咱们会把数据缓存到 JIMDB 中，然而因为缓存的 key 呈现了热点数据导致 JIMDB 单分片负载过高，恰
好，这个分片上也缓存了其余数据，然而因为 CPU 负载过高，导致查问性能变差，大量的超时，影响了业务。所以，咱们在接口设计
的时候，如果遇到相似场景，也要充分考虑数据存储的均衡性，同时针对热点数据做好监控，随时反对动静平衡。

4、资源隔离

隔离的目标将危险管制在可控范畴内，防止危险扩散

 例如：接口部署之间服务部署物理上是互相隔离的，防止单机房或者单服务器呈现故障影响整个服务

例如：咱们在存储业务数据的时候会将数据分库分表，数据通过不同分片存储，这样就不会导致某个服务器挂掉影响到整个服务 

5、接口限流

限流是一种保护措施，目标是将危险管制在可控范畴内

 咱们在开发接口的时候，肯定要联合业务流量状况进行限流措施，限流一方面处于对本身服务资源的爱护，同时也是对依赖资源的一种
保护措施。目前团体 JSF 在流量管制这块曾经有了对应的限流解决能力，同时咱们也能够结合实际业务进行限流模块的开发。

6、服务熔断

熔断也是一种保护措施，目标是将危险管制在可控范畴内，防止危险扩散

 例如：常常咱们服务 A 会同时调用 B、C、D 多个服务，当咱们依赖的服务其中一个呈现故障或者性能降落的时候，就是导致整体服务
可用率降落，所以咱们在开发此类服务的时候，肯定要留神接口之间的隔离。咱们能够利用相似 Hystrix 组件实现，也能够借助 DUCC
进行手动隔离。其实熔断也是一种管制资源依赖的一种，将强依赖降级为弱依赖 

7、异步解决

将同步操作转为异步操作

 例如：用户页面支付一些权利，针对支付这个服务在大促期间因为用户流量较大，为了防止零碎负载，此时采纳 MQ 异步接管用户支付
申请而后进行优惠券发放, 这样不仅极大的缩小了事变的影响范畴，也缩小问题产生概率。

8、降级计划

服务降级属于一种问题产生后的补救措施，通过服务降级能够缩小一部分危险影响范畴

 对于重要的服务接口咱们都要具备欠缺的降级计划，这里须要阐明的是，降级有损的，咱们肯定要在零碎开发前就要思考各种问题
产生的可能，降级的前提是通过降级非核心业务保障外围业务运行。例如：大促峰值期间，个别会提前降级掉很多性能，同时限流，次要是为了爱护峰值绝大部分人的交易领取体验。

9、灰度公布

通过灰度公布升高危险影响范畴

 例如：咱们上线一个新服务，通过肯定的灰度策略，让用户后行体验新版本的利用，通过收集这部分用户对新版本利用的反馈以及
对新版本性能、性能、稳定性等指标进行评论，进而决定持续放大新版本投放范畴直至全量降级或回滚至老版本。依据线上反馈后果，做到查漏补缺，发现重大问题，可回滚“旧版本”

10、混沌工程

通过提前对系统进行一些破坏性的伎俩，提前发现潜在问题

 例如：一个简单接口零碎依赖了太多的服务和组件，这些组件随时随地都可能会产生故障，而一旦它们产生故障，会不会如蝴蝶效应
个别造成整体服务不可用呢，咱们并不知道，因而咱们能够借助泰山平台混沌工程进行演练，针对产生的场景制订各种预案，将危险
管制在可控范畴内。