爱奇艺在 Dubbo 生态下的微服务架构实践

爱奇艺在 Dubbo 生态下的微服务架构实践

作者 | 周晓军 爱奇艺中间件团队负责人

导读:本文整理自作者于 2020 年云原生微服务大会上的分享《爱奇艺在 Dubbo 生态下的微服务架构实践》,重点介绍了爱奇艺在 Dubbo、Senti/ : | N Mnel 等开发框架方面的使用经验以及微服务生态体系的建设经验。

阿里巴巴云原生公众号后台回复818即可获取直播回看地址和大会 PPT 合集。

本文将主要围绕以下几个主题展开:

  • Apache DubG T e ! U c % G Rbo 简介及其在爱奇艺的发展历史
  • 爱奇艺内部对 Dubbo SDK 的扩展及围绕 Dubbo 相关的微服务生态建设
  • 后续规划

Apache Dubbo 简介及其在爱奇艺的发展历史

1. Apache Dubbo 简介

AE U H / p I 4pache Dubbo 是一款由阿里开源的高性能 RPC 框架。Dubbo 框架本身除了通信外,还内置了微服务治理的多项功能(如注册r Q 6 j U b g |发现,路由规则等)。

自从 2017 年重启维护以来,Dubbo 社区一直保持了较高的活跃度。从周边生态来看也相对比较完善,比如 Nacos、Sentinel 等开源框架都对@ F ^ v ` e其提供了支持。在语言支持方面,除了 Java 语言之外,Dubbo-go 社区目前也非常活跃,且针对 python,nodejs 等主流开发语言 Dubbo 也有一些开源实现。基于以上这些因素,我们决F / d K u r定引入 DubbW Y ( P J E ^o 框架,用以替换原先自研的 RPC 框架。i = r Z + #

爱奇艺在 Dubbo 生态下的微服务架构实践

爱奇艺是在 2019 年 6 月正式开| f o J { H & A Z始引入 Dubbo 框架的。我们将其与对接公司内部的基础设施做了对接,如注册中心、监控系统等等,? # d G (并在 2019 年 8 月正式发布了U l d v { s T h R第一个内部版本。

这里值得一提的是我们并没有维护自己的 Dubbo 分支,而是利用 Dubbo 强大的扩展机制开发我们的新特性,这样使得我们能够/ o a v p % ;在跟进 Dubbo 社y j j # O ( y d区新版q C * N ` N b / X本方面没有障碍。在这个内部版本发布后,很快就有第一个生产应用在同年 9 月份上线。后续我们在进一步扩展 Dubbo SDK 功能的同时,在周边生态建设方面也做了不少工作,其中就包括在 2020 年 3 月份上线的 Nacos 注册中心等。

2. Apache De r y M 2 ) wubbo 在爱奇艺的发展历F 1 t t %

爱奇艺在 Dubbo 生态下的微服务架构实践

优秀的微服务开发框架e / , ( z 8 8是业务服务化的基A ] S V $石,但是由于微服务应用的复杂性,要帮助业务团队更好地实践微服务架构,还需要一个相对完善的微服务生态体系作为支撑。

微服务生态体系

下图展示了目前爱奇艺内部微服务生态体系的全景。

爱奇艺在 Dubbo 生态下的微服务架构实践

这里面分为几z 1 E q F P . t m个层面:

  • 首先是开发框架层面,Dubbo SDK 集成了注册发现、通信及负载均衡的能力,但是类似熔断及限流功能还是需要采用 Sentinel 等框架来进行支J t ,持;

  • 在基础设施层面,注册中心O s 9 ? H/配置中心均是_ X h M @ G s微服务生态中重要组件;此外为了保证应用的可用性,完整的监控体系也必不可少,如指标监控、日志监控、链路追踪等;

  • 最后,为了方便运维人员管理微服务应用,还需要一套功能完善的管理平台,其中包括了服务管理、配置下发、监控告警及一些对开发人员的支持功能。

