本文共 1253 字，大约阅读时间需要 4 分钟。
携程引入Dubbo之路：从尝试到落地再到功能升级
作为一名技术专家，我亲眼见证了携程从引入Dubbo到CDubbo定制化发展的整个过程。这篇文章将从缘起到落地再到功能升级，为大家详细解析这一蜕变历程。
一、引入Dubbo的缘起
2013年底，携程内部主要采用基于HTTP协议的SOA微服务框架。这款自家研发的框架在六年间基本没有重构，尽管初有扩展性不足，高并发场景下连接和线程资源紧张。这些问题促使我们寻找更优质的解决方案。
Dubbo作为一个知名的开源RPC框架，以其高性能和优秀架构设计脱颖而出。2017年下半年阿里宣布重启维护，正值我们寻找替代方案之际。经过慎重考虑，携程团队决定将Dubbo引入。
二、Dubbo落地之第一步
在企业级应用落地，服务治理和监控是两大关键环节。
服务治理方面，我们现有SOA框架已具备完整服务注册中心和治理系统。参考Netflix的Eureka开发的Artemis注册中心采用去中心化对等集群机制，服务实例与集群保持长连接，确保数据一致性。客户端通过长连接接收服务实例列表。
服务数据模型直接复用现有SOA框架，Service ID唯一标识每个服务实例。为了与Dubbo兼容，我们在配置中增加serviceId参数，实现服务治理的无缝对接。
服务监控方面，我们采取双层监控策略：统计数据监控和调用链监控。前者以Hessian为序列化工具，汇总调用量、响应时间等数据，后者采用美团开源的CAT平台，记录每个请求的全链路信息。
三、CDubbo功能升级
基于上述基础，我们对CDubbo进行了多维度升级。
传统Callback模式存在唯一实例限制。我们引入Stream功能，允许每个Callback关联唯一的StreamContext。服务端通过匿名类传递请求上下文，解决了Callback场景下的上下文获取问题。
为了兼容携程内部使用的Google Protocol Buffer，我们增加PB序列化支持。扩展序列化器接口，允许用户自定义数据压缩功能，同时确保所有Java数据类型可兼容。
集成Netflix Hystrix进行请求熔断控制，防止雪崩效应。服务端和客户端均配置熔断机制，确保单个服务故障不会影响整体系统。
开发服务测试平台，支持无代码测试请求构造和发送。通过泛化调用和Filter扩展，实现自动化测试和响应数据查看。
五、功能拓展与未来规划
除了上述基础功能，CDubbo还进行了多项扩展：
提供一站式测试解决方案，支持JSON请求构造和自动化测试。扩展泛化调用功能，支持多种序列化格式互转。
开发专用堡垒测试网关，解决生产环境下的服务测试问题。支持Dubbo callback请求转发，确保测试请求准确路由。
未来CDubbo将继续扩展功能，完善服务治理、请求控制等方面。我们也将贡献更多开源成果，为Dubbo社区发展贡献力量。
董艺荃
技术专家 | 携程框架架构研发部转载地址：http://rykyz.baihongyu.com/