这书怎么说呢,讲的挺浅的,而且主要是无意义的代码片段贴的过多了。

很多知识点比如说书中的synchronized关键字讲解、wait notify等方法讲解,明明梳理知识点讲完就完事了,偏偏要贴几十页代码,有水字数嫌疑。

贴代码也就算了吧,还贴的是eclipse的截图代码,也不知道该说什么。

 

本来看synchronized关键字的时候还以为会讲讲jvm实现方式、对象头储存的数据、monitorenter、monitorexit指令之类的。

结果啥都没讲。Lock类也就讲ReentrantLock、ReentrantReadWriteLock的使用,我也以为会有实现、机制、AQS的讲解来着。

每天早上起床看半小时书,就这本看完感觉没学到啥= =

我估摸着是给没怎么接触过java多线程的人群看的,可能不太适合有多线程编程经验的职业人士。

 

最后在吐槽一句: 这些多线程相关的类的使用方法,我不会看API嘛,闲得蛋疼慢慢看这书

阅读全文

说是简单,tm那是找到解决方案之后才简单。

可能是我用的SpringCloud版本太新了,自己配zipkin server把我给配吐了。

又是版本冲突、又是注册不进去Eureka、又是访问ui报错、又是找不到ObjectProvider.orderedStream()方法的,我从百度搜到必应搜到google搜到Stack Overflow,整了一个上午。

我就想着,这玩意怎么能这么恶心呢?感觉像写maven的时候狂报xml错误那种感觉。

 

后来怼到zipkin官网 zipkin.io 上去,卧槽,快速入门里有这么句话:

If you have Java 8 or higher installed, the quickest way to get started is to fetch the latest release as a self-contained executable jar:

 

 

我佛了。然后又查了些关于高版本资料,关于 Zipkin 的服务端,在使用 Spring Boot 2.x 版本后,官方就不推荐自行定制编译了,反而是直接提供了编译好的 jar 包来给我们使用,这是官方提供的演示: https://github.com/openzipkin/docker-zipkin

白搞了半天,原来只要自己去下他的jar包然后启动这个服务就行了,至于如何将微服务跟踪的数据存到mysql/kafka/es 里边去,也可以直接用启动参数指定。

那我还自己配个蛇皮的zipkin server。

 

可以去这个网址: https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/ 选择下载zipkin的各个不同版本的启动jar,我随便找了一个,启动很顺畅,进入 localhost:9411 可以访问ui。

那服务端就算这样配完了,全部流程: 下载 –> 使用 java -jar 命令运行下载的jar

 

服务端搞完后,就到客户端了。

微服务链路跟踪嘛,需要得到请求经过了哪些微服务,了解请求流转的具体参数,那么客户端自然就是一个个不同的微服务了。

 

以我之前的user微服务为例,配置都一样。

build.gradle中加上这一行:

本来应该是spring-cloud-starter-sleuth,spring-cloud-sleuth-zipkin这两个依赖,但是spring-cloud-starter-zipkin这个集成了前面那俩,和前面那俩依赖效果是一样的。

加完依赖后只需要指定zipkin服务地址就好了

我的applicayion.yml:

 

spring.zipkin.base-url 指定地址。zipkin端口号默认9411。

spring.sleuth.sampler.probability 设置采样百分比,采样百分比就是会按比例来跟踪/保存多少条请求数据,因为在线上运行的话那数据是相当庞大的。默认设置的是0.1,也就是百分之十,我这设置百分之百是为了本地调试。

 

然后就完事了

对,没问题。所有微服务开起来,Eureka、Zuul等等,当然还有Zipkin官方服务。网页请求几个API,再去 localhost:9411 刷新一下,就可以看到每一条请求的详细信息了。

 

实现微服务跟踪需要的步骤:

1、 下载官方推荐的jar包

2、运行起来

3、改下微服务,加个依赖加个配置

完事了,如果想要保存数据到es/mysql/kafka里分析,可以设置启动参数,具体可以去看官方、github

 

 

我的使用Gradle搭的SpringCloud Finchley.SR3 项目整体地址:

https://github.com/skypyb/codeDemo/tree/master/sc-demo-microservice

阅读全文

