SpringCloudDay4

1 Spring Cloud Stream

发送消息

首先在生产者和消费者端引入依赖：

消费者的yml配置

测试发送消息的启动类（生产者）

图解过程

Source.class的包如下

至此 消息发送成功

读取消息

配置 yml 可以看到destination的属性和生产者者是一样的

启动类：

在启动了消息接收者后 再发用生产者发送一条消息 消费者就可以看到消息了

发送消息和接收消息的提取

不会有人把发送的代码写在启动类中可以把发送的方法提取出来 需要的时候调用方法发送即可

测试类：

消费者代码的提取：

如何自己定义通道

使用自己的通道

生产者：
更改方法中的一些参数

更改yml的参数

消费者：
更改方法中的类

更改yml配置文件

1.5 消息分组

就是在同一个group中的多个消费者只有一个可以获取到消息并消费
通常在生产环境，我们的每个服务都不会以单节点的方式运行在生产环境，当同一个服务启动多个实例
的时候，这些实例都会绑定到同一个消息通道的目标主题（Topic）上。默认情况下，当生产者发出一
条消息到绑定通道上，这条消息会产生多个副本被每个消费者实例接收和处理，但是有些业务场景之
下，我们希望生产者产生的消息只被其中一个实例消费，这个时候我们需要为这些消费者设置消费组来
实现这样的功能。

如何做到： 修改消费者的yml配置

1.6 消息分区

有一些场景需要满足, 同一个特征的数据被同一个实例消费, 比如同一个id的传感器监测数据必须被同一
个实例统计计算分析, 否则可能无法获取全部的数据。又比如部分异步任务，首次请求启动task，二次
请求取消task，此场景就必须保证两次请求至同一实例.
没太懂运行规则 过后再补

2 SpringCloud Config

（2）创建项目config-repo
（3）上传配置文件，将product_service工程的application.yml改名为product-dev.yml后上传
文件命名规则：
{application}-{profile}.yml
{application}-{profile}.properties
application为应用名称 profile指的开发环境（用于区分开发环境，测试环境、生产环境等）

2.3.2 搭建服务端程序

创建一个子模块（拿来从gitee获取数据的模块）
1.引入依赖

2.创建启动类 并且添加@EnableConfigServer : 通过此注解开启注册中心服务端功能

编写yml配置

server:
  port: 10000 #服务端口
spring:
  application:
    name: config-server #指定服务名
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/x229827570/config-repo.git  #填写自己的gitee地址

拿到文件很简单 就访问127.0.0.1:8080/资源路径/资源名

项目怎么使用这个配置中心的文件
在需要引入配置的模块上添加 （微服务端）
（1）引入依赖

（2）创建一个比application.yml优先级更高的配置文件bootstrap.yml

对应文件如下

2.3.4 手动刷新

我们已经在客户端取到了配置中心的值，但当我们修改GitHub上面的值时，服务端（Config Server） 能实时获取最新的值，但客户端（Config Client）读的是缓存，无法实时获取最新值。SpringCloud已 经为我们解决了这个问题，那就是客户端使用post去触发refresh，获取最新数据，需要依赖springboot-starter-actuator
（1）引入依赖

（2）在需要的地方加上@RefreshScope 注解

（3）编写bootstrap.yml的配置

发送POST请求到 http://微服务ip:端口/项目目录/refresh 就可以实现手动刷新

2.4 配置中心的高可用

在之前的代码中，客户端都是直接调用配置中心的server端来获取配置文件信息。这样就存在了一个问 题，客户端和服务端的耦合性太高，如果server端要做集群，客户端只能通过原始的方式来路由， server端改变IP地址的时候，客户端也需要修改配置，不符合springcloud服务治理的理念。 springcloud提供了这样的解决方案，我们只需要将server端当做一个服务注册到eureka中，client端去 eureka中去获取配置中心server端的服务既可。
2.4.1 服务端改造
在从gitee上获取的项目上添加依赖
（1）引入依赖

（2） 配置文件
更改获取配置服务的application配置文件
把他注册到注册中心

server:
  port: 10000 #服务端口
spring:
  application:
    name: config-server #指定服务名
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/x229827570/config-repo.git  #填写自己的gitee地址
eureka:
  client:
    serviceUrl:
      defaultZone: http://127.0.0.1:8761/eureka/ # 注册中心地址
  instance:
    preferIpAddress: true
    instance-id: ${spring.cloud.client.ip-address}:${server.port} #使用ip注册

改造微服务端的配置
从注册中心中获取属性值 service-id的值是 gitee获取服务的spring.application.name的值

2.5 消息总线bus

（1） 在springCloud-config中引入依赖

（2）springCloud-config服务端配置

（3）微服务客户端配置
引入和springCloud-config中一样的依赖
在云端的对应的配置文件中 配置rabbitmq的信息

测试发送一个post请求 到config项目中 所有的信息都会被修改：

3 开源配置中心Apollo

3.1 Apollo概述

pollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群
的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
正是基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提
供了以下的特性：
统一管理不同环境、不同集群的配置
Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许
应用对共享的配置进行覆盖
配置修改实时生效（热发布）
用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
版本发布管理
所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
灰度发布
支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
权限管理、发布审核、操作审计
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
所有的操作都有审计日志，可以方便地追踪问题
客户端配置信息监控
可以在界面上方便地看到配置在被哪些实例使用
提供Java和.Net原生客户端
提供了Java和.Net的原生客户端，方便应用集成
支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
同时提供了Http接口，非Java和.Net应用也可以方便地使用
提供开放平台API
Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
部署简单
配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

3.2 Apollo的实现方式

上图简要描述了Apollo客户端的实现原理：

1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。这是一个fallback机制，为了防止推送机制失效导致配置不更新客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:apollo.refreshInterval 来覆盖，单位为分钟。
3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
5. 应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

3.3 搭建Apollo服务端

安装方法:https://github.com/apolloconfig/apollo-build-scripts
微服务端使用方法
（1）引入依赖

（2）修改客户端配置文件

怎么使用apollo

进入配置中心


再测试值已经改变

他怎么知道是什么环境呢？是因为我们在启动的时候进行了配置