diff --git a/spring-cloud/spring-cloud-config/README.md b/spring-cloud/spring-cloud-config/README.md index a987133..37642c1 100644 --- a/spring-cloud/spring-cloud-config/README.md +++ b/spring-cloud/spring-cloud-config/README.md @@ -1,36 +1,51 @@ -# spring-cloud-config +# Spring-Cloud-Config -## 目录
-一、config 简介
+ -## 一、config 简介 +## 一、Config 简介 -spring cloud config 分为服务端和客户端，服务端称为分布式配置中心，集中管理配置文件，客户端为各个业务单元，它们从配置中心获取相关配置，同时 config 还实现了配置热更新，在服务不停机的情况下刷新配置。 +Spring Cloud Config 分为服务端和客户端，服务端称为分布式配置中心，集中管理配置文件；客户端为各个业务单元，它们会从配置中心获取相关配置。同时 Config 还支持配置热更新，可以在服务不停机的情况下刷新配置。 ## 二、项目结构 -+ config-server: 配置中心； -+ config-client: 服务单元，可以从配置中心获取相关配置； -+ eureka: 注册中心。 ++ **config-server**：配置中心； ++ **config-client**：服务单元，可以从配置中心获取相关配置； ++ **eureka**：注册中心。
+## 三、配置中心 -## 三、config-server 配置中心的实现 +Config 配置中心的具体实现如下： -#### 3.1 导入依赖 +### 3.1 导入依赖 ```xml @@ -75,7 +90,9 @@ spring cloud config 分为服务端和客户端，服务端称为分布式配置 -#### 3.2 在启动类上添加@EnableDiscoveryClient和@EnableConfigServer 注解 +### 3.2 添加注解 + +在启动类上添加 @EnableDiscoveryClient 和 @EnableConfigServer 注解： ```java @SpringBootApplication @@ -92,7 +109,9 @@ public class ConfigServerApplication { -#### 3.3 指定注册中心地址,并配置git仓库地址的配置文件路径 +### 3.3 项目配置 + +Spring Cloud Config 支持从 Git 仓库中获取统一的配置文件，具体配置如下： ```yaml server: @@ -123,32 +142,35 @@ spring: label: master ``` -这里的 git 仓库就是本用例的仓库，是公开的仓库，所以不用配置用户名和密码，配置文件如下 +这里的 Git 仓库就是本用例的仓库，是公开的仓库，所以不用配置用户名和密码，配置文件如下： -- application.yml 为主配置； -- application-dev.yml 为开发环境配置。 +- **application.yml** ：为主配置； +- **application-dev.yml**：为开发环境配置。
+### 3.4 启动服务 -#### 3.4 启动eureka和config-server服务，访问 http://localhost:8020/application-dev.yml +启动 Eureka 和 Config-Server 服务，访问 http://localhost:8020/application-dev.yml , 此时界面如下：
-这里需要注意的拉取配置的时候，我们此时指定拉取的是 dev 配置，application.yml 实际 配置如下： + + +注意此时我们访问是 dev 分支，即开发环境配置，其实际的配置文件的内容如下：
-这说明在用配置中心拉取配置的时候，和我们在本地开发的时候是一致的，配置是互补的，即 dev 中的实际配置应该是主配置和 dev 配置的结合，且遵循同名属性精确优先的原则。 + + +可以看到访问页面的内容远多于实际内容，这说明配置中心自动进行了配置的合并，即 dev 中的实际配置应该是主配置和 dev 配置的结合，且遵循同名属性精确优先的原则，这和我们本地开发时的情况是一致的。 -#### 3.5 http请求地址和资源文件映射 +### 3.5 请求地址映射 -在本用例中如果我们想要直接访问主配置，用以下路径 http://localhost:8020/application.yml 是不行的，会得到错误页面。如果想要访问主配置,，可以用 http://localhost:8020/application-X.yml，其中可以是任意字符，原因是： - -请求地址和实际的配置文件应该遵循以下规则，application 为配置文件名，profile 为环境，label 为分支（如果不指定默认就是 master 分支）。 +在本用例中如果我们想要直接访问主配置，用 http://localhost:8020/application.yml 地址是不行的，会得到错误页面。如果想要访问主配置,，可以用 http://localhost:8020/application-X.yml ，其中 X 可以是任意字符，原因是请求地址和实际的配置文件应该遵循以下的映射规则： - /{application}/{profile}[/{label}] - /{application}-{profile}.yml @@ -156,15 +178,15 @@ spring: - /{application}-{profile}.properties - /{label}/{application}-{profile}.properties -访问主配置： +其中 application 为配置文件名，profile 为环境，label 为分支（如果不指定默认就是 master 分支）。从上面的规则中我们可以看出并不存在单独的 `/{application}` 访问路径，所以必须接上一个任意字符，示例如下：
-## 四、config-client 搭建 +## 四、Config 客户端 -#### 4.1 导入依赖 +### 4.1 导入依赖 ```xml @@ -210,15 +232,14 @@ spring: ``` -#### 4.2 新建 `bootstrap.yml`配置文件，指定注册中心地址和配置中心服务名,并在启动类上开启自动注册@EnableDiscoveryClient +### 4.2 bootstrap.yml -这里需要特别说明的是，在之前的所有项目中我们采用的配置文件都是 application.yml,但是这里**一定要采用 bootstrap.yml**。 +新建 `bootstrap.yml` 配置文件，指定注册中心地址和配置中心服务名,并在启动类上开启自动注册 @EnableDiscoveryClient。这里需要特别说明的是，在之前的所有项目中我们采用的配置文件都是 application.yml，但是这里一定要采用 **bootstrap.yml**。两者的区别如下： -假设我们的数据库配置是放在远程配置中心的，那么我们应该先去远程配置中心拉取配置，然后再去进行数据库的自动化配置，反之如果我们先进行了数据库的自动化配置，那么就会因为找不到 url 或驱动而抛出异常。 +- **bootstrap.yml**（ 或 bootstrap.properties）用来程序引导时执行，应用于更加早期配置信息读取，bootstrap.yml 先于 application.yml 加载。 +- **application.yml**（或 application.properties) 应用程序各个模块的配置信息。 -- bootstrap.yml（bootstrap.properties）用来程序引导时执行，应用于更加早期配置信息读取，bootstrap.yml 先于 application.yml 加载。 - -- application.yml（application.properties) 应用程序各个模块的配置信息。 +使用 bootstrap.yml 后 ，如果我们的数据库配置放在远程配置中心，那么程序会先去远程配置中心拉取配置，然后再进行数据库的自动化配置，反之如果不使用 bootstrap.yml，就会先进行数据库的自动化配置，此时会因为找不到 url 或驱动而抛出异常。 ```yaml server: @@ -260,7 +281,9 @@ public class ConfigClientApplication { ``` -#### 4.3 创建配置映射类用于测试 +### 4.3 配置映射类 + +创建配置映射类用于测试： ```java @Component @@ -296,13 +319,14 @@ public class ConfigController { } ``` -#### 4.4 依次启动eureka,config-server,config-client ，访问 http://localhost:8030/programmer +### 4.4 启动项目 -这里需要注意是在启动 eureka 和 config-server，要稍等一会在启动 config-client，这里是为了确保 config-server 已经将服务注册到 eureka，然后我们的 config-client 才能从 eureka 中获取配置中心的服务。 +依次启动 eureka，config-server，config-client 三个项目，访问 http://localhost:8030/programmer 。在启动 eureka 和 config-server 后，要稍等一会再启动 config-client，这里是为了确保 config-server 已经将服务注册到 Eureka，然后我们的 config-client 才能从 Eureka 中获取配置中心的服务：
-启动的时候可以从控制台看到如下拉取服务的信息： + +启动时可以从控制台上看到拉取配置的相关信息： ```shell Fetching config from server at : http://localhost:8020/ @@ -311,31 +335,29 @@ Located environment: name=config-client, profiles=[dev], label=master, version=5 -## 五、集成 spring-cloud-bus 实现配置热更新 +## 五、实现配置热更新 -#### 5.1 消息总线简介 +### 5.1 消息总线 -在微服务的架构中，我们通常想要构建一个共同的消息主题被所有微服务实例所监听，以便对所有微服务实例的管理和通知，这就是消息总线，spring cloud bus 就是消息总线的一种实现。 +在微服务的架构中，通常会构建一个可以被所有微服务实例所监听的消息主题，以便对所有微服务实例进行管理和通知，这就是消息总线，Spring Cloud Bus 就是消息总线的一种实现，我们可以使用它来实现配置的热更新。目前 Spring Cloud Bus 支持的消息中间件有 RabbitMQ 和 Kafka, 我们下面的整合采用的是 RabbitMQ。另外关于热更新只需要对配置客户端（config-client）做更改，不需要对 config-server 做改动。 -目前 spring cloud bus 支持的消息中间件有 RabbitMQ 和 kafka, 我们下面的整合采用的是 RrabbitMQ。 - -关于热更新只需要对配置客户端（config-client）做更改，不需要对（config-server）做改动。 - -#### 5.1 导入bus依赖 +### 5.2 导入依赖 ```xml org.springframework.cloud spring-cloud-starter-bus-amqp - + org.springframework.boot spring-boot-starter-actuator ``` -#### 5.2 修改bootstrap.yml 配置，开启总线配置，配置rabbitmq 和 开启热刷新[端点](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-boot/spring-boot-actuator) +### 5.3 修改 bootstrap.yml + +修改 bootstrap.yml 配置，开启总线配置，主要是配置 RabbitMQ 和 开启热刷新 [端点](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-boot/spring-boot-actuator) ： ```yml server: @@ -347,7 +369,8 @@ spring: config: discovery: enabled: true - # 这里我们指定的是服务名 如果配置中心有多个，且用同一个服务名，我们的客户端拉取配置的时候是负载均衡的,配置中心也就是高可用 + # 这里我们指定的是服务名 如果配置中心有多个，且用同一个服务名， + # 那么我们的客户端拉取配置时会自动负载均衡,此时配置中心也就同时实现了高可用 serviceId: config-server # 指定分支 label: master @@ -383,7 +406,9 @@ management: ``` -#### 5.3 用@RefreshScope指定需要热刷新的配置 +### 5.4 @RefreshScope + + 用 @RefreshScope 指定需要热刷新的配置： ```java @Component @@ -406,30 +431,33 @@ public class Programmer{ } ``` -#### 5.4 依次启动eureka，config-server, config-client 服务 +### 5.5 启动项目 -在 client 服务端启动时候，可以在控制台 看到 bus 自动创建了交换机、队列等 +依次启动 eureka，config-server，config-client 四个项目，在 config 服务端启动时候，可以在控制台 看到 Bus 自动创建了交换机、队列等组件： ``` Created new connection: rabbitConnectionFactory#496c6d94:22/SimpleConnection@185d85d2 [delegate=amqp://guest@127.0.0.1:5672/, localPort= 63713] o.s.amqp.rabbit.core.RabbitAdmin : Auto-declaring a non-durable, auto-delete, or exclusive Queue (springCloudBus.anonymous.iY4TIIi9TSe0bL-TWAMhWg) durable:false, auto-delete:true, exclusive:true. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost. ``` -也可以在 rabbitmq 管控台查看 +也可以在 RabbitMQ 管控台上查看：
+
-#### 5.6 直接在 git 上修改配置文件，然后用 `post` 触发热刷新端点 http://localhost:8030/actuator/bus-refresh ,即可看到配置已经热刷新 +### 5.6 测试热刷新 -注意： 这里的只能用 post 方式请求 ，可以用 postman 等测试软件 + 直接在 Git 上修改配置文件，然后用 `post` 请求触发热刷新端点 http://localhost:8030/actuator/bus-refresh ，即可看到配置已经热刷新。注意这里的只能用 post 方式请求 ，你可以用 Postman 等测试软件来发送：
-热刷新的过程在控制台有详细的打印，部分日志如下： + + +热刷新的过程在控制台上有详细的输出，部分日志如下： ```shell # 消息传播 diff --git a/spring-cloud/spring-cloud-eureka-cluster/README.md b/spring-cloud/spring-cloud-eureka-cluster/README.md index 46d3529..fb1e638 100644 --- a/spring-cloud/spring-cloud-eureka-cluster/README.md +++ b/spring-cloud/spring-cloud-eureka-cluster/README.md @@ -1,6 +1,22 @@ # Eureka 高可用注册中心的搭建 + + ## 一、项目结构 - **eureka-server** 为服务注册中心，负责服务的管理； @@ -8,11 +24,15 @@
+ + ## 二、三步搭建 Eureka 高可用注册中心 这里我们以单机伪集群的方式搭建，让三个单机注册中心互相注册，实现注册中心的高可用。配置示意图如下：
+ + ### 2.1 服务端依赖 ```xml @@ -27,6 +47,8 @@ 创建三份配置文件，分别代表不同注册中心的配置：
+ + application-01.yml: ```yaml @@ -154,6 +176,8 @@ public class EurekaClientApplication { 这里我们可以采用命令行方式指定配置，分别启动三个注册中心：
+ + ### 4.2 集群搭建成功的判定 这里需要注意的是仅仅 Status 中出现其他注册中心时，并不一定是搭建成功的，**一定是当注册中心的 DS Replicas 和 available replicas 中显示其余的注册中心时候，才代表搭建成功**。 @@ -161,12 +185,18 @@ public class EurekaClientApplication { 8010 注册中心：
+ + 8020 注册中心：
+ + 8030 注册中心：
+ + Status 下的每个注册中心都可以点击跳转到其监控页面，但其监控页面地址链接可能是动态变化的，主要情况如下： + 当 hostname 和 prefer-ip-address 都没有配置，则访问 `主机名:服务名:端口号`： diff --git a/spring-cloud/spring-cloud-eureka/README.md b/spring-cloud/spring-cloud-eureka/README.md index 5a9ccfa..ab0067d 100644 --- a/spring-cloud/spring-cloud-eureka/README.md +++ b/spring-cloud/spring-cloud-eureka/README.md @@ -1,6 +1,20 @@ # Eureka 服务的注册与发现 + + ## 一、Eureka 简介 Spring Cloud Eureka 使用 Netflix Eureka 来实现服务注册与发现，它既包含了服务端组件，也包含了客户端组件： @@ -18,6 +32,8 @@ Spring Cloud Eureka 使用 Netflix Eureka 来实现服务注册与发现，它
+ + ## 三、三步搭建 Eureka 服务注册中心 ### 3.1 服务端依赖 @@ -112,3 +128,5 @@ public class EurekaClientApplication { 进入注册中心控制台，查看服务注册情况：
+ + diff --git a/spring-cloud/spring-cloud-feign/README.md b/spring-cloud/spring-cloud-feign/README.md index b2f353b..b06f66e 100644 --- a/spring-cloud/spring-cloud-feign/README.md +++ b/spring-cloud/spring-cloud-feign/README.md @@ -1,6 +1,28 @@ # Spring-Cloud-Feign + + ## 一、Feign 简介 在上一个用例中，我们使用 Ribbon + RestTemplate 实现服务之间的远程调用，实际上每一个调用都是模板化的内容，所以 Spring Cloud Feign 在此基础上进行了进一步的封装。我们只需要定义一个接口并使用 Feign 注解的方式来进行配置，同时采用 springMvc 注解进行参数绑定就可以完成服务的调用。Feign 同时还内置实现了负载均衡、服务容错等功能。 @@ -19,9 +41,13 @@ + + ## 三、服务提供者的实现
+ + ### 3.1 定义服务 产品服务由 `ProductService` 提供，并通过 `ProducerController` 将服务暴露给外部调用： @@ -124,6 +150,8 @@ public class ProducerApplication { ## 四、服务消费者的实现
+ + ### 4.1 基本依赖 ```xml @@ -195,6 +223,8 @@ public interface ProductFeign {
+ + ### 4.4 Feign 客户端 继承公共接口，创建 CProductFeign， 用 @FeignClient 声明为 Feign 客户端： @@ -256,20 +286,30 @@ public class SellController { 启动一个Eureka服务、三个生产者服务（注意区分端口）、和一个消费者服务。Feign 的依赖中导入了 spring-cloud-starter-netflix-ribbon 依赖，并且在内部实现了基于 Ribbon 的客户端负载均衡，所以我们这里启动三个生产者服务来观察负载均衡的情况：
+ + **服务注册中心：**
+ + ### 5.2 验证负载均衡 访问 http://localhost:8080/sell/products 查看负载均衡的调用结果：
+ +
+ +
+ + ## 六、Feign 的服务容错 ### 6.1 开启容错配置 @@ -278,6 +318,8 @@ Feign 的依赖中默认导入了 Hystrix （熔断器）的相关依赖，我
+ + 在 application.yml 中开启 Hystrix ： ```yml @@ -381,3 +423,5 @@ public List queryAllProducts() { 测试结果：
+ + diff --git a/spring-cloud/spring-cloud-hystrix/README.md b/spring-cloud/spring-cloud-hystrix/README.md index 36583eb..20eaa8c 100644 --- a/spring-cloud/spring-cloud-hystrix/README.md +++ b/spring-cloud/spring-cloud-hystrix/README.md @@ -1,5 +1,25 @@ # Spring-Cloud-Hystrix-Turbine + ## 一、简介 @@ -18,6 +38,7 @@ - 当熔断器处于打开状态的一段时间后，熔断器处于半打开状态，这时候一定数量的请求回去调用实际的服务，如果调用成功，则代表服务可用了，熔断器关闭；如果还是失败，则代表服务还是不可用，熔断器继续打开。
+ ## 二、项目结构 [spring-cloud-ribbon](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-cloud/spring-cloud-ribbon) 用例已经实现通过 Ribbon + RestTemplate 实现服务间的调用，本用例在其基础上进行 Hystrix 的整合： @@ -30,6 +51,7 @@
+ ## 三、整合 Hystrix 这里以 consumer 模块为例，说明其整合步骤： @@ -151,6 +173,7 @@ public List queryAllProducts() { 启动服务，访问 http://localhost:8030/sell/products ，多次刷新查看熔断情况：
+ ### 3.7 控制台 启动服务后，可以访问 localhost:8030/hystrix ，依次输出 http://localhost:8030/actuator/hystrix.stream（监控地址） ，2000（延迟时间），title 可以任意填写，进入Hystrix 监控台。 @@ -160,21 +183,25 @@ public List queryAllProducts() { **登录页面**：
+ **监控页面**：
+ **关于各个参数的说明参见[官方 wiki](https://github.com/Netflix-Skunkworks/hystrix-dashboard/wiki) 提供的图**：
+ ## 四、聚合监控 如果你想要聚合监控不同服务单元下的多个断路器，可以使用 Turbine 来实现。单体监控和聚合监控的区别如下：
+ ### 4.1 导入依赖 创建 Turbine 模块，导入以下依赖： @@ -285,9 +312,11 @@ public class TurbineApplication { 依次启动 eureka、producer、consumer、turbine 四个项目，因为 consumer 和 producer 都集成了 Hystrix ，所以可以在 localhost:8020/hystrix 或者 8030/hystrix 页面输入 http://localhost:8040/turbine.stream 来查看断路器聚合信息：
+ **显示了不同服务单元（consumer,producer）的多个断路器信息：**
+ ## 五、常见问题 在整合过程中可能出现的一些问题如下： @@ -326,3 +355,4 @@ public ServletRegistrationBean getServlet() { 这种情况是熔断器所在的方法没有被调用，所以没有产生监控数据，不是整合问题，这时候调用一下熔断器所在方法即可：
+ diff --git a/spring-cloud/spring-cloud-ribbon/README.md b/spring-cloud/spring-cloud-ribbon/README.md index 20ecb0c..e7ed1e7 100644 --- a/spring-cloud/spring-cloud-ribbon/README.md +++ b/spring-cloud/spring-cloud-ribbon/README.md @@ -1,6 +1,28 @@ # Spring-Cloud-Ribbon + + ## 一、Ribbon 简介 Ribbon 是 Netfix 公司开源的负载均衡组件，采用服务端负载均衡的方式，即消费者客户端维护可用的服务列表，并通过负载均衡的方式将请求按照指定的策略分摊给消费者，从而达到负载均衡的方式。 @@ -15,6 +37,8 @@ Ribbon 是 Netfix 公司开源的负载均衡组件，采用服务端负载均 + **eureka**：注册中心，Ribbon 从注册中心获取可用的服务列表，是实现负载均衡的基础。这里使用我们在 [服务的注册与发现](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-cloud/spring-cloud-eureka) 这个用例中搭建的注册中心即可。
+ + ## 三、服务提供者的实现 ### 3.1 定义服务 @@ -22,6 +46,8 @@ Ribbon 是 Netfix 公司开源的负载均衡组件，采用服务端负载均 产品服务由 `ProductService` 提供，并通过 `ProducerController` 将服务暴露给外部调用：
+ + ProductService.java： ```java @@ -125,6 +151,8 @@ public class ProducerApplication { ## 四、服务消费者的实现
+ + ### 4.1 基本依赖 ```xml @@ -225,15 +253,23 @@ public class ProductService implements IProductService { 启动一个Eureka服务、三个生产者服务（注意区分端口）、和一个消费者服务：
+ + **服务注册中心：**
+ + ### 5.2 验证负载均衡 访问 http://localhost:8080/sell/products 查看负载均衡的调用结果：
+ +
+ + ## 六、RestTemplate ### 6.1 RestTemplate 规范 diff --git a/spring-cloud/spring-cloud-sleuth-zipkin/README.md b/spring-cloud/spring-cloud-sleuth-zipkin/README.md index 14ce448..97c33d5 100644 --- a/spring-cloud/spring-cloud-sleuth-zipkin/README.md +++ b/spring-cloud/spring-cloud-sleuth-zipkin/README.md @@ -1,45 +1,43 @@ -# spring-sleuth-zipkin +# Spring-Sleuth-Zipkin -## 目录
+ ## 一、简介 -在微服务架构中，几乎每一个前端的请求都会经过多个服务单元协调来提供服务，形成复杂的服务调用链路。当服务发生问题时候，很难知道问题来源于链路的哪一个环节，这时候就需要进行链路追踪。 - -zipkin 是一个开源的分布式跟踪系统，可以使用 spring cloud sleuth 来轻松的集成 zipkin。 +在微服务架构中，几乎每一个前端的请求都会经过多个服务单元来协调提供服务，从而形成复杂的调用链路。此时如果服务发生问题，我们就很难知道其具体发生在哪一个环节，想要解决这个问题，可以使用链路追踪技术。Zipkin 是一个开源的分布式跟踪系统，Spring 支持使用 Spring Cloud Sleuth 来轻松地集成 Zipkin。 ## 二、项目结构 -这里的项目是在之前的 [spring-cloud-zuul](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-cloud/spring-cloud-zuul) 进行集成，zuul 项目的产品接口调用链路从 网关 -> consumer -> producer,历经三个环节的调用链路可以直观展示 zipkin 对链路追踪可视化的好处。 +这里的项目是在之前的 [spring-cloud-zuul](https://github.com/heibaiying/spring-samples-for-all/tree/master/spring-cloud/spring-cloud-zuul) 上进行集成，该项目产品接口的调用链路为： 网关 -> consumer -> producer ，整个过程历经三个环节的调用，因此可以直观展示 Zipkin 链路追踪的效果。 -+ common: 公共的接口和实体类； -+ consumer: 服务的消费者，采用 feign 调用产品服务； -+ producer：服务的提供者； -+ eureka: 注册中心； -+ zuul: api 网关。 ++ **common**：公共的接口和实体类； ++ **consumer**：服务的消费者，采用 Feign 调用产品服务； ++ **producer**：服务的提供者； ++ **eureka**：注册中心； ++ **zuul**： API 网关。
-## 三、构建 zipkin 服务端 -zipkin 客户端可以不用自己构建，直接从[官网](https://zipkin.io/pages/quickstart) 上下载对应的 jar 包启动即可，默认端口 9411 +## 三、Zipkin 服务端 + +zipkin 服务端可以不用自己构建，直接从 [官网](https://zipkin.io/pages/quickstart) 上下载对应的 JAR 包即可，启动命令如下。默认端口为 9411： ```shell java -jar zipkin.jar ``` -可以直接从 docker 仓库拉取，然后启动容器： +也可以直接从 Docker 仓库拉取镜像，然后进行启动： ```shell docker run -d -p 9411:9411 openzipkin/zipkin @@ -51,11 +49,14 @@ docker run -d -p 9411:9411 openzipkin/zipkin -## 四、集成zipkin -这里我们对 zuul、consumer、producer 三个模块都进行集成 +## 四、Zipkin 的集成 -#### 4.1 对三个模块(zuul、consumer、producer )添加依赖 +这里我们对 zuul、consumer、producer 三个模块都进行集成： + +### 4.1 添加依赖 + +对三个模块 (zuul、consumer、producer ) 添加 Zipkin 依赖： ```xml @@ -65,7 +66,9 @@ docker run -d -p 9411:9411 openzipkin/zipkin ``` -#### 4.2 分别在三个模块的application.yml 配置文件中指定zipkin的地址 +### 4.2 连接到服务端 + +分别在三个模块的 application.yml 配置文件中指定 zipkin 的服务地址 ： ```yaml spring: @@ -81,24 +84,21 @@ spring: ## 五、启动项目 -分别启动，eureka，zuul，consumer，producer，zuul ，访问 http://localhost:9411/ ，查看我们的服务调用链路 +分别启动 eureka，zuul，consumer，producer 四个项目，访问 http://localhost:9411/ ，查看我们的服务调用链路：
-点击链路，则可以查看具体的调用情况 + +点击链路，即可以查看具体的调用情况：
+ 展示信息说明： -Span ： 基本工作单元，发送一个远程调度任务就会产生一个 Span。 +- **Span**：基本工作单元，发送一个远程调度任务就会产生一个 Span。 +- **Trace**：由一系列 Span 组成的，呈树状结构。 所有由这个请求产生的 Span 组成了对应的 Trace 。 +- **SpanId**：工作单元 ( Span ) 的唯一标识。 +- **TraceId**：一条请求链路 ( Trace ) 的唯一标识。 -Trace：由一系列 Span 组成的，呈树状结构。 所有由这个请求产生的 Span 组成了这个 Trace 。 - -SpanId ; 工作单元 (Span) 的唯一标识。 - -TraceId : 一条请求链路 (Trace) 的唯 一 标识。 - -除了 TraceID 外，还需要 SpanID 用于记录调用父子关系。每个服务会记录下 parent id 和 span id，通过他们可以组织一次完整调用链的父子关系。 - -注：关于以上概念可以比对链表的实现原理来理解。 +除了 TraceID 外，还需要 SpanID 用于记录调用的父子关系。每个服务会记录下 parent id 和 span id，通过他们可以组成一条完整调用链，可以对比链表的实现原理来理解。 diff --git a/spring-cloud/spring-cloud-zuul/README.md b/spring-cloud/spring-cloud-zuul/README.md index 5e72e71..0583aeb 100644 --- a/spring-cloud/spring-cloud-zuul/README.md +++ b/spring-cloud/spring-cloud-zuul/README.md @@ -1,6 +1,24 @@ # Spring-Cloud-Zuul + + ## 一、简介 ### 1.1 API 网关 @@ -8,6 +26,8 @@ API 网关是整个微服务系统的门面，所有的外部访问需要通过网关进行调度和过滤。它实现了请求转发、负载均衡、校验过滤、错误熔断、服务聚合等功能：
+ + ### 1.2 Spring Cloud Zuul Spring Cloud 基于 Net Flix Zuul 实现了网关组件，这就是 Spring Cloud Zuul。它除了实现负载均衡、错误熔断、路由转发等功能，还能与 Spring 的其他组件无缝配合使用。 @@ -27,10 +47,14 @@ Spring Cloud 基于 Net Flix Zuul 实现了网关组件，这就是 Spring Cloud 聚合项目目录如下：
+ + Zuul 项目目录如下：
+ + ## 三、Zuul 网关 ### 3.1 引入依赖 @@ -159,6 +183,8 @@ zuul:
+ + ## 四、错误熔断 ### 4.1 默认依赖 @@ -166,6 +192,8 @@ zuul: Zuul 默认整合了 Hystrix ，不用导入其他额外依赖：
+ + ### 4.2 服务降级 创建 CustomZuulFallbackProvider 并实现 FallbackProvider 接口，同时用 @Component 声明为 Spring 组件，即可实现熔断时候的回退服务： @@ -245,6 +273,8 @@ public class CustomZuulFallbackProvider implements FallbackProvider {
+ + ## 五、Zuul 过滤器 创建自定义过滤器继承自 CustomZuulFilter，当我们访问网关的时候，如果判断 Session 中没有对应的 code，则跳转到我们自定义的登录页面： @@ -332,15 +362,25 @@ public class CustomZuulFilter extends ZuulFilter { Zuul 默认集成了 Ribbon 并实现了负载均衡，只要启动多个实例即可查看到负载均衡的效果：
+ + **这里我们直接在idea 中启动多个实例来测试：**
+ + **负载均衡测试结果：**
+ +
+ +
+ + ## 七、常见异常 如果出现以下错误导致启动失败，是 Spring Boot 版本不兼容导致的错误，Finchley SR2 版本的 Zuul 组件和 Spring Boot 2.1.x 存在不兼容的情况。如果出现这个问题，则将 Spring Boot 版本降至 2.0.x 即可，本用例中采用的是 2.0.8 。