微服务技术体系

 第一章 Spring Cloud Netflix

第一节 微服务简介

1、什么是微服务？

        微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的REST FUL API进行通信协作。

        拆分后的每一个小型服务都专注于完成系统中的某一项业务功能，职责单一，并且每个服务都是一个独立的项目，可以进行独立的测试、开发和部署。

        由于各个独立的服务之间使用的是基于HTTP的JSON作为数据通信协作的基础，所以实现微服务架构间的不同模块功能也可以使用不同的语言来开发。

参考：Microservices

如图所示：

​​​​​

2、分布式和微服务的区别？

        分布式和微服务都是将一个系统拆分成多个模块并且部署到不同的服务器上，一台服务器可能承受不了这么大的访问压力，或者需要采购一台支撑性能优越的大压力访问服务器，成本相对较高。

        分布式系统各个模块之间是通过接口进行数据交互，从这个意义上来说分布式也是一种微服务架构的体现，因为都是把模块拆分成独立的单元，提供接口来进行调用。

        它们的本质区别体现在“目标”上，何为目标？就是采用分布式架构或者采用微服务架构，最终为了什么，要达到什么样的目的？分布式系统架构的“目标”是一台服务器无法承受较大访问量导致的服务器压力，采购服务器的成本较高，不得不将系统拆分成多个独立的功能单元来进行多台服务器的部署工作；微服务系统架构的“目标”是将系统根据不同的功能拆分成不同的功能单元，降低系统间的耦合度，使之不会被相互影响，微服务可以在同一台服务器上进行部署。

3、微服务和Spring Cloud的关和区别？

        微服务只是一种项目的架构方式、架构理念或者说是一种概念，而Spring Cloud是对微服务架构的技术实现方式。

4、微服务的实现一定是基于Spring Cloud吗？

      微服务只是一种项目的架构方式、架构理念，任何技术都可以实现这种架构理念，只是微服务架构有很多问题需要我们去解决，比如：负载均衡、服务的注册与发现，服务调用，服务路由，服务熔断等等一些列的问题，而Spring Cloud将这些问题的技术打包起来，提供了一整套解决上述问题的方案，使我们可以很轻松的实现开发一套基于微服务架构设计理念的软件系统。

第二节 Spring Cloud概述

1、什么是Spring Cloud？

        springcloud为开发人员提供了一些工具来快速构建分布式系统中的一些常见模式和解决一些常见的问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）。 

        分布式系统的协调会生成很多样板式的代码，使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地工作，包括开发人员自己的笔记本电脑、裸机数据中心和CloudFoundry等托管平台。 

参考：Spring Cloud 

原文：

​​​​

​

 版本信息：

​​​​

​

2、Spring Cloud的特性：

      Spring Cloud专注于为典型的用例和可扩展性机制提供良好的开箱即用体验。

• 分布式/版本化配置
• 服务注册和发现
• 路由
• 服务到服务的通话
• 负载均衡
• 断路器
• 全局锁
• 领导选举和集群状态
• 分布式消息传递

3、Spring Cloud下的主要项目：

• Spring Cloud Config 
• Spring Cloud Netfix
• Spring Cloud Bus 
• Spring Cloud Cloudfoundry
• Spring Cloud Open Service Broker
• Spring Cloud Cluster 
• Spring Cloud Consul
• Spring Cloud Securtity
• Spring Cloud Sleuth
• Spring Cloud Data Flow
• Spring Cloud Stream
• Spring Cloud Stream App Starters
• Spring Cloud Task
• Spring Cloud Task App Starters
• Spring Cloud Zookeeper
• Spring Cloud AWS
• Spring Cloud Connectors
• Spring Cloud Starters
• Spring Cloud CLI
• Spring Cloud Contract
• Spring Cloud Gateway
• Spring Cloud OpenFeign
• Spring Clous Pipelines
• Spring Cloud Function

