云音乐RPC稳定性建设与实践

本文作者：断空（王松松）

背景

在典型的微服务架构的架构中，RPC框架扮演着连接各个服务、组件的关键角色。作为云音乐的最基础组件之一，支撑了用户、会员、广告、数据平台等各个业务的平稳运行。然而随着当前云原生理念的快速发展落地，在当前整体降本增效的大背景下，对RPC也提出了新的挑战。一旦RPC框架出现问题，整个系统的可用性和性能都会受到影响，用户可能会面临播放中断、延迟增加等不良体验，导致用户的流失、客诉等。因此我们开始从架构、流程等各方面重新梳理，参考业界的优秀实践，结合音乐特殊的业务场景，我们开始了RPC的稳定性建设历程。

整体架构

由传统的单体应用迁移到微服务后，应用被拆分、部署到了独立的节点、集群，进程内的函数调用不再适用于分布式场景，于是RPC框架应运而生，但同样的也引入了一系列新的问题：

• 服务发现: consumer如何快速发现provider所有的节点？ provider下线后如何快速将通知下发到consumer

• 连接管理：单连接还是连接池？ 网络抖动后如何重连、自愈？

• 面向云原生：容器化部署后，节点异常、宕机常态化，如何快速感知异常节点并快速熔断

• 重试：请求异常、超时应当选择怎样的重试策略合适？

稳定性是一个非常复杂的话题，从故障的角度来看，可以分为以下几个阶段：

• 故障前：这个阶段主要是预防，例如在问题上升为故障前，通过自动化测试、流程规范管控、监控报警、等手段快速发现。

• 故障中：这个阶段主要是发现、恢复和定位故障。需要快速发现系统出现的故障，及时采取措施进行恢复，并准确定位故障原因，最大化降低对用户的影响。

• 故障后：这个阶段主要对故障发生的原因进行分析和总结，找出不足之处并采取措施进行改进，思考通过标准化、流程化、自动化的手段，避免同样的故障二次出现。

在后续的行文中，我们将从这几个方面来探讨稳定性的话题。

故障前

SLO体系建设

You can't manage what you can't measure.

就RPC而言，音乐内部有N套平台可以用于故障的发现、预警，例如异常日志、核心指标(线程池、CPU、内存、GC等)、自动化用例等。太多的指标会导致我们忽视真正核心的问题；而选择过少的指标，例如只有异常日志告警，会导致故障无法被及时发现。我们需要站在用户的角度思考问题，当用户使用一个系统是时候更关注的是哪些指标？例如CPU使用率达到80%是一个现象，我们更希望知道对用户的影响是什么，接口可用率下降还是RT升高？

SLO是什么？

SLO是指服务等级的目标值或范围值，通常用于衡量服务健康状况。SLO提供了一种标准化的方式来描述、衡量和监控微服务应用程序的性能、质量和可靠性。SLO为应用开发和平台团队、运维团队提供了一个共享的质量基准，可作为衡量服务水平质量以及持续改进的参考。 示例如下：

• 90%的RPC请求能够在200ms以内完成
• 99%的请求返回的code为200

对于RPC这种在线服务的场景来说，例如歌曲播放、查看评论、会员充值等场景，相对来说我们会更关注接口的成功率、延迟等核心指标，即接口能正常响应用户的请求吗？ 花了多久？ 因此前期我们选择了成功率、RT来作为SLO的数据源，并重分利用了SLO平台提供的监控、告警等能力，有效实现了对接口可用性的度量，当SLO出现波动时，开发需要及时介入排查。

日志治理

早期版本打印的日志非常混乱，大部分异常缺少说明，导致用户无从下手。因此我们针对日志进行了一系列治理措施。

• 链路串联：将日志和trace打通，当业务排查问题时，通过traceId即可将上下游所有应用关联在一起，并快速跳转到APM平台
• 异步适配：RPC和单体应用时代不同，天生就具备了异步的特性，请求发出后，consumer等待，而当provider处理完成之后，框架内部根据requestId关联到对应的请求，并将结果返回。过程中会存在很多线程池切换，例如业务现场、IO线程、worker线程等，而线程池的切换可能会导致traceId丢失，从而影响问题的排查。因此我们针对内部所有的异步、线程切换等进行了统一的治理，有效避免类似问题的发生。
• 梳理&&完善核心链路日志
• 日志标准化，例如统一前缀、模块，错误码等信息，从而能够根据接口、ip等信息快速匹配到相关异常日志

异常大盘

当前告警机制更多偏向应用、资源维度，例如应用的异常日志超出配置的阈值、线程池队列堆积等，而RPC作为中心化的组件，一旦出现问题爆炸半径往往不太可控。因此我们在思考如何能够快速的发现框架层的问题。

对于RPC来说，组件能的问题往往都会通过异常日志体现，例如超时、接口熔断、限流、服务上下线、未知异常等，因此我们通过梳理出所有的logger以及异常日志，并基于此构建了以RPC为中心的异常大盘。并提供了应用维度的topN计算、离群点检测、日志采样等丰富的能力，从而能够协助中心化负责人快速发现问题、确定受影响应用、并通过日志采样等功能进一步根因定位。

故障中

降级

降级平台目前在音乐内部广泛使用，当前已有数千应用接入，通过与降级平台的打通联动，RPC提供了丰富的降级能力：

• 模板规则：用户无需触动配置，当错误率查出一定阈值时，自动触发降级

• 支持丰富的兜底策略，例如fallback方法调用、固定值，并与缓存平台打通，支持故障时返回缓存中的数据

• 监控告警：具备丰富的指标监控以及告警能力，对于BFF等类网关应用，支持支持将告警分发给对应的接口负责人

• 动态调整：降级规则支持秒级动态调整与下发，应用无需重启、发布

