Apache Dubbo 简介及其在爱奇艺的发展历史
1. Apache Dubbo 简介
Apache Dubbo 是一款由阿里开源的高性能 RPC 框架。Dubbo 框架本身除了通信外，还内置了微服务治理的多项功能（如注册发现，路由规则等）。
自从 2017 年重启维护以来，Dubbo 社区一直保持了较高的活跃度。从周边生态来看也相对比较完善，比如 Nacos、Sentinel 等开源框架都对其提供了支持。在语言支持方面，除了 Java 语言之外，Dubbo-go 社区目前也非常活跃，且针对 python，nodejs 等主流开发语言 Dubbo 也有一些开源实现。基于以上这些因素，我们决定引入 Dubbo 框架，用以替换原先自研的 RPC 框架。
爱奇艺是在 2019 年 6 月正式开始引入 Dubbo 框架的。我们将其与对接公司内部的基础设施做了对接，如注册中心、监控系统等等，并在 2019 年 8 月正式发布了第一个内部版本。
这里值得一提的是我们并没有维护自己的 Dubbo 分支，而是利用 Dubbo 强大的扩展机制开发我们的新特性，这样使得我们能够在跟进 Dubbo 社区新版本方面没有障碍。在这个内部版本发布后，很快就有第一个生产应用在同年 9 月份上线。后续我们在进一步扩展 Dubbo SDK 功能的同时，在周边生态建设方面也做了不少工作，其中就包括在 2020 年 3 月份上线的 Nacos 注册中心等。
2. Apache Dubbo 在爱奇艺的发展历史
优秀的微服务开发框架是业务服务化的基石，但是由于微服务应用的复杂性，要帮助业务团队更好地实践微服务架构，还需要一个相对完善的微服务生态体系作为支撑。
微服务生态体系
下图展示了目前爱奇艺内部微服务生态体系的全景。
这里面分为几个层面：
首先是开发框架层面，Dubbo SDK 集成了注册发现、通信及负载均衡的能力，但是类似熔断及限流功能还是需要采用 Sentinel 等框架来进行支持；
在基础设施层面，注册中心/配置中心均是微服务生态中重要组件；此外为了保证应用的可用性，完整的监控体系也必不可少，如指标监控、日志监控、链路追踪等；
最后，为了方便运维人员管理微服务应用，还需要一套功能完善的管理平台，其中包括了服务管理、配置下发、监控告警及一些对开发人员的支持功能。
可以看到，整个微服务的生态体系还是非常庞大的，限于篇幅，以下的演讲会主要会集中在以下几个方面展开：
Dubbo SDK 的扩展
生态体系建设
注册中心的演进
监控体系的建设
熔断限流方面的支持
1. Dubbo SDK 的扩展
根据爱奇艺内部的实际情况，以及各个业务团队的需求，我们主要对 Dubbo SDK 做了以下几方面的扩展：
基础设施的适配：包括注册中心、监控系统、内部的容器平台等等；
可用性增强：包括非健康实例隔离以及区域就近路由的机制；
安全性增强：支持了服务间调用的认证机制；
序列化：增加了对 protobuf 序列化方式的支持。
1）非健康实例隔离机制
首先介绍非健康实例隔离机制。
Dubbo SDK 默认采用随机的负载均衡策略，并通过失败重试的策略来保证调用的成功率。通过实践发现，生产环境中有时会出现少数 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 在收到请求时，会对其数字签名等信息进行核对，确认请求信息的来源及数据的完整性。
以上介绍的是我们针对 Dubbo SDK 的扩展内容，接下来主要介绍我们在微服务生态方面的建设。
2. 生态体系建设
注册中心在微服务应用中是最重要的基础设施之一，在 Dubbo SDK 引入之初，为了快速落地，我们使用了 ZooKeeper 作为注册中心。当然实际上 ZooKeeper 并不是微服务注册中心的最佳选型，它的主要缺点包括：
无法横向扩展；
作为一个一致性的系统，在网络分区会产生不可用。
1）注册中心演进
在调研了业界的各个方案后，我们选用了 Nacos 作为我们下一代的微服务注册中心。下图右下角是 Nacos 的整体介绍图，选用 Nacos 的主要原因是：
高性能，可以横向扩展；
既适用于传统为服务架构，也能适用于云原生环境，包括支持与 Istio 控制面对接；
提供了 Nacos-Sync 组件，可以用较低的成本进行注册中心的迁移。
在部署 Nacos 服务时，我们充分考虑了服务部署架构方面的高可用性。目前我们的 Nacos 服务是一个大集群，实例分布在多个不同的可用区中，在每个可用区内部，我们会申请不同的 VIP，最终的内网域名是绑定在这些 VIP 上。另外其底层所使用的 MySQL 也采用了多机房部署。这样的架构可以避免单个 Nacos 实例或者单机房故障造成整个 Nacos 服务的不可用。