4、Spring Cloud的版本介绍

        Spring Cloud是由一系列独立的项目组成的，每个独立的项目具有不同的发布节奏，每次Spring Cloud发布版本时，就会组合这一系列的子项目，为了避免大家对版本号的误解，同时也为了避免跟子项目混淆，Spring Cloud发布的版本时是按照伦敦地铁站字母的顺序（A-Z）进行发布的，当Spring Cloud的某些子项目出现关键性BUG或者有重大更新的时候，则发布序列将推出名称以“.SRX”结尾的版本，其中“X”是一个数字（例：Hoxton.SR10）。

5、Spring Cloud与Spring Boot的兼容版本：

 1）、大版本对应

Spring Cloud 版本	Spring Boot 版本
Hoxton	兼容Spring Boot 2.2.X版本
Greenwich	兼容Spring Boot 2.1.X版本
Finchley	兼容Spring Boot 2.0.X版本,不兼容1.5.X
Dalston、Edgware	兼容Spring Boot 1.5.X版本,不兼容2.0.X
Camden	兼容Spring Boot 1.4.X版本,也兼容1.5.X
Brixton	兼容Spring Boot 1.3.X版本,也兼容1.4.X
Angel	兼容Spring Boot 1.2.X版本

 2）、开发过程中详细版本对应部分列举

Spring Cloud	Spring Boot
Dalston.RC1	1.5.2.RELEASE
Edgware.RELEASE	1.5.9.RELEASE
Finchley.BUILD-SNAPSHOT	2.0.2.RELEASE
Finchley.RELEASE	2.0.3.RELEASE
Greenwich.SR5	2.1.0.RELEASE-2.1.14.RELEASE
Hoxton.SR4	2.2.0.M4

 3）、SpringCloud和各子项目版本对应关系：

​​​​

​

第三节 Spring Cloud Eureka

1、Spring Cloud整体架构示意图

​​​​

​

2、服务的注册与发现

 Spring Cloud 提供了多种服务注册与发现的实现方式：Eureka、 Consul、Zookpeer。

1）什么是服务注册？

        服务注册就是将服务所在的主机、端口、版本号、通信协议等一系列信息登记道Spring Cloud提供的服务注册中心进行统一的管理。

2）什么是服务发现？

        服务发现就是服务消费者通过向服务注册中心请求已登记的服务列表，然后得到某个服务的主机、端口、版本号、通信协议等信息，从而实现对某一个具体的服务进行调用。

3、Eureka是什么？

        Eureka是NetFlx的子模块之一，也是一个核心的模块，Eureka采用了C-S(客户端/服务端)的设计架构，也就是Eureka由两个组件组成：Eureka服务端和Eureka客户端。Eureka Server用于注册服务以及实现服务的负载均衡和故障转移，它是服务的注册中心；

        Eureka Client它是用于与Eurek Server交互，获取注册中心已经登记的服务列表，使得交互变得非常简单，只需要通过服务标识即可拿到服务。

4、Eureka与Spring Cloud的关系

​​​​

​

5、建与配置Eureka服务注册中心

 1）创建一个Spring Boot项目（例如：eureka-service）;

 2）添加Eureka依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    <version>2.1.5.RELEASE</version>
</dependency>

3）在Spring Boot的入口类上添加@EnableEurekaServer注解，用于开启Eureka注册中心服务端，如图：

​​​​

​

4）配置Eureka服务注册中心信息（application.properties）:

​​​​

​

 5）启动项目，验证Eureka服务注册中心是否部署成功？

​​​​

​

6、Eureka服务注册

1）添加Eureka客户端依赖：

​​​​

​

 2）添加Eureka客户端配置信息：

​​​​

​

3）在启动类添加@EnableEurekaClient注解激活Eureka客户端功能：

​​​​

​

4）Eureka的服务发现由Eureka客户端实现，而服务的真正调用由Ribbon实现，所以我们需要在调用服务提供者时使用Ribbon来调用：

​​​​

​

注：因为加入Ribbon支持，调用时就可以使用Eureka服务注册中心注册的服务名称来进行访问，图：

​​​​

​

 5）验证服务注册是否成功？

​​​​

​

