Zuul源码分析(2)Filter分析

前言

前一篇文件中我们分析了zuul对Filter请求了不同的阶段划分了多个生命周期即FilterType。接下来我们继续分析每一个FilterType的具体的Filter有哪些,他们都干了什么。

ZuulFilters运行流程图

  • 前面我们分析完了zuul的一个生命周期,下面我们在来仔细的看一下每个生命周期具体使用到的Filter

Sample

Read More

Zuul源码分析(1)生命周期

前言

  • Zuul在Spring Cloud Netfilx 体系中扮演着接入者网关的角色。
  • 本质上来说Zuul本身就是一系列的filters, 可以类比Servlet框架的Filter。按照生命周期我们可以分为四种类型(pre,route,post,err)分别对应请求过程。你可以从com.netflix.zuul.FilterProcessor类里面找到所有的生命周期处理。
  • 为什么我们要去了解它?比如我们想在网关统一对用户进行鉴权,进行JWT的解析和参数转换,比如我们想实现自己的httpClient,再比如我们想在后端业务微服务返回的结果内进行一些特别的处理,比如脱敏啊,比如去掉一些字段啊。

Zuul每个周期的流转过程

  • 请求流程

Sample

Read More

记SpringCloud 1.X 升级到2.x

前言

  • 前后花了两周多个时间完成了 Spring Boot 1.5.6.RELEASE & Spring Cloud Dalston.SR4 升级到 Spring Boot 2.0.6.RELEASE & Spring Cloud Finchley.SR2 & spring-cloud-netflix 2.0.2.RELEASE 的工作。
  • 总结一下遇到的一些问题

一些问题的总结

  • 首先 1.x和2.x的所有的服务注册,服务发现,灰度调用,服务调用,zuul网关等等组件核心都是兼容的。so大胆的升级吧。
  • 其次maven pom变化较大,主要是netifilx的artifactId变化比较多,其余的变化都不是太大,这都可以通过spring-cloud-netflix-dependenciespom中找到。
  • 然后是feign的变化比较大,整个包名发生了变化。
  • NotBlank,NotEmpty 现在已经纳入了JSR303了,不需要在使用hibernate提供的注解了。

一些建议

  • 建议统一抽象出一个业务服务使用pom依赖项目,并打包发布维护起来,比如我们这里就叫my-server-dependencies的这么一个pom项目。这样做有几个好处:
  • 第一个是通过将版本统一管理起来了,方便对所有的基础服务jar包进行升级,而且能够完成版本的基础依赖管理。
  • 第二个是能够避免掉由于未付项目过多之后导致的依赖版本混乱。
  • 第三个是能够将maven插件统一的配置,比如说docker打包插件,fatjar插件,compiler插件 ,能统一的对他们进行控制和配置,并通过properties暴露出集体的调优指标。

Read More

记Kafka的一个BUG,导致整个集群不能工作

现象

  • Kafka producer 无法正确的发出任何消息一直抛出Timeout(由于我们业务设计上就把业务时间和mq完全分离了这里,不会导致业务不能正常进行,只会产生业务暂时的不一致性)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19

    java.util.concurrent.TimeoutException: Timeout after waiting for 5000 ms.
    at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:76)
    at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:29)
    at com.my.fnc.mq.FncRunner.apply(FncRunner.java:42)
    at io.goudai.starter.runner.zookeeper.AbstractMultipartRunner$1.doRun(AbstractMultipartRunner.java:76)
    at io.goudai.starter.runner.zookeeper.AbstractRunner.takeLeadership(AbstractRunner.java:94)
    at org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
    at org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
    at org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
    at org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
    at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
    at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Read More

如何构建SpringBoot的Docker镜像

目标

  • 自定义Dockerfile构建一个生产可用的jre base image
  • 配置maven-docker-plugin插件完成从源码的 打包fatjar -> build docker image with fatjar -> push image
  • 支持docker对JVM相关参数的配置。比如Xmx,Xms,以及完全自定义的java启动参数。

rootfs

  • 说打包之前我们先了解linux内核与发行版操作系统(如centos,ubuntu,debian)之间的关系。
  • 由于linux内核与具体的操作系统是解耦的。即互相不干涉的,docker利用了这个特性,将操作系统的文件打包成一个压缩文件。
  • 在运行时,解压这个压缩包,并通过chroot进行挂载,就完成了容器的内部我们看到的操作系统了。即我们的rootfs。
  • 那么这个和我们docker打包java应用的关系在哪里呢?
  • 总所周知的是java是又提供打包解决方案的,打包成jar,但是此方案的问题在于我并不能在任何一个环境里面运行直接运行(因为依赖JRE),而每一个操作系统又不一样,这就导致许多环境带来的时间浪费。
  • 结合前面提到了docker打包是把操作系统的文件打包的,所以我们能不能把操作系统+jre+application.jar这三老铁一锅端,全给他打包起来不就解决了吗?没错,这就是我们要构建镜像。
  • 没错我们想到了一个好的办法来解决打包的问题。那我们在来看看这个东西是不是还有啥问题?你看啊,我们最初了发布一个fatjar也就60M,要结合上OS jre岂不是每次都大很多,浪费很多的磁盘,网络传送开销也加大的蛮多。
  • 这个问题的docker中利用了分层文件系统来解决这个问题,即我们的OS JRE 这些不变的东西只会在第一次使用时下载一次或者上传一次,其他时候我们只有变化的application.jar层需要进行上传和下载

最终形态

  • 我们像搭积木一样一层一层的把我们所需要的文件系统叠加起来,就完成了我们想要的Image。
    Sample

    Read More

扩展spring-cloud-ribbon支持灰度

目标

  • 扩展ribbon完成灰度调用
  • 完成对zuul的支持
  • 完成服务间调用的支持
  • 实战,解决在开发环境,进行开发中的测试,DEBUG.在微服务的模式下,需要在开发者的机器启动大量服务,
    启动大量的服务需要大量的内存和大量的时间,在我们时间的项目开发中,在16G的机器上甚至无法进行调
    和测试相关工作。

思路

Read More

kubernetes全自动弹性伸缩组件

目标

  • 使用容器完成 metrics-server 部署
  • 演示 Horizontal Pod Autoscaling (pod 自动缩放)

部署 metrics-server 服务

  • Horizontal Pod Autoscaler(HPA)控制器用于实现基于CPU使用率进行自动Pod伸缩的功能。
  • HPA控制器基于Master的kube-controller-manager服务启动参数–horizontal-pod-autoscaler-sync-period定义是时长(默认30秒),周期性监控目标Pod的CPU使用率,并在满足条件时对ReplicationController或Deployment中的Pod副本数进行调整,以符合用户定义的平均Pod CPU使用率。
  • 在新版本的kubernetes中 Pod CPU使用率不在来源于heapster,而是来自于metrics-server
  • 官网原话是 The --horizontal-pod-autoscaler-use-rest-clients is true or unset. Setting this to false switches to Heapster-based autoscaling, which is deprecated.

    Read More