微服务相关整理，及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