下载掌阅APP，畅读海量书库
立即打开
微服务分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试，服务消费方并不知道有哪些实例在给他们提供服务。这带来了一些问题：无法直观地看到服务提供方和服务消费方当前的运行状况与通信频率；消费方的失败重发、负载均衡等都没有统一策略，这加大了开发每个服务的难度，不利于快速演化。
为了解决上面的问题，我们需要一个现成的中心组件对服务进行整合，将每个服务的信息汇总，包括服务的组件名称、地址、数量等。
服务的调用方在请求某项服务时首先通过中心组件获取提供服务的实例信息（IP、端口等），再通过默认或自定义的策略选择该服务的某一提供方直接进行访问，所以考虑引入 Dubbo。
Dubbo是阿里开源的一个SOA服务治理解决方案，文档丰富，在国内的使用度非常高。如图 1.7 所示为 Dubbo 的基本架构图，使用 Dubbo 构建的微服务已经可以较好地解决上面提到的问题。
图 1.7
从图 1.7 中，可以看出以下几点：
●调用中间层变成了可选组件，消费方可以直接访问服务提供方。
●服务信息被集中到 Registry 中，形成了服务治理的中心组件。
●通过 Monitor 监控系统，可以直观地展示服务调用的统计信息。
●服务消费者可以进行负载均衡、服务降级的选择。
但是对于微服务架构而言，Dubbo 并不是十全十美的，也有一些缺陷，比如：Registry严重依赖第三方组件（ZooKeeper 或者 Redis），当这些组件出现问题时，服务调用很快就会中断。
Dubbo 只支持 RPC 调用。这使得服务提供方与调用方在代码上产生了强依赖，服务提供方需要不断将包含公共代码的Jar包打包出来供消费方使用。一旦打包出现问题，就会导致服务调用出错。
Dubbo和Spring Cloud并不是完全的竞争关系，两者所解决的问题域并不一样。
Dubbo的定位始终是一款RPC框架，而Spring Cloud的目标是微服务架构下的一站式解决方案。如果非要比较的话，Dubbo可以类比到Netflix OSS技术线，而 Spring Cloud集成了Netflix OSS作为分布式服务治理解决方案，但除此之外 Spring Cloud还提供了配置、消息、安全、调用链跟踪等分布式问题解决方案。
当前由于RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo 与 Spring Cloud 只能二选一，这也是大家总是拿Dubbo 和 Spring Cloud做对比的原因之一。Dubbo已经适配到 Spring Cloud生态，比如作为Spring Cloud的二进制通信方案来发挥 Dubbo 的性能优势，Dubbo通过模块化以及对 HTTP 的支持适配到 Spring Cloud。
Dubbo 与SpringCloud的区别：
●Spring遗弃了Dubbo的RPC通信，采用了基于HTTP的REST方式，REST比RPC更加灵活，服务提供方和调用方的依赖只是需要一纸的协议，不存在代码的级别依赖，在快速的演化的微服务环境下，显得得更加灵活了
●Spring Cloud的功能比Dubbo更加强大，覆盖更加广泛，能够完美地融合Spring Data，Spring Boot，Spring Bacth等等其他的Spring的项目，就如同名牌的电脑做了大量的兼容的测试，而Dubbo就如同组装的电脑什么样的技术都有没有做过兼容测试，总会出现乱七八糟的问题。
●Dubbo定位于一款RPC的框架，而SpringCloud的目标是微服务架构下的一站式解决的方案，在面临微服务的技术架构下，Dubbo与SpringBoot只能二选一。