7、Eureka服务的发现与消费

        Eureka服务注册中心已经搭建完成，同时也向服务注册中心注册了服务，那么接下来我们就可以发现和消费服务了，Eureka的服务发现是由Eureka的客户端来来实现的，而服务消费是有Ribbon来实现的，也就是说Eureka的服务和发现需要客户端和Ribbon结合来共同实现。

        Eureka客户端是一个由Java代码编写的客户端服务，用来链接Eureka服务注册中心与服务端进行交互、实现负载均衡、服务故障切换等功能。

        Ribbon是一个基于HTTP和TCP的胡苦短负载均衡器，当使用Ribbon对服务进行访问时，它会扩展Eureka客户端的服务发现功能，实现从Eureka注册中心获取服务列表，并通过Eureka客户端来确定服务是否已经启动。

        Ribbon在Eureka客户端服务发现的基础上，实现了对服务端实例的选择策略，从而实现对服务的负载均衡消费。

 8、Eureka和Zookpeer的比较：

        著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）和P（分区容错性，即短暂的网络波动导致的服务终端）。

        由于分区容错性在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡，在此Zookeeper保证的是CP，而Eureka保证的则是AP。

9、Zookeeper如何保证CP？

        在Zookeeper中，当Master节点因为网络故障与其他节点失去联系时，剩余的节点会重新进行Leader的选举，但问题在于，选举Leader需要一定的时间且选举期间整个Zookeeper集群是不可用的，这就导致了选举期间注册服务瘫痪，在云部署的环境下，因网络故障导致Zookeeper集群失去master节点是大概率事件，虽然服务最终能够恢复，但是在选举期间内导致服务注册长期不可用是难以容忍的。

10、Eureka如何保证AP?

        Eureka首先保证可用性，Eureka各个节点是平等的，某几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现链接失败，则会自动切换至其他节点，只要有一台Eureka服务端还在正常运行就能保证注册服务的可用（保证可用性），只不过查到的信息可能不是最新的（不保证数据的强一致性）。

11、Eureka注册中心高可用集群

        在微服务架构的这种分布式系统中，我们要充分考虑微服务架构的高可用性问题，不能有单点故障，由于注册中心Eureka本身也是一个服务，如果它只有一个节点，那么它有可能发生故障，这样就会导致不能注册和服务发现，所以我们要通过建立微服务集群的方式来解决这个问题。 

        Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就会形成一组互相注册的服务注册中心，进而实现服务清单的互相同步，往注册中心A上注册的服务可以被复制同步到注册中心B上，所以从任何一台注册中心上都能查到已经注册的服务，从而达到高可用的效果。

        高可用集群如图所示：

​​​​

12、Eureka高可用集群搭建（基于windows的集群环境的搭建）

1）在Eureka服务端项目中复制多份application.properties模拟集群搭建环境配置，如图：

​​​​

 2）修改C:\Windows\System32\drivers\etc\hosts文件

​​​​

3）修改配置文件，将自己分别注册进其他的服务注册中心：

​​​​

​​​​

​​​​

13、Eureka服务注册中心的自我保护机制

1）概述：

        在Eureka没有自我保护的情况下，如果Eureka Server在一定的时间内没有接收到某个服务实例的心跳，Eureka Server将会注销该实例，但是当网络发生分区故障时，那么微服务与Eureka Server之间将无法正常通信，以上行为将变得非常危险，假设该服务本身是正常的，此时不应该被注销掉，如果没有自我保护机制，那么此时这个正常的服务就会被注销，导致不能进行服务的注册和发现。

        Eureka通过“自我保护模式”来解决这个问题，当Eureka Server接待你在短时间内丢失过多的客户端时（可能发生了网络分区故障），那么Eureka就会把这个服务节点保护起来，Eureka Server就会将该服务的服务注册列表中的消息保护起来，不删除服务注册表中的数据，也不会注销掉该服务，直到网络故障排除后，该节点将自动退出自我保护模式，使用自我保护模式，回事Eureka集群更加健壮、稳定。

 2）禁用自我保护模式：

​​​​

第四节 Spring Colud Ribbon