刚因腰椎骨折从床上起来没几个星期,腿部的表皮样囊肿又发炎化脓了。没辙,只能手术,由于发炎了才割的,以后还有复发的可能。佛了。

从上周三开始,就是上周三(2019.06.12)做的手术,麻药并没有什么用处,本来是要打腰麻的,结果因为我刚腰椎骨折所以不能打,那只能局麻了,感受的清清楚楚,我都不想回忆了,疼的不行。

一直躺到今日出院,当然日常还是可以走一走的,下周一回到工作岗位,这也住院九天了。

今年还真是多灾多难,目前为止我2019年呆在床上的就有一半日子。我明明是个穿衣显瘦脱衣有肉的每日锻炼自律性较强的一次能拉十个标准正手引体向上的人设来着,怎么就变成一个终日卧床把医院当家住的病弱人设了呢。

 

咳咳,这也是我的第150篇博文,说实话我也有一点点小骄傲;毕竟能一直坚持做一件看似没什么用的事情也是挺不容易的,博客这玩意我也看了不少别的程序员写的博客,绝大多数就是三分钟热度,几篇十来篇文章就没下文了;像我这种持续更新的还是比较少的。

从我博客文章归档从头看起的话,可以很明显的看到我的成长,但也不过就是我的一部分成长而已,毕竟有很多新学的东西我也没总结出来,比如我现在就在学习vue.js , 还有很多别的代码放在gitbub上了。

博客还是会继续写的,持续更新,坚持一件事的感觉非常好,有个向外部展示自己水平的途径非常好。虽说这博客很简陋,就是用的wordpress,还没上ssl证书,不过都是小问题,毕竟内容为王,其他的我都不在意也懒得折腾,有一点不好的是扛不住恶意请求,之前崩过几次,要是持续有人搞我网站的话或许我会考虑自己买台国内的服务器迁移一波。

 

就说到这了,第150篇博文,又是值得纪念的一刻。《SpringCloud 与 Docker;微服务架构与实战》这本书我已经看完了,SpringCloud后面准备再写个服务跟踪的文章,应该就在不久后。至于Docker ,这书讲的速度飞起来了,就十来面,看是看完了,就是看的很难受,我还是之后慢慢看视频学比较好。

编码少年依然天天绝赞进化中!

 

阅读全文

上篇文章主要是搭建了一下Zuul的服务,并且实现了Zuul过滤器的自定义需求。

里边讲到了,Zuul 已经集成了 Ribbon、Hystrix ; 而 Ribbon无需配置,会在请求路由时自动给你进行负载均衡。

但是在Zuul服务路由不到对应微服务时,是没有对应的回退机制的,还是得自己手动写一下。

 

实现路由失败回退机制,首先需要继承 FallbackProvider 类,实现其getRoute() 和 fallbackResponse() 方法。

getRoute方法是指定你需要回退的线路,返回一个服务名就行。它会在路由该服务发生故障时调用 fallbackResponse 方法从而返回你一个 ClientHttpResponse 对象。

 

我写的回退代码:

 

 

这个代码会在路由到sc-demo-microservice-user这个服务出错时触发,然后根据不同的异常给出不同的响应(我这就是变了个Status哈)

配上一个回退机制后,就让Zuul服务更加完善健壮了,这样子,就算路由的服务挂掉了,我也能返回个东西让前端显示,也能做一些其余的抢救操作。

 

Zuul这个服务到这,其实也就差不多了,该有的都有,虽说也有Zuul这个服务挂掉的可能,但是Zuul也是可以集群的呀,前端可以访问一个负载均衡的服务器(比如Nginx),让他来转发请求到集群Zuul服务上边,这样子,整个微服务架构就非常健壮了(像这种Nginx服务一般不会挂哈,就一个纯走流量的服务器都能挂了,那你的流量是有多猛   除非硬件问题,那没辙)

 

咳咳, 说起来Zuul服务搭是搭好了,但是你就做一个服务路由+负载均衡,那也不是个事啊,我客户端那边请求服务,我要是需要多个数据,我是不是要发多个请求?

每个请求都要走–>zuul–>service 这一套流程,是不是不大好,毕竟我发多个请求来请求多个服务,总会有性能损耗。

