2019.07.23--运用三W法则初步学习SpringCloud基础知识

本文是从此网址学习后自己整理的文档结果，原文见此处：https://mp.weixin.qq.com/s/kBUJlAp9LLMX_L_q2ab0iA

采用三W原则学习法,一步步深入理解SpringCloud的各种组件并理解其作用,，注：本文不涉及具体编码教学：

WHAT-定义：

集群：同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)

分布式：一个业务分拆多个子业务，部署在不同的服务器上(不同的服务器，运行不同的代码，为了同一个目的)

分布式集群：一个业务分拆多个子业务，部署在不同的服务器上，然后再将每个子业务分别部署在多个服务器上。

• C：数据一致性(consistency)
 所有节点拥有数据的最新版本
• A：可用性(availability)
 数据具备高可用性
• P：分区容错性(partition-tolerance)
 容忍网络出现分区，分区之间网络不可达。

CAP理论定义的其实是在容忍网络分区的条件下P，
“强一致性C”和“极致可用性A”无法同时达到。

基础知识：
SpringCloud的基础功能：
• 服务治理： Spring Cloud Eureka
• 客户端负载均衡： Spring Cloud Ribbon
• 服务容错保护： Spring Cloud Hystrix
• 声明式服务调用： Spring Cloud Feign
• API网关服务：Spring Cloud Zuul
• 分布式配置中心： Spring Cloud Config
SpringCloud的高级功能(本文不讲)：
• 消息总线： Spring Cloud Bus
• 消息驱动的微服务： Spring Cloud Stream
• 分布式服务跟踪： Spring Cloud Sleuth

WHY

把一大的项目，分解成多个小的模块。将其组合起来，完成功能。
但拆分出多个模块后，会出现各种各样的问题，而SpringCloud提供了一整套的解决方案！
• 注：这些模块是独立成一个子系统的(不同主机)。

HOW

# Eureka：
问题1：
子系统之间的通讯问题-远程调用：
现在有A、B、C、D四个服务，它们之间会互相调用(而且IP地址很可能会发生变化)，一旦某个服务的IP地址变了，那服务中的代码要跟着变，手动维护这些静态配置(IP)非常麻烦！
解决：Eureka原理：1.

2. # Eureka治理机制：

WHAT:

# RestTemplate和Ribbon：
RestTemplate：通过服务名来获取具体的服务实例的位置进行调用。
// 传统的方式，直接显示写死IP是不好的！
//private static final String REST_URL_PREFIX = “http://localhost:8001”;

// 服务实例名
private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";

/**
 * 使用 使用restTemplate访问restful接口非常的简单粗暴无脑。 (url, requestMap,
 * ResponseBean.class)这三个参数分别代表 REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。
 */
@Autowired
private RestTemplate restTemplate;

@RequestMapping(value = "/consumer/dept/add")
public boolean add(Dept dept) {
    return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class);
}

# Ribbon：客户端的负载均衡

# Hystrix：

WHY:

问题2调用多个远程服务时，某个服务出现延迟，会怎么样：

HOW:

解决：
Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。
• Fallback(失败快速返回)：当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝）， 向调用方返回一个错误响应， 而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
• 资源/依赖隔离(线程池隔离)：它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响， 而不会拖慢其他的依赖服务。

Hystrix提供几个熔断关键参数：滑动窗口大小（20）、 熔断器开关间隔（5s）、错误率（50%）
• 每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。
• 直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
优点：帮助我们快速发现系统中存在的问题，从而及时地采取应对措施。

WHAT:

# Feign:
整合了 Spring Cloud Ribbon 与 Spring Cloud Hystrix, 除了整合这两者的强大功能之外，它还供了声明式的服务调用(不再通过RestTemplate)。
实现方法：服务绑定->Feign中使用熔断器->调用

WHY:

# ZUUL:
问题：路由规则与服务实例的维护间题+签名校验、 登录校验冗余问题

HOW:

解决：API网关：Spring Cloud Zuul组件
1.与eureka整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。
2. 在API网关服务上进行统一调用来对微服务接口做前置过滤，以实现对微服务接口的拦截和校验。
3. Zuul天生就拥有线程隔离和断路器的自我保护功能，以及对服务调用的客户端负载均衡功能。也就是说：Zuul也是支持Hystrix和Ribbon。

# SpringCloud Config
Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client通过接口获取数据、并依据此数据初始化自己的应用。
• 简单来说，使用Spring Cloud Config就是将配置文件放到统一的位置管理(比如GitHub)，客户端通过接口去获取这些配置文件。
• 在GitHub上修改了某个配置文件，应用加载的就是修改后的配置文件。