简介：本文整理自作者于年云原生微服务大会上的分享《爱奇艺在Dubbo生态下的微服务架构实践》，重点介绍了爱奇艺在Dubbo、Sentinel等开发框架方面的使用经验以及微服务生态体系的建设经验。
作者
周晓军爱奇艺中间件团队负责人
导读：本文整理自作者于年云原生微服务大会上的分享《爱奇艺在Dubbo生态下的微服务架构实践》，重点介绍了爱奇艺在Dubbo、Sentinel等开发框架方面的使用经验以及微服务生态体系的建设经验。
本文将主要围绕以下几个主题展开：
ApacheDubbo简介及其在爱奇艺的发展历史爱奇艺内部对DubboSDK的扩展及围绕Dubbo相关的微服务生态建设后续规划1.ApacheDubbo简介
ApacheDubbo是一款由阿里开源的高性能RPC框架。Dubbo框架本身除了通信外，还内置了微服务治理的多项功能（如注册发现，路由规则等）。
自从年重启维护以来，Dubbo社区一直保持了较高的活跃度。从周边生态来看也相对比较完善，比如Nacos、Sentinel等开源框架都对其提供了支持。在语言支持方面，除了Java语言之外，Dubbo-go社区目前也非常活跃，且针对python，nodejs等主流开发语言Dubbo也有一些开源实现。基于以上这些因素，我们决定引入Dubbo框架，用以替换原先自研的RPC框架。
爱奇艺是在年6月正式开始引入Dubbo框架的。我们将其与对接公司内部的基础设施做了对接，如注册中心、监控系统等等，并在年8月正式发布了第一个内部版本。
这里值得一提的是我们并没有维护自己的Dubbo分支，而是利用Dubbo强大的扩展机制开发我们的新特性，这样使得我们能够在跟进Dubbo社区新版本方面没有障碍。在这个内部版本发布后，很快就有第一个生产应用在同年9月份上线。后续我们在进一步扩展DubboSDK功能的同时，在周边生态建设方面也做了不少工作，其中就包括在年3月份上线的Nacos注册中心等。
2.ApacheDubbo在爱奇艺的发展历史
优秀的微服务开发框架是业务服务化的基石，但是由于微服务应用的复杂性，要帮助业务团队更好地实践微服务架构，还需要一个相对完善的微服务生态体系作为支撑。
微服务生态体系
下图展示了目前爱奇艺内部微服务生态体系的全景。
这里面分为几个层面：
首先是开发框架层面，DubboSDK集成了注册发现、通信及负载均衡的能力，但是类似熔断及限流功能还是需要采用Sentinel等框架来进行支持；在基础设施层面，注册中心/配置中心均是微服务生态中重要组件；此外为了保证应用的可用性，完整的监控体系也必不可少，如指标监控、日志监控、链路追踪等；最后，为了方便运维人员管理微服务应用，还需要一套功能完善的管理平台，其中包括了服务管理、配置下发、监控告警及一些对开发人员的支持功能。可以看到，整个微服务的生态体系还是非常庞大的，限于篇幅，以下的演讲会主要会集中在以下几个方面展开：
DubboSDK的扩展生态体系建设注册中心的演进监控体系的建设熔断限流方面的支持1.DubboSDK的扩展
根据爱奇艺内部的实际情况，以及各个业务团队的需求，我们主要对DubboSDK做了以下几方面的扩展：
基础设施的适配：包括注册中心、监控系统、内部的容器平台等等；可用性增强：包括非健康实例隔离以及区域就近路由的机制；安全性增强：支持了服务间调用的认证机制；序列化：增加了对protobuf序列化方式的支持。1）非健康实例隔离机制
首先介绍非健康实例隔离机制。
DubboSDK默认采用随机的负载均衡策略，并通过失败重试的策略来保证调用的成功率。通过实践发现，生产环境中有时会出现少数Provider节点虽然已经处于不健康的状态（比如磁盘写满等），但是还是能与注册中心进行正常通信，这样Consumer端还是能发现这些实例，导致部分请求还是会被分发过去。这些请求由于实例本身的问题，可能会出现响应时间变慢或者错误率上升，从而引起整个服务质量的下降（响应时间抖动或整体调用成功率下降）。
为了解决这样一个问题，我们的思路是引入客户端健康检查机制，即Consumer端会对每个Provider实例的请求成功率进行统计，判断其是否健康；对于不健康的Provider实例，Consumer端会对其进行隔离一段时间，后续的请求不再通过负载均衡策略发送到这些实例上。另外Consumer端会维护每个Provider实例被隔离的次数，如果某个实例被多次隔离，每次隔离的时间也会相应变长。
我们的扩展机制中提供了默认的健康检查策略，包括检查最近一次调用是否出现服务端异常，或者一段时间内是否有大量发出的请求未被返回。用户也可以通过扩展我们提供的接口来实现自己的检查策略。
为了避免因为网络抖动等造成的意外影响，我们还设计了一套兜底机制。即当Provider实例中不健康的比例超过一定阈值时，Consumer会忽略实例隔离的策略，避免集中的流量将剩余的实例打垮。
2）区域就近路由机制
接下来介绍一下区域就近路由机制。
爱奇艺在多地都建有机房，为了确保在单个机房出现故障时各业务系统仍能正常工作，核心业务一般会采用两地三中心的架构进行部署。在这种场景下，系统如果产生跨地域的访问请求，由于网络延时的原因势必导致请求延时增大，所以各业务一般都有客户端就近访问服务端实例的需求。
我们通过扩展Dubbo的路由机制实现了这样的策略。大致的实现原理是，Provider和Consumer实例在启动时，会先从一个公共的地域服务中获取实例当前所在地域信息（比如可用区等）。Provider实例在服务注册时会将上述的地域信息作为URL的一部分注册到注册中心，这样Consumer实例就能够在服务发现时获知每个Provider实例的地域信息并和自身的地域信息进行比对，优先选择临近的实例就近访问。
此外，Consumer实例也会通过上文中提到的健康检查机制对服务端实例进行检查，如果发现本地域健康的provider实例低于设定比例时，则会忽略就近路由的策略，改为在所有的Provider实例中进行负载均衡，从而实现自动的failover机制。
3）认证机制
部分内部服务有安全认证相关的需求，不希望非授权应用对其进行访问。为了解决这个问题，我们开发了一套基于数字签名及AK/SK的认证体系。
其基本原理是：
Provider服务可以通过配置在某个service上开启鉴权；需要访问敏感服务的Consumer应用，需要在微服务平台上进行申请，审批后会在这个授权关系上生成一对AK/SK并同步至鉴权服务；Provider/Consumer与鉴权服务进行通信，获取相关的AK/SK，这个过程使用HTTPS进行通信；Consumer在发起调用时，会对请求参数等生成一个数字签名，连同时间戳、AK等信息一起发送给Provider端；Provider在收到请求时，会对其数字签名等信息进行核对，确认请求信息的来源及数据的完整性。以上介绍的是我们针对DubboSDK的扩展内容，接下来主要介绍我们在微服务生态方面的建设。
2.生态体系建设
注册中心在微服务应用中是最重要的基础设施之一，在DubboSDK引入之初，为了快速落地，我们使用了ZooKeeper作为注册中心。当然实际上ZooKeeper并不是微服务注册中心的最佳选型，它的主要缺点包括：
无法横向扩展；作为一个一致性的系统，在网络分区会产生不可用。1）注册中心演进
在调研了业界的各个方案后，我们选用了Nacos作为我们下一代的微服务注册中心。下图右下角是Nacos的整体介绍图，选用Nacos的主要原因是：
高性能，可以横向扩展；既适用于传统为服务架构，也能适用于云原生环境，包括支持与Istio控制面对接；提供了Nacos-Sync组件，可以用较低的成本进行注册中心的迁移。
在部署Nacos服务时，我们充分考虑了服务部署架构方面的高可用性。目前我们的Nacos服务是一个大集群，实例分布在多个不同的可用区中，在每个可用区内部，我们会申请不同的VIP，最终的内网域名是绑定在这些VIP上。另外其底层所使用的MySQL也采用了多机房部署。这样的架构可以避免单个Nacos实例或者单机房故障造成整个Nacos服务的不可用。
以下是一些可能的故障场景的模拟：
单个Nacos实例故障：利用LoadBalancer集群提供的健康检查能力自动从VIP中摘除；某个VIP集群故障：利用客户端重试机制解决；单个AZ故障：利用客户端重试机制解决；MySQL集群故障：MySQL与注册发现过程无关，不受影响；整个Nacos服务故障：客户端兜底机制，如服务实例缓存等。接下来将简单介绍一下如何使用Nacos-Sync进行注册中心的平滑迁移。
首先要部署一个Nacos-Sync服务，从旧的注册中心向Nacos同步数据。Nacos-Sync支持集群化部署，部署多个实例时，其向新注册中心的写入时幂等的，并且它原生支持Dubbo的注册数据格式；检查数据无误后，首先升级Consumer端，改为从Nacos注册中心进行发现。这时的服务发现的数据均是由Nacos-Sync从旧的注册中心同步过来的；再升级Provider端，改为向Nacos进行服务注册；下线Nacos-Sync服务及旧的注册中心，整个迁移流程就结束了。2）监控体系建设
接下来主要介绍我们内部微服务监控体系的建设。完整的微服务监控体系一般由以下3个方面组成：
指标监控：包括QPS/响应延时/错误率等黄金指标、业务的自定义指标、JAVA应用的JVM指标，此外还需要采集和基础环境的相关指标，包括CPU/内存利用率等；日志监控：如错误日志的数量；也可以利用AI技术，对日志的模式进行统计分析等；链路监控：由于微服务调用关系的复杂性，调用链追踪也是非常必要的，它可以帮助业务人员更好地分析应用间的依赖关系，并能够监控各个调用关系上的核心指标。
指标监控方面，我们内部围绕着Prometheus建设了一套较为完整的监控和告警的方案。这里面要解决几个问题：
首先是指标计算的问题，为了降低侵入性，我们在skywalkingagent的基础上进行了二次开发，可以自动拦截Dubbo的调用，统计其调用次数、处理耗时、是否错误等等。
其次是指标采集的问题，Prometheus是采用拉模式采集指标的，对于微服务场景一般是利用Prometheus的服务发现机制。Prometheus默认集成了consul、K8s等服务发现方式，不过并未对Nacos注册中心直接提供支持，我们在开源的Nacosadapter的基础上进行了改造，使得Prometheus能够从Nacos中发现要采集的应用实例信息。
指标查看主要采用了grafana，我们提供了一套通用化的配置模板，业务也可以根据需要自行扩展。
告警方面，我们将告警策略设置在Prometheus中，具体的告警会由alert-manager通过adapter发送给内部的监控告警平台。
监控dashboard查看、告警策略设置、订阅的入口统一设置在我们内部的全链路监控平台上，用户可以在该平台上查看进行相应的操作。
下图展示的是服务监控界面：
链路追踪的基本原理也和google关于Dapper的论文一致，应用程序通过埋点的agent产生调用链数据，通过日志采集或者网络直接上报的方式统一汇总至kafka，通过我们的实时分析程序进行分析。
分析结果大致可以分为三类：
原始的调用链数据我们会使用ES+HBase进行存储；调用关系上的实时监控数据我们采用时序数据库druid进行存储；拓扑关系采用图数据存储。
3）熔断限流
最后简单介绍一下利用sentinel框架进行熔断和限流的相关内容。
由于微服务架构的特点，上下游依赖和网络通信都比较多，这些因素都会对应用本身产生一定的风险，比如上游系统的突发流量或者热点参数；下游系统服务不可用、延时增大、错误率升高等等。如果缺少对自身系统的保护，有可能产生雪崩的效应。为了应对这些场景，我们主要引入了Sentinel框架进行解决。
Sentinel的核心原理是用户可以定义各类资源（资源可以是本地的一个接口，或者远程的某个依赖），并在资源上设置各种规则（比如限流规则），在访问某个资源时，Sentinel组件会检查这些规则是否满足，在不满足的情况下会抛出特定的异常。用户可以通过捕捉这些异常实现快速失败或者降级等业务逻辑。Sentinel还提供了一个控制台，可以用来管理规则的参数设置以及查看实时监控等。
为了适应内部业务团队的需求，我们对sentinel框架也做了一些扩展，下面的例子即是我们实现的复杂参数限流功能。Sentinel框架本身就自带热点参数限流的功能，不过仅支持一些简单类型的参数（如String、int等）。在有些情况下，限流的场景可能比较复杂，比如下图中，可能要根据第一个参数的id属性进行限流，这种场景原生的sentinel并未提供支持。针对这种情况，我们提供了一个抽象的接口，允许用户通过自己的实现从参数中提取出需要限流的资源。
为了实现规则参数的动态下发，我们将sentinel与内部的配置中心进行了适配。在sentineldashboard上进行的参数改动，最后都会保存至配置中心，业务系统通过引入配置中心的SDK，即可实现在不重启应用的前提下进行参数的动态调整。
在我们的微服务管理平台上，还提供了sentineldashboard的托管功能。
发展现状及开源贡献
爱奇艺引入Dubbo的时间并不长，但是由于其较为稳定的线上表现使得的各个业务团队的整体接受度较高，上线的规模也在快速增长。短短一年内累计已上线了一百多个线上服务，实例数也已经超过五千个。
此外，我们也在使用过程中积极回馈社区，截止目前共提交了三十个左右的补丁，上文中提到的认证机制也已贡献给社区，成为Dubbo2.7.6版本的新特性之一。在这个过程中，团队中也诞生了一位社区的