diff --git a/java/springcloud实战/2.springCloud服务发现.md b/java/springcloud实战/2.springCloud服务发现.md index 75bb537..041665d 100644 --- a/java/springcloud实战/2.springCloud服务发现.md +++ b/java/springcloud实战/2.springCloud服务发现.md @@ -2,13 +2,14 @@ id: "2018-11-22-15-57" date: "2018/11/22 15:57" title: "springCloud学习2(服务发现)" -tags: ["spring-boot", "spring-cloud","eureka"] -categories: -- "java" -- "springCloud实战" +tags: ["spring-boot", "spring-cloud", "eureka"] +categories: + - "java" + - "springCloud实战" --- -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2018-11-22-15-57) + +**springcloud 总集：**[https://www.tapme.top/blog/detail/2019-02-28-11-33](https://www.tapme.top/blog/detail/2019-02-28-11-33) 本篇代码存放于:[github](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0) @@ -449,5 +450,5 @@ public Licensing getLicensingByFeign(@PathVariable("orgId") String orgId) {   这一节磨磨蹭蹭写了好几天，虽然例子很简单，但是相信应该是能够看懂的。由于篇幅原因代码没有全部贴上，想要查看完整代码，可以访问这个链接：[点击跳转](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0)。 +**本篇原创发布于：**[http://tapme.top/blog/detail/2018-11-22-15-57](http://tapme.top/blog/detail/2018-11-22-15-57) -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2018-11-22-15-57) \ No newline at end of file diff --git a/java/springcloud实战/3.springCloud与Netflix Hystrix的弹性客户端模式.md b/java/springcloud实战/3.springCloud与Netflix Hystrix的弹性客户端模式.md index bfd9e26..1bdab07 100644 --- a/java/springcloud实战/3.springCloud与Netflix Hystrix的弹性客户端模式.md +++ b/java/springcloud实战/3.springCloud与Netflix Hystrix的弹性客户端模式.md @@ -8,9 +8,11 @@ categories: - "springCloud实战" --- -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2018-11-28-15-57-00) -本次用到全部代码：[点击跳转](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud%E5%BC%B9%E6%80%A7%E5%AE%A2%E6%88%B7%E7%AB%AF) +**springcloud 总集：**[https://www.tapme.top/blog/detail/2019-02-28-11-33](https://www.tapme.top/blog/detail/2019-02-28-11-33) + + +本次用到全部代码：[github](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud%E5%BC%B9%E6%80%A7%E5%AE%A2%E6%88%B7%E7%AB%AF) # 一、为什么要有客户端弹性模式 diff --git a/java/springcloud实战/4.springCloud之Zuul服务路由.md b/java/springcloud实战/4.springCloud之Zuul服务路由.md index 0d1ac23..be51d90 100644 --- a/java/springcloud实战/4.springCloud之Zuul服务路由.md +++ b/java/springcloud实战/4.springCloud之Zuul服务路由.md @@ -11,14 +11,17 @@ categories: 镇博图 ![三笠](https://raw.githubusercontent.com/FleyX/files/master/blogImg/springcloud%E5%AE%9E%E6%88%98/20190108162523.jpeg) -**本篇代码存放于:**[github](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud%E6%9C%8D%E5%8A%A1%E8%B7%AF%E7%94%B1) -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2019-01-03-19-19) +**springcloud 总集：**[https://www.tapme.top/blog/detail/2019-02-28-11-33](https://www.tapme.top/blog/detail/2019-02-28-11-33) + + **本篇中 Zuul 版本为 1.x，目前最新的是 2.x，二者在过滤器的使用上有较大区别** **超长警告** +**项目代码见文章结尾** + # 一、背景   微服务架构将一个应用拆分为很多个微小应用，这样会导致之前不是问题的问题出现，比如： diff --git a/java/springcloud实战/5.springCloud之Spring Cloud Stream事件驱动架构.md b/java/springcloud实战/5.springCloud之Spring Cloud Stream事件驱动架构.md index 7700e6a..8ee2098 100644 --- a/java/springcloud实战/5.springCloud之Spring Cloud Stream事件驱动架构.md +++ b/java/springcloud实战/5.springCloud之Spring Cloud Stream事件驱动架构.md @@ -11,9 +11,12 @@ categories: ![hei](https://raw.githubusercontent.com/FleyX/files/master/teachSystem/20190223170520.png) -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2019-01-03-19-19) -**本篇所用全部代码:**[FleyX 的 github](https://github.com/FleyX/demo-project/tree/master/springcloud/spring-cloud-stream%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97) + +**springcloud 总集：**[https://www.tapme.top/blog/detail/2019-02-28-11-33](https://www.tapme.top/blog/detail/2019-02-28-11-33) + + +**代码见文章结尾**   想想平常生活中做饭的场景，在用电饭锅做饭的同时，我们可以洗菜、切菜,等待电饭锅发出饭做好的提示我们回去拔下电饭锅电源（或者什么也不知让它处于保温状态），反正这个时候我们知道饭做好了，接下来可以炒菜了。从这里可以看出我们在日常生活中与世界的互动并不是同步的、线性的，不是简单的请求--响应模型。它是事件驱动的，我们不断的发送消息、接受消息、处理消息。 diff --git a/java/springcloud实战/6.springCloud之Spring Cloud Sleuth分布式跟踪.md b/java/springcloud实战/6.springCloud之Spring Cloud Sleuth分布式跟踪.md index 668e7ba..104a9ef 100644 --- a/java/springcloud实战/6.springCloud之Spring Cloud Sleuth分布式跟踪.md +++ b/java/springcloud实战/6.springCloud之Spring Cloud Sleuth分布式跟踪.md @@ -1,53 +1,58 @@ --- -id: '2019-02-03-19-19' -date: '2019/02/03 19:19' -title: 'springCloud学习6(Spring Cloud Sleuth 分布式跟踪)' -tags: ['spring-boot', 'spring-cloud', 'spring-cloud-sleuth'] +id: "2019-02-03-19-19" +date: "2019/02/03 19:19" +title: "springCloud学习6(Spring Cloud Sleuth 分布式跟踪)" +tags: ["spring-boot", "spring-cloud", "spring-cloud-sleuth"] categories: - - 'java' - - 'springCloud实战' + - "java" + - "springCloud实战" --- -**本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2019-01-03-19-19) +**springcloud 总集：**[https://www.tapme.top/blog/detail/2019-02-28-11-33](https://www.tapme.top/blog/detail/2019-02-28-11-33) # 前言 -  在第四篇和第五篇中提到一个叫**关联id**的东西，用这个东西来将所有请求串起来，用来清晰的记录调用过程，以便以微服务的问题调试。 +  在第四篇和第五篇中提到一个叫**关联 id**的东西，用这个东西来将所有请求串起来，用来清晰的记录调用过程，以便以微服务的问题调试。 -  微服务虽然能够将单体软件系统分解为更小的、更易于管理的小系统。但是这种特性是需要付出代价的。其中之一就是----调试困难。所以需要有一种办法能够将所有服务产生的消息聚合起来，方便的获取某一次用户请求的全部日志信息。本篇只解决将请求串起来这个问题，日志聚合需要对应的日志平台配合，这里不做讨论(其实就是将日志全部手机放到一个地方(比如es)，再进行查询)。 +  微服务虽然能够将单体软件系统分解为更小的、更易于管理的小系统。但是这种特性是需要付出代价的。其中之一就是----调试困难。所以需要有一种办法能够将所有服务产生的消息聚合起来，方便的获取某一次用户请求的全部日志信息。本篇只解决将请求串起来这个问题，日志聚合需要对应的日志平台配合，这里不做讨论(其实就是将日志全部手机放到一个地方(比如 es)，再进行查询)。 -(PS：写这篇的时候突然发现，前面那种实现关联id方法是错误的，学习《spring微服务实战》过程中看到了不少错误，单大都不是很重要的，唯独关联id的那部分问题挺大。书上的实现是在每个服务中增加一个过滤器，提取入站请求中的关联id，然后存到ThreadLocal中，然后给服务调用类Ribbon加一个过滤器：用于从ThreadLocal中提取出关联id然后加入到请求的header中。这里的问题是前面的过滤器所在的线程和后面服务调用的线程不是同一个线程，也就无法用ThreadLocal来进行数据保存。在Feign请求的过程中是获取不到保存的值的) +(PS：写这篇的时候突然发现，前面那种实现关联 id 方法是错误的，学习《spring 微服务实战》过程中看到了不少错误，单大都不是很重要的，唯独关联 id 的那部分问题挺大。书上的实现是在每个服务中增加一个过滤器，提取入站请求中的关联 id，然后存到 ThreadLocal 中，然后给服务调用类 Ribbon 加一个过滤器：用于从 ThreadLocal 中提取出关联 id 然后加入到请求的 header 中。这里的问题是前面的过滤器所在的线程和后面服务调用的线程不是同一个线程，也就无法用 ThreadLocal 来进行数据保存。在 Feign 请求的过程中是获取不到保存的值的) -# 集成Spring Cloud Sleuth +# 集成 Spring Cloud Sleuth -## 什么是Spring Cloud Sleuth +## 什么是 Spring Cloud Sleuth -  简单来说Spring Cloud Sleuth就是为开发人员实现了前面关联ID尝试做的事情，而且做的更好。主要有一下几个功能： +  简单来说 Spring Cloud Sleuth 就是为开发人员实现了前面关联 ID 尝试做的事情，而且做的更好。主要有一下几个功能： -- 透明地创建并注入一个关联ID到服务调用中（如果不存在关联ID） -- 管理`关联ID`到出站服务的传播，将关联iD自动添加啊到出站调用中 -- 将`关联信息`添加到Spring的MDC日志记录，以便生成的`关联ID`由Spring Boot默认的SL4J和Logback实现自动记录 +- 透明地创建并注入一个关联 ID 到服务调用中（如果不存在关联 ID） +- 管理`关联ID`到出站服务的传播，将关联 iD 自动添加啊到出站调用中 +- 将`关联信息`添加到 Spring 的 MDC 日志记录，以便生成的`关联ID`由 Spring Boot 默认的 SL4J 和 Logback 实现自动记录 ## 怎么用   用法很简单，只需在要用的服务中引入`Spring Cloud Sleuth`依赖即可，代码如下： + ```xml org.springframework.cloud spring-cloud-starter-sleuth ``` + 然后就会发现引入该依赖的服务日志打印语句中都会多一些数据，结构如下： + ``` 2019-02-28 11:03:02 [ERROR] [server Name,trace ID,span ID,isSendData]... ``` + 其中各项意义如下： + - server Name：默认情况下使用`spring.applicataion.name`。 -- trace ID： 跟踪ID，相当于关联ID。整个微服务调用过程的唯一编号。 -- span ID: 跨度ID。表示某个服务过程中的唯一ID,比如在服务A中打印的日志跨度ID都是一样的。 -- isSendData: 是否发送数据给Zipkin。可配置是否将数据发给Zipkin,毕竟不是所有日志打印都是要收集的。 +- trace ID： 跟踪 ID，相当于关联 ID。整个微服务调用过程的唯一编号。 +- span ID: 跨度 ID。表示某个服务过程中的唯一 ID,比如在服务 A 中打印的日志跨度 ID 都是一样的。 +- isSendData: 是否发送数据给 Zipkin。可配置是否将数据发给 Zipkin,毕竟不是所有日志打印都是要收集的。   使用过于简单，因此不提供代码，自己引入依赖就能看到效果，无需任何配置。 @@ -58,4 +63,3 @@ categories: _2019,Fighting!_ **本篇原创发布于：**[FleyX 的个人博客](http://tapme.top/blog/detail/2019-02-03-19-19) - diff --git a/main.txt b/main.txt new file mode 100644 index 0000000..0461772 --- /dev/null +++ b/main.txt @@ -0,0 +1,3 @@ +**扫码关注微信公众号：FleyX 学习笔记,获取更多干货** + +