Dubbo 与 SpringCloud

• Dubbo的缺点，过分依赖zookeeper，就是过分依赖注册中心。在微服务中，应该做到各司其职，就是注册中心，服务网关,配置中心，三者不应该耦合度那么高。【与springcloud的对比：注册中心——Eureka、服务网关——Zuul、配置中心——SpringCloud Config】。
  微服务理应各个服务解耦，独立不相关的。

• Dubbo的容错策略，没有细粒度到方法级别上；负载均衡则可以确定到方法上，导致使用上有一定的别扭。

• 引申出的问题：一个服务，如果都是查询，配置成failover；若有添加或修改，一定要配置成failfast
目前Dubbo的集群容错策略，还没有能够细粒度到方法上

• Dubbo在微服务的地位
  Dubbo更擅长Tcp/Ip协议，虽然支持http协议，但是那样就是相当于一个单机的传统业务，类似部署在tomcat中了。

dubbo所暴露的服务，一般情况下是不支持浏览器的。服务面向tcp/ip的客户端

Dubbo多用于内网集群间通讯，解决服务集群之间的调用的，然后Application/Controller控制层想要调用服务，连接到的是注册中心。

用户访问的是Nginx，然后访问应用，再访问注册中心…这个过程之中，用户是感觉不出来使用了dubbo。dubbo擅长构建内网的，基于tcp/ip通讯的集群。

Dubbo是将原来应用中的service剥离出来，然后暴露出来，而controller没变。MVC三层中的Model层进行了剥离拆分。

而SpringCloud才是擅长分离应用层/控制层。综上dubbo和springcloud各有擅长的领域。dubbo擅长内网基于模型，业务层的拆分、springcloud则是擅长对控制层拆分。dubbo主内，springcloud主外。

又因为业务层主要是内部通讯，毋须面向用户，且使用tcp/ip层协议能更好的提升性能，选择Dubbo；对外使用springcloud，对controller进行拆分，再用上分布式的Nosql，就是全栈分布式