本文代码地址
- https://github.com/Colinlyj210/spring-cloud-demo
- https://github.com/Colinlyj210/spring-cloud-demo-config
Spring Cloud大家庭
- Eureka：服务注册和发现组件
- Ribbon：负载均衡
- Hystrix：熔断组件
- Config：统一配置管理
- Zuul：路由网关
- Bus：消息总线
- Sleuth：分布式链路追踪
- ...
Eureka
Spring Cloud Eureka提供服务端与客户端，服务端即是服务注册中心，客户端完成注册与发现。
Ribbon
在微服务中使用Ribbon实现负载均衡，Ribbon先从Eureka Server中获取列表，然后根据负载均衡算法进行负载均衡，将请求转发到其他微服务。
Hystrix
由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。为了解决这个问题，业界提出了断路器模型。
Config
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。
Zuul
Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如/api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能。
Zuul有以下等功能：
- Dynamic Routing
- Authentication
- Security
- Static Response handling
- Stress Testing
- Service Migration
- Load Shedding
Bus
Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。当git文件更改的时候，通过pc端用post 向端口为8882的config-client发送请求/bus/refresh／；此时8882端口会发送一个消息，由消息总线向其他服务传递，从而使整个微服务集群都达到更新配置文件。（Webhook）
Sleuth
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
Spring Cloud VS Dubbo
Dubbo
Spring Cloud 与Dubbo核心架构要素对比
| 微服务关注点 | Spring Cloud | Dubbo |
|---|---|---|
| 服务注册中心 | Eureka | Zookeeper |
| 服务调用方式 | REST API | RPC |
| 服务网关 | Zuul | 无 |
| 断路器 | Hystrix | 不完善 |
| 分布式配置 | Config | 无 |
| 负载均衡 | Ribbon | 自带 |
| 分布式追踪 | Spring Cloud Sleuth | 无 |
| 消息总线 | Spring Cloud Bus | 无 |
Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。
Dubbo 提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善。例如：
分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
服务跟踪：可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。
批量任务：可以使用当当开源的 Elastic-Job、tbschedule。
从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合，而 Dubbo 却需要通过实现各种 Filter 来做定制，开发成本以及技术难度略高。
通讯协议
Dubbo 使用 RPC 通讯协议，提供序列化方式如下：
- Dubbo：Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
- RMI：RMI 协议采用 JDK 标准的 java.rmi.* 实现，采用阻塞式短连接和 JDK 标准序列化方式。
- Hessian：Hessian 协议用于集成 Hessian 的服务，Hessian 底层采用 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现。
- HTTP：采用 Spring 的 Http Invoker 实现。
- Webservice：基于 CXF 的 frontend-simple 和 transports-http 实现。
Spring Cloud 使用 HTTP 协议的 REST API。
性能比较
Dubbo 支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜 Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
服务依赖方式
Dubbo需要为每个微服务定义各自的 Interface 接口，并通过持续集成发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。
Spring Cloud 通过 Json 交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身 Rest API 方式交互，为跨平台调用奠定了基础。
组件运行流程
Dubbo 需要自己开发一套 API 网关，而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。
Kubernates
Kubernates是一个容器集群管理系统，为容器化的应用程序提供部署运行、维护、扩展、资源调度、服务发现等功能。Kubernates是Google运行Borg大规模系统达15年之久的一个经验总结。它结合了社区的最佳创意和实践，旨在帮助开发人员将容器打包、动态编排，同时帮助各大公司向微服务方向进行技术演进。
Kubernates VS Spring Cloud
| 服务关注点 | Spring Cloud | Kubernates |
|---|---|---|
| 配置管理 | Config | Kubernates ConfigMap |
| 服务发现 | Eureka | Kubernates Services |
| 负载均衡 | Ribbon | Kubernates Services |
| 网关 | Zuul | Kubernates Services |
| 分布式追踪 | Sleuth | Open tracing |
| 容错 | Hystrix | Kubernates Health Check |
| 分布式日志 | ELK | EFK |
| 任务管理 | Spring Batch | Kubernates Jobs |
Kubernates是支持多语言，是一个容器管理平台，使程序容器化，并在容器管理上提供微服务功能。
除了提供基本的构建微服务功能外，还提供了环境、资源限制、管理应用程序生命周期的功能。Kubernates更像是一个平台，而Spring Cloud是一个框架。
Kubernates面向DevOps人员，普通开发人员需要学习很多这方面的知识，而且新特性更新快，需要DevOps人员学习跟进，学习成本非常高。