1、Ribbon是什么？

        Spring Cloud Ribbon是基于NetFlix Ribbon实现的一套客户端负载均衡器，主要共功能是提供客户端的软件负载均衡算法，它会从Eureka中获取一个可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。

        当客户端发送请求，Ribbon负载均衡器按某种算法（比如轮询、权重、最小链接数等），从维护的可用服务端清单中取出符合条件的服务端地址，然后发起请求；

2、什么是负载均衡？

        负载均衡是指将请求均匀的分摊到不同的服务器节点单元上执行，负载均衡分为硬件负载均衡和软件负载均衡（是基于服务器实现的）；

3、负载均衡分类：

        1）硬件负载均衡：比如F5、深信服、Array等；

        2）软件负载均衡：比如Nginx、LVS、HAProxy等；

4、Ribbon负载均衡策略：

        1）修改负载均衡策略：

​​​​

        2）负载均衡算法策略：

        如果系统中没有指定对应的负载均衡测路，则默认使用ZoneAvoidanceRule。

实现	策略
RandomRule	随机
RoundRobinRule	轮询
AvailabilityFilteringRule	先过滤掉由于多次访问故障的服务以及并发链接数超过阈值的服务，然后将剩下的服务按照轮询策略进行访问。
WeightedResponseTimeRule	根据平均相应时间计算所有服务的权重，相应时间越快服务权重就越大被选中的概率就越高，如果服务刚启动时统计信息不足，则使用轮询（RoundRobinRule）策略，待统计信息足够再自动切换回权重策略。
RetyRule	允许按照轮询（RoundRobinRule）策略分发，如果分发到的服务不能访问，则在指定时间内进行重试，然后再将请求分发到可用的服务。
BestAvailableRule	先将多次访问故障的服务过滤掉，然后将请求分发到一个并发量最小的服务上。
ZoneAvoidanceRule	综合判断服务所在区域的性能和可用性进行分发。

第五节 Spring Cloud Feign

1、什么是Feign？

        Feign是NetFlix公司开发的一个声明式的REST调用客户端（调用远程的RESTFul风格的HTTP接口的一个组件）；

        Spring Cloud Feign对Ribbon负载均衡进行了简化，在其基础上进行了进一步的封装，在配置上大大简化了开发工作，它是一种声明式的调用方式，它的使用方法是定义一个接口，然后在接口上添加注解，使其支持了Spring MVC标准注解和HttpMessageConverters，Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

2、接口的调用方式：

        1）HttpClient(apache);

        2）HttpUrlConnection(JDK)；

        3）RestTemplate(Spring);

        4）OkHttp(Android);

        5）Feign(NetFlix).

3、Feign的作用：

        Feign的主旨在于简化微服务消费方（调用者、客户端）的代码开发，在使用Ribbon+RestTemplate进行服务调用时，利用Rest Template对Http请求的封装处理，形成一套模板化的调用方式，但是在实际的开发中，由于服务提供者提供的接口可能非常多，然而一个接口也可能被多处调用，Feign在Ribbon + Rest Tempalte的基础上进一步封装，在Feign封装之后，我们只需要创建一个接口并使用注解的方式来配置，即可完成对服务提供方的接口绑定，简化了Spring Cloud Ribbon + RestTemplate的调用，自动封装服务调用客户端，减少代码开发。

 4、Feign消费者客户端的实现：

        1）创建一个Spring Boot工程；

        2）添加依赖：

​​​​

        3）创建Feign服务远程接口类并声明Feign服务：

​​​​

         4）开启Feign远程服务调用功能（在消费者的启动类）：

​​​​

        5）服务调用：

​​​​

第六节 Spring Cloud Hystrix 

