目录
1、微服务中心Eureka
1.1、CAP定理
1.2、Eureka简介
1.3、Eureka与Zookeeper对比
1.4、Eureka的自我保护机制
1.5、服务离线
2、OpenFeign与Ribbon
2.1、OpenFeign简介
2.2、Ribbon与OpenFeign
2.3、Gzip压缩设置
2.4、Ribbon负载均衡
2.4.1、系统结构
2.4.2、内置负载均衡策略
3、 Hystrix服务熔断与服务降级
3.1、Hystrix简介
3.2、fallbackMethod服务降级
3.3、Hystrix 高级属性配置
3.3.1、执行隔离策略
3.3.2、对比
3.3.3、修改策略
3.3.4、Dashboard监控仪表盘
3.3.5、 Turbine聚合监控--监控默认组集群
4、 微服务网关Zuul
4.1、简介。
5、分布式配置管理Spring Cloud Config
5.1、spring cloud config概述
1、微服务中心Eureka
1.1、CAP定理
CAP定理指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得
1.2、Eureka简介
Eureka就是一个专门用于服务发现的服务器，一些服务注册到该服务器，而另一些服务通过该服务器查找其所要调用执行的服务。可以充当服务发现服务器的组件很多，例如Zookeeper、Consul、Eureka等。
1.3、Eureka与Zookeeper对比
Eureka与Zookeeper对比 Eureka与Zookeeper都可以充当服务中心，那么它们有什么区别呢？它们的区别主要体现在对于CAP原则的支持的不同。
- Eureka：AP
- zk：CP
1.4、Eureka的自我保护机制
在短时间内若EurekaServer丢失较多微服务，即EurekaServer收到的心跳数量小于阈值，为了保证系统的可用性（AP），给那些由于网络抖动而被认为宕机的客户端“重新复活”的机会，Eureka会自动进入自我保护模式：服务列表只可读取、写入，不可执行删除操作。当EurekaServer收到的心跳数量恢复到阈值以上时，其会自动退出Self Preservation模式。
1.5、服务离线
服务离线，即某服务不能对外提供服务了。服务离线的原因有两种：服务下架与服务下线。这两种方案都是基于Actuator监控器实现的。
服务下架：将注册到Eureka Server中的Eureka Client从Server的注册表中移除，这样其实Client就无法发现该Client了。
服务下线：Client并没有从Eureka Server的注册表中移除（其它Client仍可发现该服务），而是通过修改服务的状态来到达其它Client无法调用的目的。
2、OpenFeign与Ribbon
2.1、OpenFeign简介
Feign，假装，伪装。
OpenFeign可以将提供者提供的Restful服务伪装为接口进行消费，消费者只需使用“feign接口 + 注解”的方式即可直接调用提供者提供的Restful服务，而无需再使用RestTemplate。
需要注意：
该伪装的Feign接口是由消费者调用，与提供者没有任何关系。
Feign仅是一个伪客户端，其不会对请求做任何处理。 Feign是通过注解的方式实现RESTful请求的。
2.2、Ribbon与OpenFeign
说到OpenFeign，不得不提的就是Ribbon。Ribbon是Netflix公司的一个开源的负载均衡项目，是一个客户端负载均衡器，运行在消费者端。 OpenFeign也是运行在消费者端的，使用Ribbon进行负载均衡，所以OpenFeign直接内置了Ribbon。即在导入OpenFeign依赖后，无需再专门导入Ribbon依赖了。
2.3、Gzip压缩设置
Feign支持对请求（Feign客户端向提供者的请求）和响应（Feign客户端向客户端浏览器的响应）进行Gzip压缩以提高通信效率。
在springboot-feign 工程的配置文件中直接添加如下内容：
2.4、Ribbon负载均衡
2.4.1、系统结构
2.4.2、内置负载均衡策略
Ribbon默认采用的是RoundRobinRule，即轮询策略。但通过修改消费者工程的配置文件，或修改消费者的启动类或JavaConfig类可以实现更换负载均衡策略的目的。
（1） RoundRobinRule 轮询策略。Ribbon默认采用的策略。若经过一轮轮询没有找到可用的provider，其最多轮询10轮。若最终还没有找到，则返回null。
（2） RandomRule 随机策略，从所有可用的provider中随机选择一个。
（3） RetryRule 重试策略。先按照RoundRobinRule策略获取provider，若获取失败，则在指定的时限内重试。默认的时限为500毫秒。
（4） BestAvailableRule 最可用策略。选择并发量最小的provider，即连接的消费者数量最少的provider。
（5） AvailabilityFilteringRule 可用过滤算法。该算法规则是：过滤掉处于熔断状态的provider与已经超过连接极限的provider，对剩余provider采用轮询策略。
（6） ZoneAvoidanceRule zone回避策略。根据provider所在zone及provider的可用性，对provider进行选择。
（7） WeightedResponseTimeRule “权重响应时间”策略。根据每个provider的平均响应时间计算其权重，响应时间越快权重越大，被选中的机率就越高。在刚启动时采用轮询策略。后面就会根据权重进行选择了。
3、 Hystrix服务熔断与服务降级
3.1、Hystrix简介
Spring Cloud是通过Hystrix来实现服务熔断与降级的.
Hystrix是一种开关装置，类似于熔断保险丝。在消费者端安装一个Hystrix熔断器，当Hystrix监控到某个服务发生故障后熔断器会开启，将此服务访问链路断开。不过Hystrix并不会将该服务的消费者阻塞，或向消费者抛出异常，而是向消费者返回一个符合预期的备选响应（FallBack）。通过Hystrix的熔断与降级功能，避免了服务雪崩的发生，同时也考虑到了用户体验。故Hystrix是系统的一种防御机制。
3.2、fallbackMethod服务降级
Hystrix对于服务降级的实现方式有两种：
fallbackMethod服务降级，fallbackFactory服务降级。
3.3、Hystrix 高级属性配置
3.3.1、执行隔离策略
执行隔离策略有两大作用：防止服务熔断，防止服务雪崩。
对某种依赖的请求数量进行限制的方式，称为执行隔离。
隔离请求的方式有两种类型：
线程隔离：Hystrix的默认隔离策略。系统会创建一个依赖线程池，为每个依赖请求分配一个独立的线程，而每个依赖所拥有的线程数量是有上限的。当对该依赖的调用请求数量达到上限后再有请求，则直接拒绝该请求，并对该请求做降级处理。所以对某依赖的并发量取决于为该依赖线程池所分配的线程数量。
信号量隔离：对依赖的调用所使用的线程仍为请求线程，即不会为依赖请求再新创建新的线程。但系统会为每种依赖分配一定数量的信号量，而每个依赖请求分配一个信号。当对该依赖的调用请求数量达到上限后再有请求，则直接拒绝该请求，并直接对该请求做降级处理。所以对某依赖的并发量取决于为该依赖所分配的信号量数量。
3.3.2、对比
线程是进程的一个执行体，其具有独立运行的特性，而信号量却不是，其仅仅是线程执行的条件。
线程隔离中请求线程与提供者调用线程不是同一个线程，而信号量隔离中请求线程与调用线程是同一个线程。
线程隔离的执行效率要高于信号量隔离的，因为线程隔离的执行体数量是信号量隔离的2倍。
线程隔离使每台主机处理请求的数量是有限制的，因为主机线程数量是有上限的。而信号量隔离不同，其没有上限，因为所谓信号量就是一个计数器，是一个数值，其不存在上限。
在服务器少而请求并发量大的情况下不建议使用线程隔离，否则可能会使系统对请求的并发能力下降。
线程隔离便于控制反馈给客户端的降级时间。
3.3.3、修改策略
若是在配置文件中，则可以通过以下设置修改：
hystrix.command.default.execution.isolation.strategy=thread
hystrix.command.default.execution.isolation.strategy=semaphore
3.3.4、Dashboard监控仪表盘
Hystrix Dashboard仪表盘用于以GUI的形式展示消费者的执行情况，包括其处理器方法与Service方法的调用执行情况，及熔断器CircuitBreaker的状态等。当然，这些显示出的数据都是在指定时间窗内的执行情况及状态信息
3.3.5、 Turbine聚合监控--监控默认组集群
4、 微服务网关Zuul
4.1、简介
网关是系统唯一对外的入口，介于客户端与服务器端之间，用于对请求进行鉴权、限流、路由、监控等功能。
Zuul主要提供了对请求的路由与过滤功能。
路由：将外部请求转发到具体的微服务实例上，是外部访问微服务的统一入口。
过滤：对请求的处理过程进行干预，对请求进行校验、鉴权等处理
5、分布式配置管理Spring Cloud Config
5.1、spring cloud config概述
Spring Cloud Config就是对微服务的配置文件进行统一管理的。其工作原理是，我们首先需要将各个微服务公共的配置信息推送到GitHub远程版本库。然后我们再定义一个Spring Cloud Config Server，其会连接上这个GitHub远程库。这样我们就可以定义Config版的Eureka Server、提供者与消费者了，它们都将作为Spring Cloud Config Client出现，它们都会通过连接Spring Cloud Config Server连接上GitHub上的远程库，以读取到指定配置文件中的内容。
相关产品： 百度：disconf， 阿里：diamand， zookeeper
6、调用链跟踪 Spring Cloud Sleuth + Zipkin
Sleuth ：收集日志
发送到MQ或者kafuka
zipkin ：为用户提供调用链路监控可视化UI界面
补充：
6、nacos
Nacos = 服务注册中心 + 配置中心 = Eureka + Spring Cloud Config + Spring Cloud Bus
7、 Seata分布式事务
7.1、简介
Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务（官网）。
7.2、Seata术语
（1） TC Transaction Coordinator，事务协调者。维护全局和分支事务的状态（记录全局和分支事务的执行结果），驱动全局事务提交或回滚。其是一个专门的服务器。
（2） TM Transaction Manager，事务管理器。定义全局事务的范围：开始全局事务、提交或回滚全局事务。它实际是全局事务的发起者。
（3） RM Resource Manager，资源管理器。管理分支事务处理的资源，与TC交谈（通信）以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。常见的DBMS在分布式系统中都是以RM的角色出现的。
7.3、分布式事务模式
Seata提供了AT、TCC、SAGA与XA事务模式。
7.3.1、XA模式
XA模式是一个典型的2PC，其执行原理如下：
1) TM向TC注册并开启一个全局事务。
2) 根据业务要求，各个RM会逐个向TC注册分支事务，然后TC会逐个向RM发出预执行指令。
3) 各个RM在接收到指令后会在进行本地事务预执行。
4) RM将预执行结果Report给TC。当然，这个结果可能是成功，也可能是失败。
5) TC在接收到各个RM的Report后TM会获取到汇总结果，根据汇总结果TM会向TC发出确认指令。
若所有结果都是成功响应，则向TC发送Global Commit指令。
只要有结果是失败响应，则向TC发送Global Rollback指令。
6) TC在接收到指令后再次向RM发送确认指令。
7.3.2、AT模式
AT模式是Seata默认的分布式事务模型，是由XA模式演变而来的，通过全局锁对XA模式中的一些问题进行了解决。
当所有RM执行完毕第二阶段的Global Commit后，AT模式能够自动以异步方式批量清理掉回滚日志，而XA模式不会清理，需要手动清理。
8、调用链跟踪 SkyWalking
启动类添加的注解
@SpringBootApplication
@SpringCloudApplication
@EnableEurekaServer：// 开启Eureka服务
@EnableFeignClients //开启Feign客户端
@EnableCircuitBreaker // 开启熔断器 Hystrix
@EnableHystrixDashboard // 开启Hystrix 仪表盘 Dashboard功能
@EnableTurbine //开启 Hystrix 仪表盘 Turbine 聚合功能
@EnableZuulProxy //开启zuul代理模式
注入类添加的常用注解
@LoadBalance ：// 注解，实例负载均衡
@FeignClient("***") // 指定当前为Feign客户端，参数为提供者的微服务名称
// 指定当前为Feign客户端，参数为提供者的微服务名称
// fallback用于指定当前Feign接口的服务降级类
@FeignClient(value = "aaa", fallback = DepartFallback.class)
// 指定该方法要使用服务降级。即当前处理器方法在运行过程中若发生异常，
// 无法给客户端正常响应时，就会调用fallbackMethod指定的方法
@HystrixCommand(fallbackMethod = "getHystrixHandler")