• 便捷：无需主动接入，平台配置后动态生效

限流

通过接入内部的限流平台，提升应用对于异常流量的应对能力，并支持丰富的限流策略：

• 单机、并发限流

• 分布式限流

• 参数限流

• 高频限流等

离群节点剔除

在分布式系统中，宕机是常态时间，而站在服务消费者的层面来说，如果不能及时检测到服务提供者中的异常节点，并快速剔除，将会影响服务的可用性(SLO)，进而导致客诉。因此组件层面提供了离群节点检测与剔除能力，当个别节点错误率不符合预期时会将该节点剔除，在指定时间窗口内不再将流量分配到该节点，并再探活成功后，将该节点重新加入服务列表中。

线程池隔离

若所有的接口都路由到同一个线程池，那么这些接口变会资源争抢的风险，接口A的RT抖动，会导致接口B的吞吐下降，因此对于一些核心的业务，我们希望能够进行线程池的隔离。因此我们对RPC框架的线程池使用进行了梳理之后，提供了丰富的隔离能力：

• 产品：支持不同的产品配置路由到各自单独的集群，例如云音乐、直播等不同的APP路由到各自独立的集群、线程池，从而实现更好的隔离

• 应用、接口、方法：支持各个粒度的隔离

• 区分普通请求、重试请求：例如将重试请求放到单独的线程池中，避免阻塞正常流量

快速失败

针对超时、堆积等场景，在执行业务逻辑前、执行业务逻辑后进行多层超时判断，例如超时配置为100ms，而provider在收到请求时会进行一次计算，若此时耗时已经大于100ms，则直接返回超时异常，而无需调用业务接口，从而有效避免无效请求。同时结合客户端、服务端提供的异步能力，更进一步减少线程资源的使用。

注册中心弱依赖

对于RPC框架来说最核心的依赖便是注册中心，当前云音乐内部使用Zookeeper作为主要的注册中心，而在之前的版本中对于Zookeeper是强依赖，导致Zookeeper一旦抖动或发生网络异常，provider便会大量下线，导致客户端路由不到正确的节点，影响整体的可用性。

从一致性的角度出发，Zookeeper底层基于Zab的类Paxos协议实现，更注重的是CP，即一致性，因此各种大数据、中间件都会利用Zookeeper来进行元数据、配置的管理。而对于注册中心的场景来说，对于一致性的要求并没有那么高，举个例子，服务提供者有一个节点OOM宕机，没有调用下线接口从Zookeeper中摘除，因此客户端会认为该节点没有下线，仍会保留在路由表中，如果仍将流量达到该节点，那么必然会导致请求失败，但RPC框架通常会具备探活能力，此时下游节点OOM宕机，网络链接断开不可用会直接被节点剔除，对可用率没有任何影响。我们发现对于注册中心来说，底层存储大多数时候只需最终一致即可，不需要这么强的一致性。以这个思路出发，我们对RPC框架进行了一系列专项改造：

Zookeeper调优

• 配置、重试策略调优，例如sessionTimeout调整到30s，那么网络抖动只要在30s以内，由于session不会过期，provider也不会触发批量下线，对于服务的可用性几乎没有影响。这个参数需要结合实际的应用场景调整。
• 事件监听优化，区分sessionId，若sessionId未变化，说明session未过期，此时provider不需要重新注册。在服务规模较大时，能够减少大量无用的写入操作。
• 配置化：重试、超时等参数可动态配置，并将连接串统一管理，节点扩容下线业务无需感知

回收站

当服务下线时，将该节点的元数据暂存到缓存中，并支持根据容量、过期时间等策略进行清理。当发生Zookeeper大规模故障时，支持从回收站中将已下线节点重新添加到路由表中。

这里需要注意的是，容器化部署后，节点的ip可能会被其他应用复用、回收站中的节点已经真实下线，因此不能无脑回收，需要对节点进行探活、异常节点检测，从而能够快速将离群节点剔除，最小化对于可用率的影响。

自动化降级

区别于dubbo、Nacos的推空保护，平台支持手动以及自动化的降级，当监控集群检测到Zookeeper服务端异常时，例如无法正常建立链接、写入失败等，则会根据配置自动打开注册中心的回收站机制，从而有效应对注册中心变更(扩容、修改配置)、网络分区等情况。

多注册

在新版本中，我们完善了RPC框架的多注册能力，支持将Nacos作为备，并支持动态调整，例如开关打开后，provider会同时往Zookeeper、Nacos注册，而客户端也支持了多订阅能力，并支持丰富的路由策略，例如优先从Nacos读、若Nacos不存在可用节点，从Zookeeper读取作为兜底。

同时由于平台默认支持了Zookeeper、Nacos的多注册能力，我们在启动时对Zookeeper、Nacos做了强弱依赖的管理，例如当进行Zookeeper扩容、迁移操作时，支持将Zookeeper作为弱依赖，即Zookeeper连接、注册、订阅失败不影响应用启动，框架底层会异步重试，从而更进一步降低RPC对于注册中心的依赖。

故障后

经验库沉淀

区别于业务异常，RPC组件内部的代码相对稳定，不会频繁变动，因此问题的定位、排查通常具备一定的套路。因此通过日常的答疑、故障定位等逐步积累了组件的经验库。例如当发生指定异常时，平台自动根据异常、堆栈等信息匹配到对应的经验库，进一步优化用户看到异常后无法自助处理的问题。

总结

RPC作为一个微服务框架来说，稳定性、性能是最基本的要素，需要我们持续的打磨、治理，同时我们需要思考在当前云原生、降本增效的大背景下，如何能够更好的支撑未来的架构，并给开发者提供更好的使用体验。

最后：

更多岗位，可进入网易招聘官网查看 hr.163.com/