携程技术转型：从HTTP到Dubbo的演进之路

"这篇文章讲述了携程从使用自研的基于HTTP协议的SOA微服务框架转向引入Dubbo作为高性能RPC框架的过程。携程面临的主要问题是自研框架的扩展性不足以及HTTP协议在高并发下的性能瓶颈。Dubbo因其优秀的架构设计、高性能和社区支持成为了解决这些问题的理想选择。文章还详细介绍了在携程落地Dubbo时，如何处理服务治理和监控的挑战，包括使用自研的去中心化注册中心Artemis，以及如何将Dubbo与现有的服务数据模型集成。" 在携程的技术演进过程中，引入Dubbo的主要动机是解决由自研SOA框架带来的局限性。该框架由于设计之初的限制，导致扩展性较差，不便于用户添加自定义功能。此外，基于HTTP协议的服务在处理高并发请求时，由于其单连接单请求的特性，使得服务端资源（如连接数和线程池）面临压力，影响了性能。而Dubbo作为一种高性能的RPC框架，因其优秀的架构设计，能够提供更好的扩展性和更高效的数据传输方式，从而有效解决这些问题。 在实际落地Dubbo的过程中，携程首要解决的是服务治理和监控。服务治理方面，携程拥有自己的服务注册中心Artemis，它是基于Netflix Eureka的自研实现，采用去中心化的对等集群架构。服务实例与任意节点保持长连接，通过节点间的同步保证数据一致性。服务数据模型与Dubbo接口相对应，每个服务实例都有唯一标识ServiceID，用于服务注册和客户端查找服务实例。 服务注册时，由于Dubbo自身没有ServiceID的概念，携程采取的策略是在Service和Reference配置中添加额外信息，将接口映射到ServiceID，实现了Dubbo与注册中心的无缝对接。这样一来，即使使用新的框架，也能充分利用现有的服务治理系统。 监控方面，文章虽然没有详细展开，但可以推测携程会构建一套与Dubbo兼容的监控体系，可能包括服务调用的性能指标、健康检查和故障排查等功能，以确保服务质量和稳定性。 携程引入Dubbo是为了提升服务性能、改善扩展性，并利用Dubbo的成熟服务治理能力，同时通过自研组件的适配，确保了技术栈的平滑过渡和现有系统的兼容性。这一过程展示了携程在技术选型和系统演进中的谨慎和创新，也体现了对开源技术的接纳和支持。