hashmap 通过hash函数 链表 +红黑树
框架比较的方面Dubbo+zookeeperSpring Cloud
性能方面 Dubbo是阿里巴巴开源的顶级项目，以前是用于阿里巴巴的分布式服务治理框架,其性能毋庸置疑一定是很强的，它适合一些比较大的公司用的分布式服务治理框架。（注：2017年之前阿里巴巴没有对其进行更新维护，但是2017年Dubbo项目官网宣布重新对其进行更新维护，并且在2018年Dubbo项目正式进入了Apache孵化器） Spring Cloud是最近才兴起的一个分布式服务框架，现在它的社区十分的火爆，代码的更新迭代十分的快；它一般适合于中小型企业，并且性能比Dubbo低一些；
具有的特点 Dubbo有良好的连通性、健壮性、伸缩性、升级性。结合Dubbo可以相对于单体系统提升系统整体的扩展性。
Dubbo提供了多种协议给用户选择， 如dubbo、hessian、rmi 。 并可为每个服务指定不同的传输协议，粒度可以细化到方法， 不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。
Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证Spring Cloud是Java领域最适合做微服务的框架。
相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
Spirng Cloud天然支持Spring Boot，更加便于业务落地。
框架结构
(自身支持的组件)
见下图（spirng cloud对比 Dubbo 图（1））
注：(dubbo本身自带的组件不够支持搭建分布式系统的架构，但是其可以集成第三方的开源项目，从而完善分布式系统的架构。)
方便性 Dubbo使用起来不太方便，由于许多组件其本身不支持，所以我们在搭建架构环境时，需要集成一些其他的开源组件，集成时会遇到种种的困难，并且在以后的项目维护和升级也不方便。
Dubbo服务调用的方式是RPC，服务提供方与调用方接口依赖方式太强：我们需要将调用的抽象接口依赖到消费者项目中才能调用服务，这会导致在以后的开发、测试、版本管理上很麻烦。
SpringCloud自身的组件可以搭建成一个完整的微服务架构，并且搭建起来稍微简单一些；
SpringCloud调用的方式是REST，REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有缺点，很容易导致定义文档与实际实现不一致导致服务集成时的问题。
灵活性 由于dubbo许多组件都是集成的第三方，所以dubbo组件之间的自由度很高，dubbo更加的灵活SpringCloud自身支持了组件，各个组件之间的关联关系已经配置好了，所以它的灵活度不是很好，如果想要用第三方组件代替其中的一个组件的话会有一些困难。
服务注册中心Zookeeper保证C(一致性)P(分区容错性)
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
Eureka保证A(可用性)P(分区容错性)
Eureka各个节点都是平等的，几个节点挂掉不会影响正常工作。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)
代码开发角度Dubbo常与Spring、zookeeper结合，而且实现只是通过xml来配置服务地址、名称、端口，代码的侵入性是很小的，可以说几乎没有代码入侵。Spring Cloud，由于它的实现需要类注解等，所以多少具有一定代码侵入。
spirng cloud对比 Dubbo 图（1）
网友评论