CAP理论： Consistency 强一致性，Availability 可用性，Partition tolerance 分区容错性一个分布式系统最多只能同时满足两个。
 CAP理论核心：一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性的三个要求。
 因此，根据CAP理论将NoSQL数据库分成满足CA原则、满足CP原则和满足AP原则三大类：
 CA:单点集群，满足一致性，可用性的系统，在扩展性上不太强大
 CP:满足一致性，分区容忍性的系统，通常性能不高
 AP:满足可用性，分区容忍性的系统，通常对一致性要求较低

Nginx是服务器端负载均衡，客户端所有请求都会发到Ngin，然后由Ngnix实现请求转发，即负载均衡。

Ribbon本地负载均衡，在调用微服务接口时，会在注册中心上获取注册信息服务列表之后缓存到本地，从而在本地实现RPC远程服务调用

轮询算法：rest接口第几次请求数 % 服务器集群总数量=实际调用服务器位置下标，每次服务重启后rest接口计数从1开始。

Feign中包含了Ribbon，在此基础上进行改进，采用接口的方式来提供更加方便的HTTP请求

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

- 程序运行异常
- 服务请求超时
- 服务熔断会触发服务降级
- 线程池/信号量打满则会导致服务降级

@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod",
             commandProperties = {
                     @HystrixProperty(name = "circuitBreaker.enabled", value = "true"), // 是否开启熔断
                     @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), // 请求次数
                     @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "1000"), // 时间窗口
                     @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60") // 失败率到达多少进行熔断跳闸
             })
     public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
         if (id < 0) {
             throw new RuntimeException("******id 不能为负数");
         }
         String serialNumber = IdUtil.simpleUUID();  //UUID.randomUUID();
         return Thread.currentThread().getName() + "\t" + "调用成功，流水号：" + serialNumber;
     }
 
     public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id){
         return "id 不能负数，请稍后再试，o(╥﹏╥)o  id："+id;
     }

服务熔断的作用类似于我们家用的保险丝，当某服务出现访问量最大情况、不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

在DashBoard和服务提供给模块中添加以上依赖，修改服务模块中的主函数.