第1章 服务发现(Eureka)

1.1 Eureka基础架构

服务注册中心(Eureka服务端)

服务提供者(Eureka客户端)

服务消费者(Eureka客户端)

服务注册中心可以看作是一种特殊的服务提供者, 高可用配置时相互注册.

某一服务的提供者可以是另一服务的消费者, 因此服务提供者和服务消费者没有本质区别.

1.2 服务治理机制(通信行为)

从服务提供者角度

• 服务注册(携带元数据信息的REST请求)

• 服务同步(服务清单同步, 注册到任一服务注册中心均可)

• 服务续约(心跳机制)

  心跳间隔时间

  服务失效时间

从服务消费者角度

• 获取服务(服务注册的那个REST请求的响应结果是服务清单列表吗?)

• 服务调用

  在获取服务清单后, 通过服务名可以获得具体的服务实例和实例的元数据信息. 通过这些信息, 服务消费者可以决定调用哪个实例.

• 服务下线

  Eureka客户端发送服务下线的REST请求, Eureka服务端在接收到服务下线的请求后, 将该服务的状态设置为下线, 然后广播给所有的Eureka客户端.

从服务注册中心角度

• 失效剔除

  由于内存溢出, 网络故障等原因, Eureka客户端非正常下线, 此时需要服务注册中心主动的把下线服务剔除. 默认60s将服务清单中超时(默认90s)没有续约的服务剔除.

• 自我保护

  在网络不稳定的情况下, 失效剔除机制会不合理地将Eureka客户端剔除, 造成误删除. 为了避免因网络而不是Eureka客户端下线而造成地超时, Eureka设计了自我保护机制.

  但自我保护机制也会造成误保护, 容易使得客户端拿到一些已经下线的服务提供者实例, 因此造成调用失败的情况, 因此需要客户端有容错机制, 例如, 请求重试, 断路器等.

  Eureka判断网络不稳定的方法: 在运行期间统计15 min内心跳失败的比例是否小于85%, 如果是则认为网络不稳定.

将REST请求看作是一次心跳, 无论是第几次, 都认为是第一次服务注册, 这样服务续约也可以认为是服务注册的一种, 但是会不会服务续约经过更复杂的特殊处理来加快速度. 默认情况下可以认为每一次心跳都会返回一个服务清单列表.

1.3 Eureka源码分析

1.4 配置详解

第2章 客户端负载均衡(Ribbon)

第3章 服务容错与服务降级(Hystrix)

第4章 API网关服务(Gateway)

第5章 分布式配置中心(Config)

分布式配置中心用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持.

服务端: 也称为分布式配置中心

• 连接配置仓库
• 为客户端提供配置信息
• 为客户端提供加密/解密信息

客户端: 各个微服务应用或基础设施

• 通过指定的配置中心来管理应用资源与业务相关的配置内容
• 启动的时候从配置中心获取和加载配置信息

Spring Cloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射, 不仅适用于Spring构建的应用程序, 也适用于在任何其它语言运行的应用程序中使用.

配置中心默认采用Git来存储配置信息, 也支持SVN仓库和本地文件系统的存储方式.

5.1 快速入门知识点

• 构建基于Git存储的分布式配置中心(服务端)
• 学习配置的详细规则
• 客户端指定所属的配置中心, 从中获取配置信息并绑定到代码中

构建分布式配置中心的四个步骤

1. 引入pom依赖

   <dependencies> 
       <dependency> 
           <groupId>org.springframework.cloud</groupId> 
           <artifactId>spring-cloud-config-server</artifactId>
       </dependency>
   
       <dependency> 
           <groupId>org.springframework.cloud</groupId> 
           <artifactId>spring-cloud-starter-eureka</artifactId>
       </dependency>
   </dependencies>

2. 主启动类中添加@EnableConfigServer注解, 开启Spring Cloud Config的服务端功能

3. 在Spring配置文件application.properties中添加配置服务的基本信息以及Git仓库的相关信息

   #git仓库位置
   spring.cloud.config.server.git.uri=
   #仓库路径下的相对搜索位置, 可以配置多个
   spring.cloud.config.server.git.searchPaths=
   # git仓库的用户名
   spring.cloud.config.server.git.username=
   # git仓库的密码
   spring.cloud.config.server.git.password=

4. 配置中心服务需要注册到服务注册中心(Eureka)中

   # 指定eureka的服务注册中心位置
   eureka.client.serviceUrl.defaultZone=

配置规则

客户端获取配置信息

1. 引入pom依赖

2. 创建bootstrap.properties配置文件, 在其中指定配置中心的地址

   bootstrap.properties是系统级的配置文件, 而application.properties是用户级的配置文件, bootstrap.properties的优先级更高, 优先加载

   # 对应配置规则中的{profile}
   spring.cloud.config.profile=
   # 对应配置规则中的{label}
   spring.cloud.config.label=
   # 对应配置规则中的{application}
   spring.cloud.config.name=
   #配置中心服务端的地址
   spring.cloud.config.uri=

   必须配置在bootstrap.properties文件中, 配置信息才能够被正确加载

3. 配置客户端到服务注册中心

   eureka.client.serviceUrl.defaultZone=
   
   # 开启通过服务(在注册中心的服务)来访问配置中心的功能
   spring.cloud.config.discovery.enabled=true
   # 指定配置中心服务在注册中心中登记的服务名
   spring.cloud.config.serviceId=

SpringBoot应用对于配置文件的加载顺序: 本应用jar包之外的配置文件加载优先于应用jar包内的配置内容, 通过bootstrap.properties的配置内容会使得客户端应用从配置中心获取的外部配置信息的优先级要高于本地的配置信息, 从而实现外部化配置.

执行流程

1. 微服务应用启动时, 根据bootstrap.properties中配置的应用名application, 环境名profile, 分支名label, 向配置中心获取配置信息
2. 配置中心根据自己维护的Git仓库信息和客户端传递过来的配置定位信息查找配置信息, 通过git clone命令将配置信息下载到配置中心的文件系统中
3. 服务端应用从Git本地仓库中加载配置文件, 然后将配置内容读取出来返回给客户端应用
4. 客户端获得外部配置信息进行加载, 覆盖本地本地配置信息, 实现外部化配置

配置中心通过git clone将配置信息保存到本地, 起到缓存的作用, 当Git远程仓库无法访问的时候, 依然可以从配置中心中取出缓存内容进行使用

5.2 注册到服务注册中心

5.3 失败快速响应和重试机制

5.4 动态刷新配置

目的: 客户端在获取配置信息之后, 若远程仓库中的配置信息发生改变, 客户端能够自动实时更新

测试过程

1. 引入pom依赖

   监控模块, 其中包含了/refresh端点的实现, 该端点将用于实现配置信息的重新获取和刷新

   <dependency> 
       <groupId>org.springframework.boot</groupId> 
       <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>

2. 启动客户端应用, 获取远程配置信息(第一次)

3. 修改远程的配置信息后, 再次获取远程配置信息(第二次: /refresh前), 发现并没有获得修改后的配置信息, 仍然和第一次获得的配置信息相同

4. 通过post请求发送到http://<host>:<port>/refresh, 得到返回结果, 其中包含哪些远程配置信息被更新

5. 再次获取远程配置信息(第三次: /refresh后), 获得修改后的配置信息, 实现动态刷新配置功能

第6章 消息总线(Bus)

消息总线是架构模式; 消息代理是中间件产品, 也称为消息中间件

消息路由的两种类型:

• 点对点模式
• 发布-订阅模式

Spring的事件驱动模型