1、什么是Hystrix？

        Hystrix被称为熔断器，它是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多服务之间通过远程调用实现信息交互，调用时不可避免会出现调用失败（比如超时、异常等），Hystrix能保证在一个服务问题的情况下，不会导致整个服务的瘫痪，避免级联故障的发生（例：服务雪崩），以提高分布式系统的高可用性。

        熔断器也叫断路器，“熔断器”的本身是一种开关装置，用于在电路上保护线路的过载，当线路中有电器发生短路时，能够及时切断故障的电路，防止发生过载，发热甚至起火等严重后果。所以当某个服务单元发生故障后，通过断路器的故障监控（类似熔断保险丝），向服务的调用方返回一个符合预期的、可处理的备选响应（FallBack，也称为服务降级处理），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间的占用，从而避免了故障在分布式系统中的蔓延，乃至服务雪崩。

        Spring Cloud Hystrix实现了熔断器、线程隔离等一系列的服务保护功能，该功能也是基于NetFlix的开源框架Hystrix实现的，该框架的目标在于通过控制那些访问远程系统、服务合格第三方库的节点，从而对延迟和故障提供更加强大的容错能力。

2、Hystrix的两大特性

1）熔断降级：

        服务降级是指当某个服务响应时间过长，发送异常，或者不可用时，我们不能直接将错误信息返回或者让服务一直卡在那里，我们要准备一个对应的策略来应对这种问题的发生，在发生了服务异常时，我们可以直接调用这个备用的方法快速的返回一个默认的结果，让请求得到快速的响应。

2）请求限流：

        请求限流就是限制某个为服务的使用量（可用线程数、信号量）；

        Hystrix通过线程池的方式来管理微服务的调用，它默认是一个线程池（大小10个）管理所有的微服务，但是可以给某个微服务开辟新的线程池。

3、Hystrix如何实现熔断降级？

1）添加依赖：

​​​

2）在启动类上添加注解开启断路器支持：

        @EnableCircuirBreaker或 @EnableHystrix 或 @SpringCloudApplication

​​​

3）远程方法调用：

​​​

4）如何修改Hystrix的默认超时时间？

a）配置方式：

​​​

b）代码方式：

​​​

4、Hystrix的异常处理

1）使用服务降级异常处理：

​​​

2）忽略异常信息：

​​​

5、服务降级的作用

1）监听请求是否超时（默认超时时间为1秒）；

2）侦听服务异常并作出相应的处理，然后快速的给请求调用方相应，避免服务雪崩；

3）当服务器面临高并发的场景时，关闭部分非核心服务，把资源优先提供给核心服务器使用，并使用降级方法给非核心服务给用户返回一个友好的提示。

6、服务请求限流的实现方案：

1）Nginx

2）Redis + Lua

3）Sentiel

4）基于限流算法自己实现（令牌桶、漏桶算法）。

7、Hystrix如何实现请求限流？

​​​

8、Feign整合Hystrix

1）概述：

        Feign默认是支持Hystrix的，但是在Spring Cloud Dalston版本之后就默认关闭了，因为不一定所有的业务需求都能用的到。

2）整合步骤：

a）开启服务降级支持：

​​​

b）在声明式的服务接口上加上服务降级处理：

​​​

​​​

 3）异常信息处理：

​​​

​​​

9、Hystrix相关配置:

1）[hystrix.command.default.excution.isolation.strategy]隔离策略，默认是Thread，可选 Thread | Semaphore(信号量)；

2）[hystrix.command.default.excution.isolation.thread.timeoutInMilliseconds]线程执行超时时间，默认1秒。

3）[hystrix.command.default.excution.timeout.enable]是否启用超时设置，默认为true.

4）[hystrix.command.default.excution.isolation.thread.interruptOnTimeout]发生超时是否终端线程，默认为true;

5）[hystrix.command.default.excution.isolation.semaphore.maxConcurrentRequests]最大并发请求数，默认为10；该参数使用【hystrix.command.default.excution.isolation.strategy= Semaphore】策略时才生效。如果达到最大并发请求数，请求就会被拒。理论上选择semaphore size的原则和选择thread size一致，但选用semaphore时每次执行单元要比较小且执行速度快，否则的话就应该使用thread。Semaphore应该占整个容器（Tomcat）的一小部分。

