6.1 Dubbo
6.1.1 Dubbo概述
服务间基于RPC的方式调用。
6.1.2 核心流程
Dubbo中必有的核心概念只有服务提供者、服务消费者和注册中心这三个，治理中心以及监控中心并非必需品。
服务提供者初始化后会向注册中心注册服务；服务消费者启动时向注册中心订阅服务。注册中心在服务提供者列表发生变化时将变化的内容主动通知给服务消费者。服务提供者和服务消费者在初次连通后，持有长连接，通过透明化的远程调用进行通信。
6.1.3 注册中心
大多数情况，Dubbo都是配合Zookeeper注册中心来使用的。
6.1.4 负载均衡
Dubbo采用客户端负载均衡方式，由服务消费者一方决定当前通信发送至哪个服务提供者。
服务消费者启动时会从注册中心同步一份有效的服务提供者列表，缓存起来，当服务列表变化时，会更新。每次调用服务时，根据合适的负载均衡算法选择一个服务提供者。
Dubbo的服务发现和负载均衡机制，有如下三个特征：
- 弹性好：基于服务发现机制，动态、灵活、实时。
- 高可用：去中心化的服务治理方案，注册中心挂了后，可以使用缓存。但是在注册中心挂了后，无法感知新上线的服务。
- 性能优：服务提供者和消费者之间点对点直接连接，连接建立后无需断开。
Dubbo支持随机、轮询(会导致大量请求阻塞在短板服务上)、最少活跃调用数和一致性哈希这四种负载均衡策略。
重点说一下一致性哈希：为了解决因特网中的热点(Hot spot)问题。
比如：有4个服务器，每个都缓存图片，当定位一个图片时，为了避免访问四次，可以用取模运算的方式来决定图片的位置。但是问题是：当服务器增加或减少时，取模运算会导致所有的图片位置都不对，缓存在短时间内全部失效，叫缓存雪崩。为了避免这种情况，提出一致性哈希算法，目的是当服务器数量增加和减少时，图片缓存的位置不变，不会发生雪崩。
6.1.5 远程通信
Dubbo通信协议采用的是Java NIO实现的多路复用。对于每一个服务消费者来说，Dubbo协议的服务提供者会创建固定数量的长连接传输消息，有效减少握手次数，Dubbo通信协议使用线程池并发处理请求来增加并发效率。由于连接复用，传输大文件时带宽占用率高可能会成为系统瓶颈，因此Dubbo通信协议适合处理高并发的小数据量互联网请求，不适合处理视频、高清照片。
6.1.6 限流
Dubbo服务提供者可以设置限流。
6.1.7 治理中心
提供一个可视化中心，辅助做运维工作。提供了分组查询、配置更改、加权降权、禁用启用、权限控制、负责人管理等运维功能。
6.1.8 监控中心
6.1.9 DubboX的扩展
DubboX由当当网开源，X是extensions一词，是对Dubbo的扩展。
Rest协议：Dubbo缺乏对RESTful风格支持。 DubboX弥补了这一缺憾。
高新能序列化：序列化对远程调用的响应速度、吞吐量、网络带宽影响大。Dubbo支持的不算太好，DubboX进行了扩展。
6.2 Spring Cloud
提供了一套云原生开发组件。
6.2.1 概述
Spring Cloud是基于Spring boot的嵌入式服务治理框架，建立在工程师熟悉约定的前提下。
6.2.2 开发脚手架Spring Boot
自动装配：
Spring boot对Spring 进行封装，通过约定优于配置以及元注解驱动的设计理念。
Spring Boot提供了内嵌的Web服务器并简化了Spring MVC配置，提供了对数据库、NOSQL、缓存、消息中间件、REST访问、邮件发送等第三方服务的高度整合。
启动Spring boot的入口应用仅需要一个注解和一行代码。
@SpringBootApplication是@Configuration 、 @EnableAutoConfiguration 、@ComponentScan这三个注解的组合。
暴露端点：
Spring boot提供了Actuator模块用于方便地暴露应用自身的信息，以便监控与管理。
6.2.3 服务发现
-
- Eureka
- 使用zookeeper
- 使用Consul
6.2.4 负载均衡
Ribbon: 提供了客户端负载均衡的解决方案。自动的从Eureka中获取服务提供者列表，将负载均衡与服务发现结合起来。
6.2.5 熔断
Hystrix做为熔断器，并通过它实现熔断后的业务降级。
6.2.6 远程通信
Spring cloud采用当前较为流行的RESTful API进行服务之间交互。Feign。