Apache Dubbo 简单介绍
Apache Dubbo是一款开源的RPC（Remote Procedure Call，远程过程调用）框架，其提供了简单易用、高性能的RPC能力、灵活可控的扩展、强大的服务治理、完善的开源生态支持，目前已有Java、Go、JS、Python等多个语言支持。
Apache Dubbo更是一款服务治理框架，其在服务治理层面提供了多种静态以及动态路由配置、集群容错、可视化运维、监控、流量调度等功能。如下图所示：
Dubbo基本架构
更详尽的信息可以参考Dubbo官方网站：
http://dubbo.apache.org/zh-cn/docs/user/quick-start.html
爱奇艺在Dubbo上的实践
爱奇艺从2019年开始正式引入Dubbo，从引入之初，我们即确定了基于Dubbo强大的SPI（Service Provider Interface，服务发现机制）机制定制公司内部插件的技术路线，目前来看，这套机制可以满足我们对Dubbo的定制化需求。
第一个版本主要提供了对公司基础设施的适配和兼容和容器运行环境的适配、以及配合爱奇艺的监控系统进行一些基础的埋点。这样对后续各个业务团队能够更高效地使用Dubbo框架开发业务应用。该版本发布后我们收集到了业务方的很多积极反馈和需求，这也坚定了我们想要去做好Dubbo和推广Dubbo的决心。
以下是针对爱奇艺注册中心、配置中心及元数据中心的适配：
1.注册中心方面，考虑到历史原因和维护成本，我们初期依旧选择了之前内部广泛使用的Zookeeper作为注册中心，并通过集群名称的方式让用户进行访问（类似iqiyi-zk://idc1-cluster），其目的主要是简化用户配置，并方便之后对Zookeeper集群进行透明运维。
2.配置中心方面 2.7.x版本中很大的改进就是对于配置中心功能的加强，配置中心不再只是提供全局Dubbo启动配置的一个数据库，而是真正地利用了配置中心的推送能力进行，包括服务治理、运行时动态配置。
3. 元数据中心也是2.7.x版本中引进的新特性，其主要目的是将一些与调用无关的数据，例如元数据、方法信息等与注册中心的URL分开存储，有效精简URL，减轻注册中心推送和存储的负担。我们选择了官方推荐的Redis作为存储中心。
不久后，我们发布了第二个版本，主要是对站点管理平台的一些改造(下图部分敏感信息打码)。
我们尝试新版本的Dubbo Admin站点的一些功能集成到了内部管理平台上，并且与之前的站点进行了整合，目前主要功能包括实例新消息可视化、监控展示、基础报警订阅、服务接口查看、服务在线测试和治理配置下发。
第三个版本着重对Dubbo的可用性、RPC调用的效率以及安全性方面进行了加强。
我们在Dubbo上做的工作总结如下表：
1 基础设施维护
内部Dubbo扩展：使用别名方式进行连接，方便运维管理
开源Dubbo版本：需自行申请维护，不便于运维
2 部署环境
内部Dubbo扩展：任意环境部署，无需额外配置
开源Dubbo版本：容器暴露的是虚拟ip和端口，需要自行改造注册发现、或者配置ip信息
3 服务治理和监控
内部Dubbo扩展：
1）集成微服务平台
2）重要指标采集，对接内部监控平台，可视化查询，自定义指标查询，重要指标报警订阅
3）服务治理规则、服务压测、服务在线测试
4 可用性加强
内部Dubbo扩展：
1）不健康实例剔除
2）服务级别熔断、降级、限流
开源Dubbo版本： 需自行开发
5 多地部署
内部Dubbo扩展：同区域优先路由，无需关心部署环境
开源Dubbo版本： 需自行开发
6 安全性
内部Dubbo扩展：提供AK/SK鉴权认证
开源Dubbo版本： 自有鉴权机制，安全性低
Apache Dubbo 的优化
以下主要在可用性、多地部署调用优化以及安全性几个方面的加强进行详细地介绍。
▌提升可用性
可用性方面我们通过如下两个维度加强：
· 实例级别可用性
· 服务级别的可用性
实例级别可用性
在生产实践中发现，如果仅仅依赖注册中心进行健康检查可能无法剔除所有的非健康实例。例如，在一个具体的场景中，某业务团队线上频繁出现超时，最终排查发现这是因为部署的某个容器磁盘写满，导致该实例处理请求时一直阻塞在写日志刷盘的过程，以至于客户端请求超时。对于这种情况，需要在框架中提供一种策略，使得我们能够发现这些非健康实例，即在对某个实例的请求频繁出错或者超时的情况下，临时屏蔽掉该实例，优先调用其他健康的实例，并定期探测，以便于在该实例恢复到健康状态之后，能及时把该实例加入到负载均衡的列表中。
因为Dubbo是典型的富客户端模型，即负载均衡、路由等功能都是在客户端SDK中集成，客户端无法直接获取到服务端的整体监控指标，如QPS/响应延时/错误率等。所以，我们用了客户端几个最基本的并且能方便采集的指标作为判断的依据，例如请求错误比例、请求超时比例、请求未返回比例。考虑到扩展性，我们也提供了SPI机制，方便业务自己去决定怎样的实例是健康的。SPI接口如下：
具体使用方式是通过parameters开启该功能并且指定健康监测策略，以注解方式举例:
服务级别可用性
要保障微服务应用稳定性运行，熔断和限流也是必要的保护机制。在某个客户端过多地占用服务端资源，我们需要通过动态配置方法限制其调用数；在依赖的第三方服务发生故障时，为了不级联影响到其他核心功能的正常使用，对这类服务进行快速失败或者是触发降级功能。
在进行大量调研之后，我们最终选择开源Sentinel，并在其之上进行熔断降级、限流等功能的开发，并且加强了Sentinel Apache Dubbo Adapter插件的功能，增加了对Dubbo异步的支持、支持基于group/version等服务端属性进行细粒度控制等。这部分代码已经贡献至Sentinel社区（已合并），欢迎大家使用。
插件地址：
https://github.com/alibaba/Sentinel/tree/master/sentinel-adapter/sentinel-apache-dubbo-adapter
▌提升RPC效率
为了避免机房级别故障，会将服务的实例冗余并分散部署在不同的机房甚至地区。但在一般情况下，跨地区的访问延时很高，如从北京到上海的请求，仅网络延时就将近30ms。在这样的背景下，如果不考虑服务端和客户端所处的地域，仅仅简单地进行负载均衡会对服务性能造成比较大的影响。
为了提升在多地部署的情况下RPC请求的效率，我们设计了基于地域感知的就近路由功能，尽可能地将请求限制在同地区甚至是同可用区中。我们在SDK层面集成了接入了公司内部的CMDB，在应用启动时，SDK会自动从CMDB获取本实例的运行信息，包括可用区、地区等，并将这些进行作为注册信息的一部分注册至注册中心，从而无需用户关心应用部署的环境。
由于服务端和客户端可能分属于不同业务团队，区域部署信息不对等的情况可能带来流量负载不均、单区域热点的问题。设想如下图所示的场景，上下游系统地区部署不均匀，导致右边地区的下游系统处理能力过剩，左边则趋于饱和。
当这种不均匀的情况更加严重时，时刻遵循区域亲和性的调用原则会导致同区域的下游实例的处理水平无法匹配到上游的请求流量时，从而打垮下游服务，并且级联影响到整个系统，此时的同区域路由效果甚至比跨区域的效果还要差，所以这就需要同区域路由有兼备服务端当前处理状态的能力，做到适时的流量转移。
为了避免这种情况的发生，我们额外引入了地区可用的策略。该策略也依托于上文提到的健康实例检查策略，根据实例“健康”数是否达标来判断该地区是否可用，如果某就近区域的健康实例数不足，负载均衡的范围就将自动扩展至其他地域的实例。特别需要的指出的是，这里对于健康的定义不只是实例宕机和不可达，也可以由用户自行扩展，例如积压请求数太多、处理速度过慢都可以认为其是不健康的。
▌加强服务安全
对安全性敏感的业务可能会有限制匿名调用的需求，如支付等。在加固安全性方面，我们引入了基于AK/SK机制的认证鉴权机制，主要架构如下图所示：
服务认证鉴权主要是为了解决两个问题：消费端如何申明自己的身份以及服务端如何鉴别该身份是否有效。
Access Key Id /Secret Access Key的功能就是标识消费者的身份，并在调用时生成请求签名以及由服务提供者对该签名正确性验证来识别某个请求来源的消费者身份是否有效，其间一切过程都对上层用户透明。
并且，为了免去用户在代码中明码配置敏感信息的操作以及为应用提供诸如AK/SK动态吊销、更新的能力，我们引入了鉴权服务中心，其相当于一个身份和权限的注册分发系统，使用鉴权服务的应用和鉴权服务中心的交互需通过HTTPS的双向认证，并在TLS信道上进行数据交互，保证AK/SK信息传输的安全性。
具体的接入方式也并不复杂，以申请消费某敏感服务举例：
1. 使用者需要在微服务站点上填写自己的应用信息，并为该应用生成唯一的证书凭证。
2. 之后在管理站点上提交工单，申请某个敏感业务服务的使用权限，并由对应业务管理者进行审批，审批通过之后，会生成对应的AK/SK到鉴权服务中心。
3. 导入该证书到对应的应用下，并且配置好证书的文件名等信息即可，代码不需要做任何改动。
敏感服务自身在发布的时候，只需要导入本应用证书到classpath下，并在具体Service上配置好鉴权相关的参数即可，如下所示：
该方案目前已经提交给Dubbo开源社区，并且完成了基本框架的合并。除了AK/SK的鉴权方式之外，通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。
后续展望
1. Zookeeper服务受限于其CP模型和水平扩展性方面的缺陷，因此它可能并不是作为微服务注册中心的最佳选择，我们目前也在调研新的注册中心服务，并计划适时引入并提供平滑迁移的方案。另外我们也计划依托于注册中心的多地部署能力及SDK中的就近路由策略，形成系统性的多地部署高可用方案。
2. 进一步加强管理平台的功能，完善服务治理的各项能力（如限流策略下发、压测、远程调试等等），配合内部微服务框架，打造集服务发布、测试、监控、调试的一站式服务治理平台。
3. 探索Dubbo框架在云原生环境及Service Mesh场景下的使用方式及相关过渡方案。
总结
短短6个月时间，爱奇艺已经上线几千个Dubbo实例，并为Dubbo相关开源生态，包括Dubbo、Sentinel累计提交18个PR（其中已合并15个），并孵化一位DubboCommitter。得益于Dubbo在国内广泛的应用和开源社区的积累，目前公司内部所有Dubbo应用平稳运行，没有业务反馈过任何重大故障。在这之后会继续完善Dubbo的服务治理功能和加强Dubbo的推广，并紧跟Dubbo开源社区的脚步，将爱奇艺在Dubbo上积累的实践经验反哺给开源社区，共建Dubbo开源。
也许你还想看
爱奇艺RND框架之JS Framework解析
爱奇艺RND框架技术探索——架构与实现
扫一扫下方二维码，更多精彩内容陪伴你！
本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