可以看到,整个微服务的生态体系还是非常庞大的,限于篇幅,以下的演讲会主要会集中在以下几个方面展开:

  • Dubbo SDK 的扩展
  • 生态体系建设
    • 注册中心的演进
    • 监控体系的建设
    • 熔断限流方面的支持

1. Dubf - * b bo SDK 的扩展

根据爱奇艺内部的实际情况,以及t A e ( c o o _各个业务团队的需求,我们主要对 Dubbo SDK 做了以下几方面的扩展:

爱奇艺在 Dubbo 生态下的微服务架构实践

  • 基础设施的适配:b - Q V N包括注册中心、监控系统、内部的容器平台等等;
  • 可用性增强:包括非健康实例隔离以及区域就近路由的机制;
  • 安全性增强:支持了服务间调用的认证机制;
  • 序列化:增加了对 protobuf+ I ( - : r t # 序列化方式的支持。

1)非健康实例隔离机制

首先介绍非健康实例隔离机制。

D: z = m L 9 & g !ubbo SDK 默认采用随机的负载均衡策略,并通K x m 5过失败重试的策略来保证调用的成功率。通过/ 1 _实践发现,生产环境中有时会出现少数 Provider 节点虽然已经处于不健康的状态(比如磁盘写满等)l F + $ x,但是还是能与注册中心进行正常通信,这样 ConsumeG 3 g 7 n R W Dr 端还是能发现这^ A p g f些实例,导致部分请求还是会被分发过去。这些请求由于实例本身的问题,可能会出现响应时间变慢或者错误率上升,从而引起整个服务质量的下降(响应时间抖动或整体e O @ A b & ( W调用成功率下降)。

爱奇艺在 Dubbo 生态下的微服务架构实践

为了解决这样一个问题,我们的思路是引入客户端健康检查机制,即 Consumer 端会对每个 Provider 实例的请求成功率进行统计,判断其是否健康;对于不健康的 Provider 实例,Consumer 端会对其进行隔离一段时间,后续的请求不再通过负载均衡策略发送到这些实例上。另外 Consumer 端会维护每个 Provider 实例被隔离的次数,如果某个实例被多次隔离,每次隔离的时间也会相应变长。

我们的扩展机制中提供了默认的健康检查策略,包括检查最近一次调用是否出现服务端异常,或者一段时间内是否有大量发出的请求未被返回。用户也可; j ? g : S } ?以通过扩展我们提供的接口来l V K # n | [ , &实现| d Q * X = #自己的检查策略。

为了避免因为网络^ 8 s r v ` h t抖动等造成的意外影响,我们还设计了一套兜底机制。即当N N _ b A Provij = E C $ L hder 实例中不健康的比例超过一定阈值时,Consumer 会忽略实例隔离的策略,避免集~ r J F中的流量将剩余的实例打垮。

2)区域就近路由机制z 5 : L S 9 a -

接下来介绍一下区域f 7 X 9 w c 就近路由机制。

爱奇艺在 Dubbo 生态下的微服务架构实践

爱奇艺在多地都建有机房,为了确保在单个机V E p房出现故障时各业务系统仍能正常工作,核心业务一般会采用两地三中心的架构进行部署。在这种场景下,系统Y o ~ c 5 F z H ~如果产生跨地域的访问请求,由于网络延时的原因势必导致请求延时增大,所以各业务r 1 ^一般都有客户端就近访问服务端实例的需求。

我们通过扩展 Dubbo 的路由机制实现了这样的策略。大致的实现原理是,Provider 和 Consumer 实例V ! q R q X启动时,会先从一个公共的地域服务中获取实例当前所在地域信息(比如可用区等)。Provider 实例在服务注册时会将上述的地域信息作O S [ R $ Q j o为 UE 2 = o c ERL 的一部分注册到注册中心,这样 Consumer 实例就能够在服务发现时Q P V q s获知每个 Provider 实例的地域信息并和自身的地域信息进行比对,优先x L } 7 5 f - D选择临近的实例就近访问。

此外,Consumer 实例也会通过上文中提到的健康检查机制对服务端实例进行检查,如果发现本地域健康的 provider 实例低于设定比例时,则会忽略就c A K C } ` l近路由的策略,改为在所有的 Provider 实例中进行负载均衡,从而实现自+ 9 H T动的 failover 机制。

3)认证机制

