新的篇章
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构
——Martin Fowler的博客
本文主要是针对于初学者对微服务选型的若干问题和疑惑
DUBBODubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架
1. 框架 模块注解 Provider: 暴露服务的服务提供方Consumer: 调用远程服务的服务消费方Registry: 服务注册与发现的注册中心Monitor: 统计服务的调用次调和调用时间的监控中心Container: 服务运行容器 流程详解 服务容器负责启动，加载，运行服务提供者（Standalone 容器）服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）服务消费者在启动时，向注册中心订阅自己所需的服务注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重） 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 年，阿里巴巴开始内部使用 Dubbo2009 年初，发布 1.0 版本2010 年初，发布 2.0 版本2011 年 10 月，阿里巴巴宣布开源，版本为 2.0.72012 年 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 Boot2014 年 10 月，当当网 Fork 了 Dubbo 版本，命名为 Dubbox-2.8.0，并支持 HTTP REST 协议 SpringCloudSpring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等
1. 核心功能 分布式/版本化配置服务注册和发现路由服务和服务之间的调用负载均衡断路器分布式消息传递 2. 完整技术 3. 组件架构 流程 请求统一通过 API 网关（Zuul）来访问内部服务网关接收到请求后，从注册中心（Eureka）获取可用服务由 Ribbon 进行均衡负载后，分发到后端具体实例微服务之间通过 Feign 进行通信处理业务Hystrix 负责处理服务超时熔断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 StartersSpring Cloud Zookeeper 服务发现和配置管理基于 Apache ZookeeperSpring 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、WebServiceDobbo 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 微服务架构终极对决！