微服务相关整理，及spring cloud和dubbo的比较
当下微服务主要的优势如下：
1、降低耦合及复杂度，
每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界
2、可独立部署
3、容错，
限流、熔断、降级
4、扩展
交互（核心）描述：
服务提供方
Provider
将自己要发布的服务注册到注册中心
Registry，服务调用方
Consumer启动后
向注册中心
Registry
订阅它想要调用的服务，这时，
注册中心
Registry将其所管理的服务列表通知给到
服务调用方Consumer(
注册中心和提供方和调用方之间均保持长连接，可以获取Provider发布的服务的变化情况，并将最新的服务列表推送给
服务调用方
Consumer
)，
服务调用方
Consumer
根据从注册中心
Registry
获得的服务列表，根据软负载均衡算法选择一个服务提供者Provider进行远程服务调用，如果调用失败则选择另一台进行调用（
服务调用方
Consumer会缓存服务列表，即使注册中心宕机也不妨碍进行远程服务调用），在整个交互过程中，
监控中心Monitor
对服务的发布和订阅进行监控和统计服务消费者和提供者，并在内存中累计调用次数和调用时间，而且会定时每分钟发送一次统计数据到监控中心Monitor；Monitor可以选择Zookeeper、Redis或者Multiast注册中心等
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置等，基于上述几种必要条件对 Dubbo 和 Spring Cloud 做出对比。
|
划分
|
Spring Cloud
|
Dubbo
|
备注
|
| 形象比喻 |
电脑整机（
性能有保证）
|
组装机（可自定义，比较自由）
|
一个是工具集一个是rpc框架
|
|
服务注册中心
|
只能选Eureka Server或者自研
|
（三方）Zookeeper(也可以使用Redis,但需要服务器时间同步，且性能消耗过大)
|
Zookeeper采用树形的目录结构来存储
Provider注册的远程服务信息
Redis是一个基于内存的，以Key-Value形式存储数据的高性能Nosql数据库，可以用来存储远程服务信息用作注册中心
|
|
服务调用方式
|
HTTP(rest接口)，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大
|
RPC模式，即
二进制传输，即TCP，
占用带宽会更少
,
配合以Hession序列化
|
微服务在本质上就是rpc
rpc有基于tcp的，http的，mq的等等
spring cloud是基于spring boot的，而spring boot 实现的是http协议，算是rpc的一个子集
TCP属于传输层，而HTTP属于应用层（文本传输），TCP上是基于网络层的IP等协议
HTTP上层协议是基于TCP的，但相对而言HTTP方便多语言开发整合
|
|
服务网关
|
Spring Cloud Netflix Zuul
|
可以考虑
soul、
gateway等
|
|
|
熔断器
|
Spring Cloud Netflix Hystrix
|
Sentinel
|
解释：
微服务之间的相互调用可能出现各种各样的原因导致服务的阻塞，在高并发场景下，服务的阻塞意味着线程的阻塞，导致当前线程不可用，服务器的线程全部阻塞，导致服务器崩溃，由于服务之间的调用关系是同步的，会对整个微服务系统造成服务雪崩。
为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的系统资源引起雪崩效应就需要进行服务熔断和服务降级处理。即：
当某个异常条件被触发就直接熔断整个服务，而不是一直等到此服务超时
|
|
分布式配置
|
Spring Cloud Config
|
无(可选用百度的Disconf、
淘宝的diamond
、携程Apollo
)
|
disconf 依赖比较多，比如zookeeper等都需要提供环境；
apollo依赖较少，只有一个db。阿波罗在多环境配置时，需要搭建多个config-server，这种结构非常干净，但是多环境产生成本，所以暂未使用。
|
|
负载均衡
|
Netflix发布的Ribbon，提供的有轮询、随机等多种负载均衡算法
|
有(内置)
|
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
|
|
服务调用
|
Feign（是一个声明式的WEB客户端，本质上就是一个HTTP,只是在进行了内部封装），通过@FeignClient等注解的方式完成服务调用
|
有(内置)
|
|
|
服务追踪
|
Sleuth
sleuth+elk 结合，聚合微服务日志
sleuth+ zipkin结合，显示文件调用链路
|
可以使用京东开源的Hydra
|
|
|
消息总线
|
Spring Cloud Bus
|
无
|
|
|
监控
|
Spring Boot Admin
|
Dubbo Admin
|
|
|
批量任务
|
Spring Cloud Task
|
可以使用开源的Elastic-Job
|
|
|
底层实现
|
servlet
|
Netty（
NIO框架
）
|
|
|
CAP原则
|
遵循
AP原则
|
保证的是CP
|
C——数据一致性
A——服务可用性
P——服务对网络分区故障的容错性
|
| 技术难度 |
接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
对比来说Spring Cloud相对复杂一点，但难度也不是太大
|
dubbo的神坑是jar包依赖，很多大型工程无法解决，但另一方面
dubbo因为有完善的中文文档，所以可以非常快速的上手
|
Dubbo本身只是实现了服务治理
|
|
结构简化描述
|
注册+springmvc=springcloud
|
远程服务运行容器（Container），远程服务提供方（Provider）、注册中心（Register）、远程服务调用者（Consumer）、监控中心（Monitor）。
|
相对来说springcloud的系统结构更简单，但
SpringCloud现在已经有21个子项目，以后还会更多
|
|
社区活跃度
|
Spring Cloud是近5年才兴起的项目，项目和社区一直比较活跃
影响力在全世界
|
Dubbo是在2012年停更的，于2017年开始重新更新，目前还比较活跃。
影响力主要集中在国内
|
|
|
成熟度
|
Spring Cloud是国外Netflix开源的项目，也经历国内外许多公司的验证，也比较成熟
|
Dubbo因为是阿里巴巴开源的框架，在阿里及国内许多大中型公司都有很多的项目实践，经历多次项目检验，比较成熟
|
|
|
文档健全方面
|
Spring Cloud只有英文文档，而且一般只讲解了其中的使用方法
|
Dubbo有完善而且丰富的中文与英文文档
|
|
备注：
SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发
SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架，
为各个微服务之间提供配置管理,服务发现,断路器,路由,事件总线等集成服务
相应的技术栈（转）
|
微服务条目
|
落地技术
|
备注
|
|
服务开发
|
SpringBoot、Spring、SpringMVC
|
|
|
服务配置与管理
|
Netflix公司的Archaius、阿里的Diamind等
|
|
|
服务注册与发现
|
Eureka、Consul、Zookeeper等
|
|
|
服务调用
|
Rest、RPC、gRPC
|
|
|
服务熔断器
|
Hystrix、Envoy等
|
|
|
负载均衡
|
Ribbon、Nginx等
|
|
|
服务接口调用(客户端调用服务的简化工具)
|
Feign等
|
|
|
消息队列
|
Kafka、RabbitMQ、ActiveMQ等
|
|
|
服务配置中心管理
|
SpringCloudConfig、Chef等
|
|
|
服务路由(API网关)
|
Zuul等
|
|
|
服务监控
|
Zabbix、Nagios、Metrics、Spectator
|
|
|
全链路追踪
|
Zipkin、Brave、Dapper等
|
|
|
服务部署
|
Docker、OpernStack、Kubernetes
|
|
|
数据流操作开发包
|
SpringCloud Stream(封装与Redis,Rabbit,Kafaka等发送接收消息)
|
|
|
事件消息总线
|
Spring Cloud Bus
|
|