微服务分布式框架Dubbo和Spring Cloud

1.前言

选择阿里系还是Spring全家桶?

谈到微服务技术的选择,面临的第一个问题就是到底用Dubbo还是Spring Cloud。随着Dubbo开源和微服务在中国近10年的发展,Dubbo拥有超过33k的stars和12k的fork,在github java项目的前十和前三。目前已登记的Dubbo企业用户超过了200个。其中主要包括阿里,弟弟,携程,爱奇艺,斗鱼,等。

Dubbo目前的特点是高扩展性和高性能,按照Dubbo的发展,成为一个完整的微服务解决方案是迟早的事;而Spring的特点就是全面,涵盖了微服务的各个方面,提供了微服务所有问题的解决方案。

微服务分布式框架Dubbo和Spring Cloud_第1张图片

2.Dubbo和Spring Cloud

Dubbo说到底还是一个RPC架构,实现了透明化的远程方法调用,就行调用本地方法一样调用远程方法,只需要简单的配置,没有任何的Api入侵。
Spring Cloud则抛弃了传统的RPC通信方式,采用了基于HTTP的REST的方式。这种方式,牺牲了服务器的调用的性能,但也避免了原生RPC带来的问题。同时REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更为合适。
(其中官方推荐的解决方案为SpringCloud OpenFeign,它最核心的作用是为 HTTP 形式的 Rest API 提供了非常简洁高效的 RPC 调用方式)

3.注册中心

关于CAP理论

  • 一致性(Consistency) (所有节点在同一时间具有相同的数据)
  • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
  • 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
    一个系统不能同时保证A和C。

主流的注册中心

Nacos Eureka Consul CoreDNS Zookeeper
一致性协议 CP+AP AP CP CP
健康检查 TCP/HTTP/MYSQL/Client Beat Client Beat TCP/HTTP/gRPC/Cmd Keep Alive
负载均衡策略 权重/metadata/Selector Ribbon Fabio RoundRobin
雪崩保护
自动注销实例 支持 支持 不支持 不支持 支持
访问协议 HTTP/DNS HTTP HTTP/DNS DNS TCP
监听支持 支持 支持 支持 不支持 支持
多数据中心 支持 支持 支持 不支持 不支持
跨注册中心同步 支持 不支持 支持 不支持 不支持
SpringCloud集成 支持 支持 支持 不支持 支持
Dubbo集成 支持 不支持 不支持 不支持 支持
K8S集成 支持 不支持 支持 支持 不支持
(表侵删)

3.1.Zookeeper

zk是Apache Hadoop的子项目,是一个树形的目录服务,支持变更推送,适合作为Dubbo服务的注册中心。

Zookeeper的功能主要是它的树形节点来实现的。当有数据变化的时候,或者节点过期的时候,会通过事件触发通知对应的客户端数据变化了,然后客户端再请求zookeeper获取最新的数据,采用push-pull来做树更新。服务注册和消费信息直接存储在zk树形节点上,集群下采用国办机制保证服务节点简单一致性。

(消息队列kafka也是依赖于zk,Kafka把它的meta数据都存储在ZK上,所以说ZK是必要存在的,没有ZK没法运行Kafka)

2018年阿里将Dubbo捐献给了apache。

3.2.Nacos

Nacos是阿里巴巴开发的开源工具,用于实现分布式系统的服务发现与配置管理,Nacos是Dubbo生态系统中重要的注册中心实现,提供了简洁的配管和注册管理操作界面。
Nacos的配置中心和注册中心实现的是两套代码。Nacos依赖Mysql数据库做数据存储,当有数据更新的时候,直接更新数据库的数据,然后将数据更新的信息异步广播给Nacos集群中所有服务节点数据变更,在由Nacos服务节点更新本地缓存,然后将通知客户端节点数据变化。

3.3.Eureka

Spring Cloud 的注册中心。

4.技术选择

1.Spring Cloud 全家桶

2.Spring Cloud + Nacos +

2.Spring boot + Dubbo + Zookeeper +

3.Spring boot + Dubbo + Nacos +

具体需要根据项目的技术栈,服务器,等各种因素选择最合适的技术方案。

5.总结

Dubbo和Spring Cloud并不是完全的竞争关系,两者所解决的问题域不一样:Dubbo的定位始终是一款RPC框架,而Spring Cloud的目的是微服务架构下的一站式解决方案。同时Dubbo和Spring框架可以实现无缝集成。
非要比较的话,Dubbo可以类比到Netflix OSS技术栈,而Spring Cloud集成了Netflix OSS作为分布式服务治理解决方案,但除此之外Spring Cloud还提供了包括config、stream、security、sleuth等分布式服务解决方案。当前由于RPC协议、注册中心元数据不匹配等问题,在面临微服务基础框架选型时Dubbo与Spring Cloud只能二选一,这也是两者总拿来做对比的原因。Dubbo之后会积极寻求适配到Spring Cloud生态,比如作为SpringCloud的二进制通讯方案来发挥Dubbo的性能优势,或者Dubbo通过模块化以及对http的支持适配到Spring Cloud。

你可能感兴趣的:(分布式,dubbo,微服务,分布式)