10、Hystrix的仪表盘监控

        Hystrix仪表盘（Hystrix Dashboard），就像汽车的仪表盘实时显示汽车的各项数据一样，Hystrix仪表盘主要用来监控Hystrix的运行状态，通过它我们可以看到Hystrix的各项指标信息，从而快速的发现系统中存在的问题进而解决它。

11、如何实现Hystrix Dashboard？

1）创建一个名为Dashboard的Maven Project；

​​​

2）导入依赖：

​​​

3）开启Hystrix Dashboard支持： 

​​​

12、如何使用Hystrix Dashboard对服务进行监控？

1）添加客户端依赖：

​​​

2）配置Spring Boot监控端点的权限：

​​​

3）仪表盘数据解读：

​​​

13、Turbine

1）创建一个名为turbine的Maven Project；

​​​

2）添加依赖：

​​​

3）配置Turbine设置：

​​​

 4）开启Turbine支持：

​​​

5）整合监控图示：

​​​

第七节 Spring Cloud Zuul

1、什么是Zuul？

        Zuul是netflix开源的一个API Gateway服务器,本质上是一个Web Servlet应用。

        Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

2、Zuul的主要功能：

1）请求路由：负责将外部的请求转发到具体的服务器实力上，是实现外部统一访问的入口基础；

2）请求过滤：负责对请求的处理进行干预，是实现请求校验、服务聚合等的基础。

3、如何实现路由功能？

1）导入依赖：

​​

 2）配置文件：

​​

​​

 3）开启网关路由支持：

​​

4、如何实现网关过滤器？

        过滤器（filter）是Zuul的核心组件。

        Zuul的过滤器之间没有直接的相互通信，他们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据。

        Zuul的过滤器是由Groovy写成，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用。

5、标准过滤器类型：

1）PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

2）ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。

3）POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

4）ERROR：在其他阶段发生错误时执行该过滤器。

6、过滤器的生命周期：

​​

 7、过滤器的简单实现：

1）创建一个过滤器类：LogFilter.java。

2）继承ZuulFiler并实现其子类：

​​

 8、Zuul过滤器禁用

​​

9、Zuul异常处理：

1）禁用Zuul默认的异常处理SendErrorFilter过滤器，自定义ExceptionFilter;

2）ExceptionFilter实现：

​​

10、Zuul的熔断：

​​

第八节 Spring Cloud Config

 1、什么是配置中心？

         传统配制方式：配置信息分散道系统的各个角落方式，配置文件或者在代码中；

         集中式配置中心：将应用系统中的配置信息作为一个新的应用模块进行集中统一的管理，并提供额外功能。

         分布式配置中心：在分布式、微服务架构中，独立的配置中心服务。

 2、为什么需要分布式的配置中心？

        在分布式微服务架构体系中，服务的数量以及配置信息日益增多，比如各种服务器参数配置，各种数据库访问参数配置，各种环境下配置信息的不同，配置信息修改之后的实时生效等等，传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求。

 3、传统配置的劣势：

         安全性：配置跟随源码保存在代码中，容易造成配置泄漏；

         时效性：配置修改需要重启服务才能生效；

         局限性：无法支持动态调整，例：日志开关、功能开关等。

 4、常见的分布式配置中心的框架：

 1）Apollo(阿波罗)：

        携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

 2）Diamond：

        淘宝开源的持久化配置中心，支持各种持久化信息（比如各种规则、数据库配置等）的发布和订阅（更新机制稍微落后一点）。

 3）Xdiamond：

        全局配置中心，存储应用的配置项，解决配置混乱分散的问题，名字来源于淘宝的开源项目Diamond，前面加上X以示区分。

 4）Qconf：

        奇虎360内部分布式配置管理工具，用来代替传统的配置文件，使得配置信息和程序代码分离，同时配置变化能够实时同步到客户端，而且保证用户高效读取配置，这使得工程师从琐碎的配置修改、代码提交、配置上线等流程中解放出来，极大的简化了配置管理工作。

 5）Disconf：

        百度的分布式配置管理平台，专注于各种分布式系统配置管理的通用组件和平台，提供统一的配置管理服务。

 6）Spring Cloud Config：

        Spring Cloud微服务开发配置中心，提供服务端和客户端支持；

 7）其他（国外）：

        Apache、Apache Commons 、Configuration、owner、cfg4j等。

 5、什么是Spring Cloud Config？

        Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。

        Spring Cloud使用Git或者SVN、也可以是本地存放配置文件，默认情况下使用Git。

 6、Spring Cloud Config的工作原理：

         1）首先需要建立一个远程的Git仓库，用于保存配置文件；

         2）新建一个本地仓库，当Config Server访问远程Git仓库时都会将远程Git服务器的配置文件拉取到本地仓库，就保证了远程服务器宕机时依然可以获取配置信息；

         3）微服务应用在启动时从Config Server获取对应的配置信息；

 当微服务应用从Config Server中加载配置信息的时候，Config Server都会先通过git clone命令克隆一份配置文件到本地仓库；

         4）Config Server中的配置文件具有版本管理的功能。