部分内部服务有安全认证相关的需求,不希望非授权应用对其进/ ~ h 2行访问。为了解决这个问题,我们开发了一套基于数字签名及 AK^ - l d B n ` P w/SK 的认证体系。

爱奇艺在 Dubbo 生态下的微服务架构实践

其基本原理是:

  • Provider 服务可q v t e以通过配置在某个service上开启鉴权;
  • 需要访问敏感服务的 Consumer 应用,需要在微L : . T服务平台上进行申请,审批后会在这个授7 | + ,权关系上生成一对 AK/SK 并同步至鉴权服务;
  • Provider/Consumer 与鉴权服务进行通信,获取相关的 AK/SK,这个过程使用 HTTPS 进行通信;
  • Consumer 在发起调用时,会对请求参数等生成一个数字签名,连同时间戳、AK 等信息一起发送给 Provider 端;
  • Provider 在收到请求时,会对其数字签名等信息进行核对,确认请求信息的来源及数据的完整性。

以上介绍的是我g g ! t n们针对 Dubbo SDK 的扩展内容,接下来主g N X : X要介绍我@ # j ` E w 7 T们在微服务生态方面的建设。

2. 生态体系建设

注册中心在微服务应用中是最重要的基础设施之一,在 Dubbo SDK 引入之初,为了快速落地,我们使用z * V ? t E P了 ZooKeeper 作为注册中心。当然实际上 ZooKeeper 并不是微服务注册中心的最佳选型,它的主要缺点包括:

  • 无法横向扩展;
  • 作为一个一致性的系统,在网络分区会产生不可用。

1)注册中心演进

在调研了业界的各个方案后,我们选用了 Nacos 作为我们下一代的微服务注册中心。下图右下角5 y C r ? * / U ~是 Nacos 的整体介绍图,选用 Nacos 的主要原因是:

  • 高性能,可以横向扩展;
  • 既适用于传统为服务架构,也能适用* / 0 t C x Z 9于云原生环境,包括支持与 Istio 控制面对接;
  • 提供了 Nacos-Sync 组件,可以用较低的成本进行注册中心的迁移。

爱奇艺在 Dubbo 生态下的微服务架构实践

在部署 Nacos 服务时,我们充分考W ! y y虑了服务部署架构方面的高可用性。目前我们的 Nacos 服务是一个大集群,实例分布在多个不同的可用区中,在每个可用区内部,我们会申请不同的 VIP,最终的, , C h N内网域名是绑定在这些 VIP 上。另外其底层所使用的 MySQL 也采用了多机房部署。这样的架构可以避免单个 Nacos 实例或者单机房故障造成整个 Nacos 服务的不可用。

爱奇艺在 Dubbo 生态下的微服务架构实践

以下是一些可能的故障场景的模拟:

  • 单个 Nacosg ! Q 实例故障:利用 Load BalanceS E ; p [ ! _r 集群提供的健康检查能力自动从 VIP 中摘除;
  • 某个 VIP 集群故障:利用客户端重试机制解决;
  • 单个 AZ 故障:- 5 Y利用客户端重试机制解决;
  • MySQL 集群故障:MySQW c ! 7 W ^ oL 与注册发现过程无关,不受影响;
  • 整个 Nacos 服务故障:客户端兜底机制,如服务实例缓存等。

接下来将简单介绍一下如何使用 Nacos-Sync 进行注册中心的平滑迁移。

爱奇艺在 Dubbo 生态下的微服务架构实践

  • 首先要部署一个 Nacos-Sync 服务,从旧的注册中心向 Nacos 同步数据。Nacos-Sync 支持集群J u - 0 k , ! E化部署,部署多个实例时,其向新注册中心Z ^ 5 e $ o W的写入时幂等的,并且它原生支持 Dubbo 的注册数据格式;

  • 检查数据无误后,首先升级 Consumer 端,改为从 Nacos 注册中心进行发现。这时的服务发现的数据均是由 Nab w @cos-Sync 从旧的注册中心同步过来的;

  • 再升级 Provider 端,改为向 Nacos 进行服务注册3 h ] 9 =

  • 下线 Nacos-Sync 服务及旧的注册中心,整个迁移流程就结束了。

