1.实现微服务需要解决的问题

马丁福勒于2014年在一篇文章中提出微服务架构，原文地址如下：

Microservices

微服务只是一个概念，目前业内还没有统一的标准。

微服务的概念大致如下：

将大系统划为一个个分开部署的小服务。小服务独立运行，采用轻量级的通信机制进行相互沟通、调用。由于通信底层基本是采用面向API的http请求，模块之间只有数据交互，并无直接的代码调用，所以不同模块可以采用不同的编程语言来编写。

微服务在实现上需要解决以下一些问题：

客户端如何知道服务在哪台服务器上？

服务间如何进行通信？

如何进行容错？

其实不管是spring cloud也好，还是其它微服务框架也好，核心就是要解决以上几个问题，各个框架的不同点只是在于解决上面问题的方式不同。

2.解决这些问题需要的技术栈

前面我们已经说了微服务在实现上需要解决的一些问题，这些问题细化下来需要多个维度的技术来一起解决，因此目前微服务的技术栈长这样：

维度 组件

服务开发 Springboot、spring、springMVC

服务配置与管理 Netfilx公司的Archaius、阿里的Diamond

服务注册与发现 Eureka、Consul、Zookeeper

服务调用 Rest、RPC、gRPC

服务的熔断器 Hystrix、Enovy等

负载均衡 Ribbon、Nginx等

服务接口调用 Feign

消息队列 Kafka、RabbitMQ、ActiveMQ等

服务配置中心管理 SpringCloudConfig、chef等

服务路由(API网关) Zuul等

服务监控 Zabbix、Nagios、Metrics、Spectator等

全链路追踪 Zipkin、Brave、Dapper等

服务部署 Docker、OpenStack、Kubernates等

数据流操作开发包 SpringCloud Stream（封装Redis、RabbitMQ、Kafka等发送接收消息）

时间消息总线 Spring Cloud Bus

3.spring cloud

分布式微服务技术栈是个理念，由多个维度的技术理念来构成。

springCloud则是分布式微服务技术栈的一个落地实现。其中实现或者集成一个分布式技术栈需要的各个维度的技术。是个一站式的分布式微服务全家桶。

有的技术维度是springcloud自己实现，有的则是集成市面上成熟优秀的解决方案。

spring官网上对于springCloud的介绍原文：

“Building distributed systems doesn't need to be complex and error-prone. Spring Cloud offers a simple and accessible programming model to the most common distributed system patterns, helping developers build resilient, reliable, and coordinated applications. Spring Cloud is built on top of Spring Boot, making it easy for developers to get started and become productive quickly.”

构建分布式系统不需要复杂且容易出错。SpringCloud为最常见的分布式系统模式提供了一个简单和可访问的编程模型，帮助开发人员构建弹性、可靠和协调的应用程序。SpringCloud构建在SpringBoot之上，使开发人员很容易开始工作并迅速提高生产力。

 

4.Netflix和Alibaba

alibaba率先推出微服务框架dubbo，dubbo是个生态体系，各个环节均整合业内优秀的方案（如注册中心采用zookeeper，等等……），业内没有成型解决方案的，alibaba再推出自己的组件，最初的dubbo较为简陋只支持最基础的服务管理功能。

后来alibaba没有连续迭代dubbo，中间断代一段时间，

spring社区联合Netflix公司抓住机会推出springcloud Netflix，分布式微服务的一站式解决方案。迭代到H版时，由于核心开发团队人员流失，springcloud Netflix官方失去继续大版本迭代的能力，目前springcloud Netflix版已经进入维护模式，只进行修补，不再进行大版本的迭代。

alibaba随后接棒推出springcloud alibaba。springcloud alibaba已经登录spring社区。

所以springcloud存在一个新旧体系的问题。

5.springCloud和doubbo

通信机制上的区别:

SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适

上手代价上的区别：

SpringCloud是一个全家桶，各种组件都组装好了，开箱即食，就像一台一体式的品牌机，一步到位。doubbo就像一台组装式的电脑，各环节选择的自由度很高，以doubbo为核心需要辅以其它第三方组件来实现微服务架构。

社区支持与更新力度：

最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级(比如当当网弄出了Dubbox) ，这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。

以下是他们各自组件的不同：

6.版本适配

springcloud和springboot之间存在版本号兼容问题

springcloud官网上给出了boot和cloud间的版本号适配。

7.停更

springcloud中有些组件停止了更新。

注册中心：

Eurake停用，使用Nacos。

服务调用：

Ribbon停止更新，建议使用LoadBalancer。

Feign停用，使用OpenFeign。

服务降级：

Hystrix停用，使用Sentinel。

服务网关：

Zuul停用，使用gateWay。

服务配置：

Config停用，使用Nacos。

服务总线：

Bus停用，使用Nacos。