7、搭建Spring Cloud Config中心仓库：

1）注册Gitee账号

        参考官方文档：Gitee 帮助中心 - Gitee.com

2）在Gitee新建一个远程配置中心仓库：

​​

3）将配置文件提交到远程仓库：

​​

8、搭建Spring Cloud Config服务端：

1）创建一个名为CfgServer的Spring Boot项目；

2）添加依赖：

​​

3）开启配置中心服务支持：

​​

4）链接远程Gitee仓库获取配置文件信息：

​​

9、配置中心映射规则：

• /{application}/{profile}[/{label}]
• /{application}-{profile}.yml
• /{label}/{application}-{profile}.properties
• /{application}-{profile}.yml
• /{label}/{application}-{profile}.yml

10、Spring Cloud Config配置中心客户端实现：

1）添加依赖：

​​

2）创建bootstrap.properties文件，用于获取配置信息：

​​

11、bootstrap.properties文件的解释：

        Spring Cloud有一个“引导上下文”的概念，这是主应用程序的父上下文。引导上下文负责从配置服务器加载配置属性，以及解密外部配置文件的属性，和主应用程序加载application.(yml/properties/yaml)的属性不同，引导上下文加载bootstrap.properties中的属性。配置在bootstrap.*中的属性有更高的优先级，因此默认情况下他们不能被本地覆盖。

12、读取配置中心的数据：

1）通过@Value注解来获取：

​​

  2）通过org.springframework.core.env.Environment类来获取：

​​

13、配置中心数据加解密支持：

1）安装JCE（Java Cryptography Extension）：

https://www.oracle.com/java/technologies/javase-jce8-downloads.html

2）解压覆盖到JDK/jre/lib/security:

​​

3）对称加密：

Config Server提供了加密与解密的接口，分别是：

加密接口：http://localhost:9000/encrypt  

解密接口：http://localhost:9000/decrypt 

4）在Config Server项目中添加bootstrap.properties文件，配置密钥：

​​

5）实现加密：

​​

注：必须有{cipher}前缀告知配置中心该标记后面的字符串经过加密处理。

 14、配置局部刷新：

 1）局部刷新：

a）添加依赖：

​

 b）添加@RefreshScope注解：

​

 c）开启Web访问断点：

​

 d）手动刷新配置(POST访问)：

http://localhost:9000/actuator/refresh

​

 2）全局刷新：

 a）添加依赖：

​

 b）添加配置项：

​

 c）手动刷新RabbitMq（post）:

http://localhost:8082/actuator/bus-refresh

 15、什么是Spring Cloud Bus？

        Spring Cloud Bus使用轻量级的消息代理/消息总线（例如Rabbit MQ、Kafaka等）广播传播状态的更改（例如配置的更新）或者其他的管理指令，可以将Spring Cloud Bus想象成一个分布式的Spring Boot Actuator。

 16、Spring Cloud Config高可用

 1）什么是Spring Cloud Config高可用机制？

        有了配置配置中心之后，其他的微服务都是从配置中心获取配置信息，此时的配置中心就至关重要了，在项目生产环境中，Spring Cloud Config配置中心难免会出现各种问题，此时就需要考虑配置中心的高可用机制了。

        Spring Cloud Config的高可用机制解决方式非常简单，把Spring Cloud Config注册到Eureka就可以了，此时用户不再是直接从配置中心获取配置信息了，而实先通过Eureka服务注册中心获取配置中心的地址，然后再从配置中心拿到对应配置信息。

 2）实现步骤：

 a）添加Eureka依赖：

