神兵利器： GitLab CI/CD UP 工作效率 🚀🚀🚀
前言
在互联网行业中，当新产品的一个个需求确立下来，开发同学不仅仅需要进行代码开发，在每个功能完善的同时，都需要重新发布测试环境，换而言之，开发同学还肩负着持续的部署工作。
为什么需要频繁部署？
因为产品时由多个功能点组合而成，所以一般会拆分为各个功能点划分给不同的开发同学协同合作推进产品成型，每一个功能点完成后，都需要发布到测试环境交由测试同学进行验证，若出现 Bug，则告知开发同学进行修复，因此，在一个功能点完成后，一个 Bug 修复后，都需要发布到测试环境。
开发同学是如何进行部署工作的呢？
开发同学一般是在功能点完成或 Bug 修复后，进行一系列以下操作：
- ① 将代码打包
- ② 上传到测试环境服务器
- ③ 删除（备份）旧包，kill 旧包进程，start 新包进程
这一系列人工操作，是重复且会花费开发同学一定时间的。
那么，以上操作能否自动化？降低开发同学的部署时间，提升团队的工作效率呢？
当然可以，这个时候就需要使用 CI/CD 工具了，并且它的作用远不止于此。
聚沙成塔：巧用 Nexus 搭建 Maven 私服
前言
在互联网行业中，成熟的公司都会有专门的技术团队开发出各式各样的产品供用户使用。对于公司内部的不同产品而言，并不是每一个产品都需要重零构建，大多数情况下都是在旧产品基础上组合拼凑，衍生出新产品。
如果说 B、C 产品都是在 A 产品基础上开发的新产品，那么意味着什么呢？
对程序员而言，这代表着继承，也可以说是代码复用。
那么，就有个问题了，如何去让 B、C 产品的代码继承 A 产品代码呢？
A 产品代码打个包嘛，每个 Java 程序员都会使用 Maven，引入下不就好了？
话是这么说，但是有个问题，A 产品的包放在哪里？不可能放中央仓库吧？这可是公司内部的产品呀！
嘿嘿，这个时候，就需要专门搭建一个存放公司产品包的仓库，去管理这些内部产品包了。（这种内部产品包被称为二方包，公司搭建的仓库被成为二方库）。
一般而言，公司内部的二方库早就有开发搭建好了，用不着新人动手，但由于罗马并不是一天就能建成的，有的公司技术部门可能刚刚创立，会存在没搭建过私服的情况，这个时候就需要我们手动动手了。
那么，下面跟随本文来搭建一个 Maven 私服吧！
线上诊断神器──Arthas
Thread
Thread 命令可以查看当前线程信息，查看线程的堆栈.
定位 CPU 问题：thread
直接使用thread命令将默认按照 CPU 增量时间降序排列，只显示第一页数据。
1 | $ thread |
展示当前最忙的前 N 个线程：thread -n
展示当前最忙的前 N 个线程并打印堆栈：
1 | $ thread -n 3 |
- 没有线程 ID，包含
[Internal]表示为 JVM 内部线程，参考dashboard命令的介绍。 cpuUsage为采样间隔时间内线程的 CPU 使用率，与dashboard命令的数据一致。deltaTime为采样间隔时间内线程的增量 CPU 时间，小于 1ms 时被取整显示为 0ms。time线程运行总 CPU 时间。
注意：线程栈为第二采样结束时获取，不能表明采样间隔时间内该线程都是在处理相同的任务。建议间隔时间不要太长，可能间隔时间越大越不准确。 可以根据具体情况尝试指定不同的间隔时间，观察输出结果。
thread –all, 显示所有匹配的线程
显示所有匹配线程信息，有时需要获取全部 JVM 的线程数据进行分析。
显示指定线程的运行堆栈：thread id
1 | $ thread 1 |
线程死锁：thread -b
有时候我们发现应用卡住了， 通常是由于某个线程拿住了某个锁， 并且其他线程都在等待这把锁造成的。 为了排查这类问题，可以通过thread -b命令 一键找出罪魁祸首。
1 | $ thread -b |
注意， 目前只支持找出 synchronized 关键字阻塞住的线程， 如果是
java.util.concurrent.Lock， 目前还不支持。
其他
指定采样时间间隔：thread -i,
thread -i 1000: 统计最近 1000ms 内的线程 CPU 时间。thread -n 3 -i 1000: 列出 1000ms 内最忙的 3 个线程栈
1 | $ thread -n 3 -i 1000 |
查看指定状态的线程：thread –state
1 | [arthas@28114]$ thread --state WAITING |
生成火焰图
通过命令开启采样，观察一段事件后停止，输出一个 html 火焰图文件打开观察即可。1
profiler start
1 | profiler status |
1 | profiler stop |
火焰图的效果大致如下图：
图中的每个色块代表的是一个线程栈帧，色块中是该栈帧加载执行的函数以及一些采样信息。Y 轴代表调用栈的深度，调用从底部开始向上进行，顶部是正在执行的函数，下面是它的父函数，调用栈越深，火焰就越高。X 轴代表抽样数，如果一个函数在 X 轴占据的宽度越大，表示它被抽取到的次数越多，也就意味着它占用的 CPU 时间越长。
需要注意的是，图中的颜色并不重要，只用于区分不同的函数，同时 X 轴的从左到右的顺序也不重要，默认按照字典顺序排序。
我们可以简单举个例子来理解。一般在使用性能分析工具时，我们会选取一个合适的时机启动分析采样，然后等待一段时间后停止采样。假设采样时间为 20 秒，每秒采样 100 次，那么共采样 2000 次，在这 2000 次中，共有 1800 次执行的是 main 方法，其余 200 次执行的是 run 方法，同时 main 方法又调用了很多其他方法，run 方法也是，这就形成了一个从下往上的调用链，在这些调用链中，又同时会收集到每个方法采样的次数，最终形成一张火焰图。
火焰图是可以互动的，点击某个色块，该色块会被放大并占据所有的宽度，这样可以方便地查看某个函数内部的调用链信息。一般观察火焰图，就是看顶层函数占用的宽度，如果有些函数占用的宽度很大，形成了“平顶”，那么就代表该函数可能存在性能问题。当然，有时候直接观察平顶并不能快速定位问题，因为很多时候顶部的函数都是一些底层的库函数，这时候就应该先观察业务代码在火焰图中的宽度，然后再往上观察顶部的库函数来缩小范围。
从上面的火焰图发现TestController类的wl方法占据的 x 轴宽度较长，这是因为我们程序写了一个死循环到消耗了 CPU 。
1 |
|
trace
使用 trace 命令查看耗时
我们写几个不同循环次数的方法，分别代表方法耗时不同，代码如下：
1 | //示例代码,timeCost是个接口 |
部署之后我们使用 trace 来查找最耗时的方法，在此过程中需要知道包名、类名，以及方法的名字。上述代码方法所在包名为 com.cctest.arthas_demo.controller，类名为 StressSceneController，所以我们需要输入如下 trace 命令：
1 | trace |
输完命令后回车，然后 arthas 程序就进入了等待访问状态。这时候访问接口 /timeCost，我们就可以看到被测程序台在疯狂打印日志，等结束之后，arthas 命令窗口便输出了各方法耗时时间，如图 3 所示：
vmtool
查看spring所管理的所有的bean名称
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBeanDefinitionNames()’
查看具体的某个bean及其属性
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”)’ -x 3
调用 bean 的方法
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”).ok(1)’
ognl
ognl 语法：
- #开头变量 在ognl 里面是变量全局的，可以传递 ;
- 字段类型要注意
- Doubble -> 1D
- Long - >1L
- String ->
""
- Class对象-> @xxxClass@class 相当于一个静态的变量
调用 Spring Bean 及对应方法
步骤说明
主要分为三步：
- sc 获取工具类的 classLoaderHash
- ognl 指定工具类的 classLoaderHash 获取对应 Bean
- 根据需要调用的 Bean 对象相关方法进行调用
实战运用
1 | sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
1 | [arthas@14466]$ sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
调用 Redis 工具类查看某个 Redis Key 的类型
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").type("osier:sys:dict")' |
返回结果：
ognl -c 2e5d6d97 -x 3 '@com.it.chenyuan.business.utils.SpringUtil@getBean(“MyRedisUtil”).get(“aper_duty_rate:hwzy:1868547696917106690”)’
1 | [HASH] |
调用 Redis 工具类查看某个 Redis Key 是否存在
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").exists("osier:sys:dict")' |
返回结果：1
[true]
单独设置UserController的logger level
1 | ognl --classLoaderClass org.springframework.boot.loader.LaunchedURLClassLoader '@com.example.demo.arthas.user.UserController@logger.setLevel(@ch.qos.logback.classic.Level@DEBUG)' |
排查HTTP请求返回401
请求接口没有权限的时候一般就返回401 Unauthorized。
401通常是被权限管理的Filter拦截了，那么到底是哪个Filter处理了这个请求，返回了401？
跟踪所有的Filter函数
开始trace：
1 | trace javax.servlet.Filter * |
可以在调用树的最深层，找到AdminFilterConfig$AdminFilter返回了401
1 | +---[3.806273ms] javax.servlet.FilterChain:doFilter() |