微服务用 Spring Cloud 多还是 Dubbo 多？

springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研但如果我选，我会用springcloud。从公司整体规划：我不会选择很久没人维护的dubbo，重启之后也未必是原班人马从程序员招聘难度：招springcloud的程序员会更好招，因为更新更炫从系统结构简易程序：springcloud的系统结构更简单、“注册+springmvc=springcloud”，而dubbo各种复杂的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化…炫技的成分更多一些从性能：dubbo的网络消耗小于springcloud，但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解从开发难易度：dubbo的神坑是jar包依赖，开发阶段难度极大，我曾经带一个三十人的团队，因为jar包升级问题，把每个人的电脑都操作过，尤其每个人电脑的库路径、命令、快捷键、键盘，鼠标快慢都不一样，那会儿我默默的在心中艹了dubbo发明者全家老小一百二十遍。springcloud比较自由，但带来的问题是无法“强力约束接口规范”，建议用行政方式解决，且我们团队的强力行政约束做的还是比较好的，在接口管控层面比较强效，一个没有行政组织能力的IT团队真的是个废渣，用什么框架都不好使。从后续改进：dubbo的改进是通过dubbofilter，很多东西没有，需要自己继承，如监控，如日志，如限流，如追踪。springcloud自己带了很多监控、限流措施，但是功能可能和欧美习惯相同，国内需要进行适当改造，但更简单，就是ServletFilter而已，但是总归比dubbo多一些东西是好的从配套措施：springcloud一直宣称自己是“一套全方面的解决方案”。。。。。。我起初信了，后来发现上当了，实话说：有，但是不是很健全，100分打50的样子，很多你还需要改造。而DUBBO相反，