​

 b）注册配置中心服务到注册中心

​

 c）将配置中心打好的JAR包上传到Linux服务器的/usr/local/ConfigServer下

 d）编写Shell启动脚本：

​

 e）释放端口：

编辑/etc/sysconfig/iptables文件增加：

​

 f）重启防火墙配置：service iptables restart

g）启动CfgServer配置中心服务；

 h）在客户端增加对Eureka注册中心的配置：

​

 3）实现配置中心高可用的第二种方式，也可以使用Nginx。

 17、Spring Cloud Config安全认证

 1）添加依赖：

​

 2）配置账号密码（服务端/消费端）：

​

 3）测试验证：

​

 18、Spring Cloud Eureka安全认证

 1）添加依赖：

​

 2）配置账号密码（服务端/消费端）：

​

 3）重写EurekaSecurityConfig的configure方法：

​

 4）服务端使用用户名/密码验证链接：

​

 5）校验服务是否注册成功：

​

第九节 Spring Cloud Sleuth

 1、分布式链路跟踪概述：

        Spring Cloud Sleuth [sluːθ]为Spring Cloud提供了分布式跟踪的解决方案，他大量使用了Google Dapper、Twitter Zipkin和Apache Htrace的设计。

        Spring Cloud Sleuth可以追踪10种类型的组件，async、Hystrix、messaging、websocket、rxjava、scheduling、web(Spring MVC Controller，Servlet)、webclient(Spring RestTemplate)、Feign、Zuul。

 2、分布式链路跟踪解决的问题：

• 如何串联整个调用链路，快速定位问题？
• 如何清理各个微服务之间的依赖关系？
• 如何进行各个微服务接口的性能分析？
• 如何跟踪整个业务流程的调用处理顺序？

 3、Sleuth常用术语：

 1）Span(跨度)：

        工作的基本单位。例如，发送RPC是一个新的跨度，就像发送响应到RPC一样。Span是由一个唯一的64位ID来标识的，而另一个64位ID用于跟踪。span还具有其他数据，如描述、时间戳事件、键值标注(标记)、导致它们的span的ID和进程ID(通常是IP地址)。

        可以启动和停止跨度，并跟踪其时间信息。 创建跨度后，必须在将来的某个时刻停止它。

        启动跟踪的初始范围称为根跨度。 该范围的ID值等于跟踪ID。

 2）Trace（跟踪）：

        一组span形成树状结构。 例如，如果运行分布式大数据存储，则可能由PUT请求形成跟踪。

 3）Annotation：用来及时记录一个事件的存在。

•  cs - Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
• sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
• ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
• cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间 

 4、什么是ZipKin？

        ZipKin是Twitter开源的分布式实时数据跟踪系统（Distributed Tracking System），基于Google Dapper的论文设计而成，Google开源了Dapper数据追踪组件，并在2010年发表了论文《Dapper，a Large-Scale Distributed Systems Tracking Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。

        Zipkin的主要功能是收集系统的时序数据，从而追踪微服务架构的系统延时等问题，从而达到链路调用监控追踪作用，另外ZipKin还提供了一个非常友好的界面来帮助分析追踪数据。

        ZipKin官网地址：OpenZipkin · A distributed tracing system 。

 5、搭建ZipKin分布式链路跟踪服务端

 1）新建一个名为Microservice-zipkin的Spring Boot项目；

 2）添加依赖：

 3）配置文件：

 4）开启Zipkin服务支持：

 5）启动服务，访问ZipKin管理页面：

下节更精彩！！！

感谢各位看官龙年行大运，新春万事如意，心想事成，升职加薪，龙年旺旺旺！！！