Java微服务框架选型

新的篇章

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构

——Martin Fowler的博客

本文主要是针对于初学者对微服务选型的若干问题和疑惑

DUBBO

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

1. 框架

模块注解

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

流程详解

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

2. 集群容错

面对服务消费方，当业务逻辑中需要调用一个服务时，真正调用的其实是 Dubbo 创建的一个 Proxy，该 Proxy 会把调用转化成调用指定的 Invoker（Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个（通过 LoadBalance），Invoker 封装了 Provider 地址及 Service 接口信息）。而在这一系列的委托调用的过程里就完成了服务治理的逻辑，最终完成调用

3. 特点

• 远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装（非阻塞 I/O 的通信方式，Mina/Netty/Grizzly），包括多种线程模型，序列化（Hessian2/ProtoBuf），以及“请求-响应”模式的信息交换方式
• 集群容错: 提供基于接口方法的透明远程过程调用（RPC），包括多协议支持（自定义 RPC 协议），以及软负载均衡（Random/RoundRobin），失败容错（Failover/Failback），地址路由，动态配置等集群支持
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器

4. 发展历程

• 2008 年，阿里巴巴开始内部使用 Dubbo
• 2009 年初，发布 1.0 版本
• 2010 年初，发布 2.0 版本
• 2011 年 10 月，阿里巴巴宣布开源，版本为 2.0.7
• 2012 年 3 月，发布 2.1.0 版本
• 2013 年 3 月，发布 2.4.10 版本
• 2014 年 10 月，发布 2.3.11 版本，之后版本停滞
• 2017 年 9 月，阿里巴巴重启维护，重点升级所依赖 JDK 及组件版本，发布 2.5.4/5 版本
• 2017 年 10 月，发布 2.5.6 版本
• 2017 年 11 月，发布 2.5.7 版本，后期集成 Spring Boot
• 2014 年 10 月，当当网 Fork 了 Dubbo 版本，命名为 Dubbox-2.8.0，并支持 HTTP REST 协议

SpringCloud

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

1. 核心功能

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

2. 完整技术

3. 组件架构

流程

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

4. 工具框架

• 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比SpringCloud效率高？

DUBBO和SpringCloud功能的对比

Dubbo负责人说明：

这里就不得不提到目前的一些文章在谈到微服务的时候总是拿 Spring Cloud 和 Dubbo 来对比，需要强调的是 Dubbo 未来的定位并不是要成为一个微服务的全面解决方案，而是专注在 RPC 领域，成为微服务生态体系中的一个重要组件。至于大家关注的微服务化衍生出的服务治理需求，我们会在 Dubbo 积极适配开源解决方案，甚至启动独立的开源项目予以支持。受众主要来自国内各友商以及个人开发者，希望将来能够将用户拓展到全球，代表国人在 RPC 领域与 gRPC（基于 HTTP 2.0）、Finagle 等竞争

其实相比于 Dubbo，Spring Cloud 可以说是一个更完备的微服务解决方案，它从功能性上是 Dubbo 的一个超集

DUBBO和SpringCloud的优劣

1. DUBBO

• 优点
  • Dubbo 支持 RPC 调用，服务之间的调用性能会很好
  • 支持多种序列化协议，如 Hessian、HTTP、WebService
  • Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能
  • 在国内影响力比较大，中文社区文档较为全面。
  • 阿里最近重启维护
• 问题
  • Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断
  • Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）
  • Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如 Thrift、gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）
  • Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大
  • 社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了，就尴尬了
  • 主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些

2. SpringCloud

• 优点
  • 有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃
  • 标准化的将微服务的成熟产品和框架结合一起，Spring Cloud 提供整套的微服务解决方案，开发成本较低，且风险较小
  • 基于 Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点
  • 支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。另外，结合 Swagger，也使得服务的文档一体化
  • 提供了 Docker 及 Kubernetes 微服务编排支持
  • 国内外企业应用非常多，经受了大公司的应用考验（比如 Netfilx 公司），以及强大的开源社区支持
• 问题
  • 支持 REST 服务调用，可能因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如 Swagger）
  • REST 服务调用性能会比 RPC 低一些（但也不是强绑定）
  • Spring Cloud 整合了大量组件，相关文档比较复杂，需要针对性的进行阅读

建议

• 使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题
• 而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解
• 想象一下我们买电脑的过程，从小白到大牛，都是从整机到组装的过程。所以我个人建议，在没有其他特殊情况下，初入微服务的小白还是选择SpringCloud作为练手对象，这样会使自己对整个微服务生态有一个比较好的了解，便于以后深入。如果公司业务需要DUBBO或者其他原因，还是建议你在了解微服务生态之后再选择DUBBO^_

参考资料：

微服务架构的基础框架选择：Spring Cloud 还是 Dubbo？

Java微服务架构选型

springcloud(一)：大话 Spring Cloud

到底孰优孰劣？Dubbo 和 Spring Cloud 微服务架构终极对决！