BATJ架构

Spring Cloud与Dubbo优缺点

2020-08-04  本文已影响0人  裘马轻狂大帅

Spring Cloud与Dubbo优缺点

Dubbo由于是二进制的传输,占用带宽会更少。Spring Cloud 是 HTTP 协议传输,带宽占用会比较多,同时使用 HTTP 协议一般会使用 JSON 报文,消耗会更大。

Dubbo 的开发难度较大,原因是 Dubbo 的 jar 包依赖问题很多大型工程无法解决;Spring Cloud 的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级。

Dubbo 的注册中心可以选择 ZK、Redis 等多种;Spring Cloud 的注册中心只能用 Eureka 或者自研。

但如果我选,我会用 Spring Cloud。

从公司整体规划考虑

我不会选择很久没人维护的 Dubbo,重启之后也未必是原班人马。

从程序员招聘难度考虑

招 Spring Cloud 的程序员会更好招,因为更新更炫。

从系统结构简易程度考虑

Spring Cloud的系统结构更简单,“注册+springmvc=springcloud”,而 Dubbo 各种复杂的 URL、protocol、register、invocation、dubbofilter、dubboSPI,dubbo序列化……炫技的成分更多一些。

从性能考虑

Dubbo 的网络消耗小于 Spring Cloud,但是在国内95%的公司内,网络消耗不是什么太大问题。如果真的成了问题,通过压缩、二进制、高速缓存、分段降级等方法,很容易解。

从开发难易度考虑

Dubbo 的神坑是 jar 包依赖,开发阶段难度极大。Spring Cloud比较自由,但带来的问题是无法“强力约束接口规范”,建议用行政方式解决,且我们团队的强力行政约束做的还是比较好的,在接口管控层面比较强效,一个没有行政组织能力的IT团队真的是个废渣,用什么框架都不好使。

从后续改进考虑

Dubbo 的改进是通过 dubbofilter,很多东西没有,需要自己继承,如监控、日志、限流、追踪。Spring Cloud 自己带了很多监控、限流措施,但是功能可能和欧美习惯相同,国内需要进行适当改造,但更简单,就是 ServletFilter 而已,但是总归比 Dubbo 多一些东西是好的。

上一篇下一篇

猜你喜欢

热点阅读