微服务框架选型（Dubbo 和 Spring Cloud）

一、概念

       微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

旨在：通过将功能分解到各个离散的服务中以实现对解决方案的解耦。将其看作是在架构层次而非获取服务的，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题

1、Dubbo 是什么

      Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。

架构图：

模块注解：

• Provider: 暴露服务的服务提供方。
• Consumer: 调用远程服务的服务消费方。
• Registry: 服务注册与发现的注册中心。
• Monitor: 统计服务的调用次调和调用时间的监控中心。
• Container: 服务运行容器。
  

流程详解：

• 0 服务容器负责启动，加载，运行服务提供者（Standalone 容器）。
• 1 服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。
• 2 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重）
  

2、Spring Cloud 是什么

      Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

重点：

• 基于 Spring Boot
• 云服务、分布式框架集合（众多）
  

核心功能：

• 分布式/版本化配置
• 服务注册和发现
• 路由
• 服务和服务之间的调用
• 负载均衡
• 断路器
• 分布式消息传递
  

Spring Cloud 组件架构：

流程：

• 请求统一通过 API 网关（Zuul）来访问内部服务。
• 网关接收到请求后，从注册中心（Eureka）获取可用服务。
• 由 Ribbon 进行均衡负载后，分发到后端具体实例。
• 微服务之间通过 Feign 进行通信处理业务。
• Hystrix 负责处理服务超时熔断。
• Turbine 监控服务间的调用和熔断相关指标。
  

Spring Cloud工具框架

• Spring Cloud Config 配置中心，利用 Git 集中管理程序的配置。
• Spring Cloud Netflix 集成众多Netflix的开源软件。
• Spring Cloud Netflix Eureka 服务中心（类似于管家的概念，需要什么直接从这里取，就可以了），一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
• Spring Cloud Netflix Hystrix 熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。
• Spring Cloud Netflix Zuul 网关，是在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Web 网站后端所有请求的前门。
• Spring Cloud Netflix Archaius 配置管理 API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
• Spring Cloud Netflix Ribbon 负载均衡。
• Spring Cloud Netflix Fegin REST客户端。
• Spring Cloud Bus 消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化。
• Spring Cloud for Cloud Foundry 利用 Pivotal Cloudfoundry 集成你的应用程序。
• Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。
• Spring Cloud Cluster 集群工具，基于 Zookeeper, Redis, Hazelcast, Consul 实现的领导选举和平民状态模式的抽象和实现。
• Spring Cloud Consul 基于 Hashicorp Consul 实现的服务发现和配置管理。
• Spring Cloud Security 安全控制，在 Zuul 代理中为 OAuth2 REST 客户端和认证头转发提供负载均衡。
• Spring Cloud Sleuth 分布式链路监控，SpringCloud 应用的分布式追踪系统，和 Zipkin，HTrace，ELK 兼容。
• Spring Cloud Data Flow 一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。
• Spring Cloud Stream 消息组件，基于 Redis，Rabbit，Kafka 实现的消息微服务，简单声明模型用以在 Spring Cloud 应用中收发消息。
• Spring Cloud Stream App Starters 基于 Spring Boot 为外部系统提供 Spring 的集成。
• Spring Cloud Task 短生命周期的微服务，为 Spring Booot 应用简单声明添加功能和非功能特性。
• Spring Cloud Task App Starters。
• Spring Cloud Zookeeper 服务发现和配置管理基于 Apache Zookeeper。
• Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。
• Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
• Spring Cloud Starters （项目已经终止并且在 Angel.SR2 后的版本和其他项目合并）
• Spring Cloud CLI 命令行工具，插件用 Groovy 快速的创建 Spring Cloud 组件应用。
  

二、Dubbo和Spring Cloud区别

     Dubbo 的功能只是 Spring Cloud 体系的一部分。Dubbo 是 SOA 时代的产物，它的关注点主要在于服务调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托Spring、Spring Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spring Cloud 是一个生态。
仅关注于服务治理的这个层面，Dubbo 优于 Spring Cloud：

• Dubbo 支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
• Dubbo Admin有更强大的后台管理，Dubbo 提供的后台管理 Dubbo Admin 功能强大，提供路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能
• Dobbo Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断
• Dubbo 使用 RPC 协议效率更高，Dubbo由于是二进制的传输，占用带宽会更少
• Spring Cloud 是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大，在极端压力测试下，Dubbo 的效率会高于 Spring Cloud 效率一倍多，但RESTful比RPC更加灵活，不存在代码级别的强依赖
• 可以限制某个 IP 流量的访问权限，设置不同服务器分发不同的流量权重，并且支持多种算法，利用这些功能可以在线上做服务治理、灰度发布、故障转移、流量分发等，Spring Cloud 到现在还不支持灰度发布、流量权重等功能。
• 最大的区别就是通信方式不同，Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输，配合hession序列化进行RPC调用，springcloud是基于REST调用
• Spring Cloud提供了 Docker 及 Kubernetes 微服务编排支持
  

服务调用方式的不同

Dubbo 和 Spring Cloud 对比

三、ZooKeeper 和 Eureka 的区别

      鉴于服务发现对服务化架构的重要性，Dubbo 实践通常以 ZooKeeper 为注册中心（Dubbo 原生支持的 Redis 方案需要服务器时间同步，且性能消耗过大）。针对分布式领域著名的 CAP 理论（C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性），Zookeeper 保证的是 CP ，但对于服务发现而言，可用性比数据一致性更加重要，AP 胜过 CP，而 Eureka 设计则遵循 AP 原则。
Spring Cloud 支持 Consul（CA）和 Zookeeper，但不推荐使用。

参考资料：https://www.cnblogs.com/xishuai/p/dubbo-and-spring-cloud.html