1.前言
选择阿里系还是Spring全家桶?
谈到微服务技术的选择,面临的第一个问题就是到底用Dubbo还是Spring Cloud。随着Dubbo开源和微服务在中国近10年的发展,Dubbo拥有超过33k的stars和12k的fork,在github java项目的前十和前三。目前已登记的Dubbo企业用户超过了200个。其中主要包括阿里,弟弟,携程,爱奇艺,斗鱼,等。
Dubbo目前的特点是高扩展性和高性能,按照Dubbo的发展,成为一个完整的微服务解决方案是迟早的事;而Spring的特点就是全面,涵盖了微服务的各个方面,提供了微服务所有问题的解决方案。
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。