2)监控体系建设

接下来主要介绍我们内部微服务监控体系的建设。完整的微服务监控体系一般由以下 3 个方面组成:

  • 指标监控:包括 QPSd z l h L L * * / 响应延时 / 错误率等黄金指标、业务的自定义指标、JAVA 应用的 JVf a F @M 指标,此外还需要采集和基础环境的相关指标,包括 CPU / 内存利用率等;

  • 日志监控~ M : W V J H .:如错误日志的数量;也可以利用 AI 技术,对日志的模式R O I U l进行统计分析等;

  • 链路监控:由! ^ ;于微服务调用关系的复杂性,调用链追踪也是非常必要的,它可以帮助业务人员更好地分析应用间的依赖关系,并能够监控各个调用关系上的核心指标。

爱奇艺在 Dubbo 生态下的微服务架构实践

指标监控方面,我们内部围绕着 Prometheus 建设了一套较为完整的监控和告警的方案。这里面要解决几个问题:

首先是指标计算的问题,为了降低侵入性,我们在 skywalking agent 的基础上进行了% $ I S f + 3 7 {二次开发,可以自动拦截 Dubbo 的调用,统计其调用次数、处理耗时、是否错误等等。

其次是指标采集的问题,Prometheus 是采用拉模式采集指标的,对于微服务场景一般是利用 Prometheus 的服务发$ 5 } u ^ =现机制。Prometheus 默认集成了 consul、K8s 等服务发现+ + s 7 M C . 5方式,不过并未对 Nacos 注册中心直接提供支持,我们在开源的 Nacos adapter 的基础上进行了改造,使Q / { a S ? b k得 Prometheus 能够从 Nacos 中发现要采集的应用实例信息。

指标查看a i : Q `主要采用了 grafana,我们提供了一套通用化的配置模板,业务也可以根] 1 *据需要自行扩展。

告警方面,我们将告警策略设置在 Promt # Q Z | &etheus 中,具体的告警会由 alerc 8 r h x Pt-manager 通过 adapter 发G D m送给内部的监控告警~ v M n / x平台。

监控 dashboard 查看、R C g C ^ $ t {告警策略设置、订阅的入口统一设置在我们内部的全链路监控平台上,用户可以在该平台上查看进行相应的操作

爱奇艺在 Dubbo 生态下的微服务架构实践

下图展示的是服务监控界面:

爱奇艺在 Dubbo 生态下的微服务架构实践

链路追踪的基本原理也K v k ! ! ,和 google 关于 Dapper 的& _ B F Z { ]论文一致,应用程序通过埋点的 agent 产生调用链数据,通过日志采集或者网络直接上报的方式统一汇总至 kafka,通过我们的实时分析程序进行分析。

分析结果大致可以分为三类:

  • 原始的调用链数据我们会使用 ES+HBase 进行存储;
  • 调用关n b * | 4 9系上的实时监J ? +控数据我们采用时序数据库{ : h g s J C K p druid 进行存储;; 7 / ,
  • 拓扑关系采用图数据存储。

爱奇艺在 Dubbo 生态下的微服务架构实践

3)熔断限流

最后简单介绍一下利用 sentinel 框架进行熔断和限流的相关内容。

爱奇艺在 Dubbo 生态下的微服务架构实践

由于微服务架构的特点,上下游依赖和网络通信都比较多,这些因素都会对应用本身产生一定的风险, ! S % - o o,比如上游系统的突发流量或者热点参数;下游系统服务不可用、延时增大、错误率升高等等。如果缺少对自身系统的保护,有可能产生雪崩的效应。% ~ ? A r为了应对这些场景,我们主要引入了 Sentinel 框架进行解决。

Sentinel 的核^ ! u z e A B心原理是用户可以定义各类资源(资e ( I $ q 1 9 # o源可以是本地的一个接口,或者远程的某$ R v个依赖),并在资源上设置各种规则(比如限流规则),在访问某个资源时,Sentinel 组件会检查这些规则k / T是否满足,在不满足的情况下会抛出特定的异常。用户可以通过捕捉这些异常实现快速失败或者降级等业务逻辑。SentinR z 5 Rel 还提供了一个控制台,可以用来管理规则的参数设置以及查看实时监控等。

爱奇艺在 Dubbo 生态下的微服务架构实践

为了适应内部业务团队的需求,我们对 sentinel 框架也做了一些扩展,下面的例子即是我们实现的复杂参数限流功能。Sentinel 框架本身就自带热点参数限流的功能,不过仅支持一些简单类型的参数(如 SQ _ 2tring、inZ @ @ L ? K - N ~t 等)。在有些情况下,限流的场景可能比较复杂,比如下图中,可能要根据第一个参数的 id 属性进行限流,这种场景原生的 sentinel 并未提供支持。针对这种情况,我们: _ x c提供了一个抽象K C w Q + J C +的接口,允许用户通过自己的实现* 5 p p z +从参数中提y 3 u ;取出需要限流的资源。

爱奇艺在 Dubbo 生态下的微服务架构实践

为了实现规则参数的动态下发,- 7 S v $ Z ]我们将 sentinelD 8 : = + W g 与内部的配置中心进行了适配。在 sentinel dau ? mshboard 上进行的参数改动,最后都会保存至配置中心,业务系统通过引入配置中心的 SDK,即可实现在不重启应用的前提下进行参数的动态调整。

爱奇艺在 Dubbo 生态下的微服务架构实践

在我们的微服务管理平台上,还提供了 sentinel dashboard 的托管I S 0 V - e l 2能。

爱奇艺在 Dubbo 生态下的微服务架构实践

发展现状及开源贡献

爱奇艺引入 Dubbo 的时间并不长,但是由于其较为稳定的线上表现使得的各个业务团队的整体接受度较高,上线的规模也在快速增长。短p K T ) = b V L n短一年内累计已上线了一百多个线上服务,实例数也已经超过五千个。

此外,我们也在使用过程中积极回馈社区,截止目前共提交了三十个左右的补丁,上文中提到的认证机制也已贡献给社区,成为 Dubbo 2.7.6 版本的新特性之一。在这个过程中,团5 f ~ n 2 r #队中也诞生了一位社区的 committer。

爱奇艺在 Dubbo 生态下的微服务架构实践

未来规划

对于未来的规划,大概有以] & n q l ]下几方面的工作:

爱奇艺在 Dubbo 生态下的微服务架构实践

  • 云原生与 service mesh 已经是微服务技术演进的一个趋势了,且在一些公司已经有了比较大规模的实践。如何将 dubbo 与 service mesh 结合,如何提供平滑过渡的解决方案,将y % ~ H Z M会是我们今后工作的一个f 5 V ^ 3 6 !重点;

  • 在服务治理r ! D方面,后续我们希望能够建立一个对 service mesh 和传统微服务都适用的控制面;

  • 在开发者支持方w A N [ V I N # G面,我们计划推出项目脚手架以及在线调试等服务,使得开发人员能更方便地进行项目开发,以及线上问题的排查等。

阿里巴巴云原生公众号后台回复818即可获取直播回看地址和大会 PPT 合集。

“阿里巴巴云原生关注微服务、a J =ServerlessW / m y &、容+ . g 3器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的6 P H f落地实践,做最懂云原生开发者的公众号。”