携程的 Dubbo 之路

最新推荐文章于 2021-11-21 22:45:36 发布

阿里巴巴中间件

最新推荐文章于 2021-11-21 22:45:36 发布

阅读量403

点赞数 2

本文链接：https://blog.csdn.net/weixin_39860915/article/details/101488265

版权

本篇文章整理自董艺荃在 Dubbo 社区开发者日上海站的演讲。

缘起

携程当初为什么要引入 Dubbo 呢？实际上从 2013 年底起，携程内主要使用的就是基于 HTTP 协议的 SOA 微服务框架。这个框架是携程内部自行研发的，整体架构在这近6年中没有进行大的重构。受到当初设计的限制，框架本身的扩展性不是很好，使得用户要想自己扩展一些功能就会比较困难。另外，由于 HTTP 协议一个连接同时只能处理一个请求。在高并发的情况下，服务端的连接数和线程池等资源都会比较紧张，影响到请求处理的性能。而 Dubbo 作为一个高性能的 RPC 框架，不仅是一款业界知名的开源产品，它整体优秀的架构设计和数据传输方式也可以解决上面提到的这些问题。正好在 2017 年下半年，阿里宣布重启维护 Dubbo 。基于这些原因，我们团队决定把 Dubbo 引入携程。

Dubbo 落地第一步

要在公司落地 Dubbo 这个新服务框架，第一步就是解决服务治理和监控这两个问题。

服务治理

在服务治理这方面，携程现有的 SOA 框架已经有了一套完整的服务注册中心和服务治理系统。对于服务注册中心，大家比较常用的可能是 Apache Zookeeper 。而我们使用的是参考 Netflix 开源的 Eureka 自行研发的注册中心 Artemis 。Artemis 的架构是一个去中心的对等集群。各个节点的地位相同，没有主从之分。服务实例与集群中的任意一个节点保持长连接，发送注册和心跳信息。收到信息的节点会将这些信息分发给其他节点，确保集群间数据的一致性。客户端也会通过一个长连接来接受注册中心推送的服务实例列表信息。