那要是我就发一个请求到Zuul Server ,然后由Zuul 来帮我聚合请求多个微服务,包装成一个数据返回响应给我好不好鸭,那当然是极好的。这些微服务所在的服务器八成是在一个局域网里(除非你买的实例所在地区不同甚至供应商都不同哈) 那个网络传输速度,快的飞起来。

 

这个是我写请求聚合的代码:

 

我这就请求了zuul一个服务,然后就全权交给zuul给我把我要的数据都拿到了,组合成一个数据响应给我,是不是非常nice。我客户端的请求代码编写,也变得简单了。

 

到现在为止,整个Zuul架构就差不多了。自定义过滤器、回退、请求聚合、我还提供了一个zuul的集群高可用方案。基本上可以满足大多生产需求。

我的项目地址:Github

阅读全文

 

微服务架构有一个问题,那就是客户端如何访问各个微服务。

总不能在客户端APP/HTML写很多个不同的地址来请求吧?这样维护及其困难、开发不易。

这时候就需要一个网关,客户端的请求都发给这个网关, 然后由他来给你路由到别的微服务里边。

netflix 就开源了一个微服务网关:Zuul ,可以和 SpringCloudNetflix 全家桶(Eureka、Ribbon、Hystrix等)完美集成。

 

废话不多说.代码撸起来。

首先,项目创建,当然,创建的还是我那个Gradle搭的SpringCloudFinchley项目的子模块。

这回不用加什么依赖,只需要一个Zuul的依赖和Eureka Client的依赖就够了。

而且Zuul自己本身就集成了Ribbon和Hystrix,非常强大。

build.gradle:

 

然后在Application启动类上边加上@EnableZuulProxy 用以声明zuul代理

最主要的: 配置类yml文件

既然这个 zuul 是提供一个服务路由的功能,又已知 zuul 完美的集成了 Eureka。可以从Eureka Server中得到所有注册进去的服务。

那么,最需要进行配置的。自然是访问路径所对应的服务啦, 在zuul这个服务的配置文件里,专门有个地方给你写这个路由规则( zuul.routes )

我的配置文件:

 

虽然我这个配置文件里注释已经写得挺详细了,但还是简单的解释一下:

zuul.routes 这个属性树下面第一级节点,即我写的local-router、user-router 等,这一级只是让你写个路由规则的名字。 瞎写就行。

再下一级,大致可以分为两种:

1、路由到其余微服务的 指定好 service-id(即服务注册进Eureka的服务名) 和对应的访问路径就行了 ( 例如: 我用户微服务有个API请求路径是 user/{id},我现在就可以通过 ZUUL_ADDRESS:ZUUL_PORT/zuul_user/user/{id} 来访问我sc-demo-microservice-user中的API)。

 2、路由到本地由Zuul自己进行处理的 指定好客户端访问路径,和对应的本地API地址( forward: +本地API的地址) 就行

 

到这步,其实Zuul这个服务就搭建完毕了, 已经可以使用了。而且,不但可以帮你进行服务路由,还会用自带的Ribbon给你的请求进行负载均衡。

 

搭建完了,当然还不够,还能让这个 zuul 服务更加强大

zuul的路由功能是基于他自己编写的一大堆过滤器实现的,这里先简单说下他的过滤器类型

他主要有四大标准过滤器类型,这四种是最主要的

1、PRE  在请求被路由之前调用这个过滤器

2、ROUTING 这个过滤器将请求路由到微服务

3、POST 这个过滤器在路由到对应微服务之后再执行

4、ERROR 出错时进的

 

zuul 他自己有这几个过滤器的实现,当然,他写的我不动他,我可以自己额外写过滤器来实现自己的功能嘛。

zuul过滤器的实现非常简单,只要继承 ZuulFilter 这个类就完事了。

我写了个日志记录的过滤器:

这几个方法不多说,看下ZuulFilter源码的注释就知道具体是什么意思了。反正就是关于你写的过滤器的设置(类型、执行顺序、是否执行、具体逻辑)

我这过滤器很简单,就记录一下请求方法、地址,是个PRE类型的过滤器,会在路由之前调用。过滤器能干的事情很多,认证啊、加密啊啥的都行,看业务需求了。

 

 

阅读全文
EA PLAYER &

历史记录 [ 注意:部分数据仅限于当前浏览器 ]清空

      00:00/00:00