有时候多个项目在一个代码仓库中，可能每个文件夹都是一个项目。如果每次使用CI自动部署的话就需要判断最近的改动属于哪个文件夹/项目。

通过JGit直接获取两个commit之间的diff然后判断是比较直接的方法，具体使用哪两个commit就看需要的。可以使用CI系统上一次成功构建的commit sha，也可以直接使用最近两天的commit的。

代码如下：

Repository repo = FileRepositoryBuilder.create(new File(basePath + ".git"));
Git git = new Git(repo);
ObjectReader reader = repo.newObjectReader();
ObjectId newObjectId = repo.resolve("HEAD^{tree}");
ObjectId oldObjectId = repo.resolve(successSha + "^{tree}");


System.out.println("Starting diff " + oldObjectId + " : " + newObjectId);

CanonicalTreeParser oldTreeIter = new CanonicalTreeParser();
oldTreeIter.reset(reader, oldObjectId);
CanonicalTreeParser newTreeIter = new CanonicalTreeParser();
newTreeIter.reset(reader, newObjectId);

List<DiffEntry> diffs = git.diff().setNewTree(newTreeIter).setOldTree(oldTreeIter).call();

for (DiffEntry entry : diffs) {
    System.out.println("Entry: " + entry);

    for (String folderName : folderNames) {
        if (entry.getNewPath().contains(folderName) || entry.getOldPath().contains(folderName)) {
            System.out.println("Need deploy folder: " + folderName);
            foldersNeedDeploy.add(folderName);
        }
    }

}

其中的successSha是上一次成功部署过的commit sha值，也可以使用类似HEAD^^^^^的表达式直接使用倒数第四次commit。

如果是Groovy脚本的话需要引入依赖

@Grapes([
        @Grab(group = 'org.eclipse.jgit', module = 'org.eclipse.jgit', version = '5.2.1.201812262042-r')
])

影子表和buffer pool

影子表并不是一个数据库的特殊功能，简单来说只是和原表结构一致但是名字不一样的普通表而已。所以创建影子表并不需要特别的操作，根据数据库中间件的支持规则创建就行了。

buffer pool是一个缓存数据和索引信息到内存的存储区，简单理解就是一个热数据区，或者叫缓存。具体的配置和计算比较复杂，但是总体而言，buffer pool命中率越高，性能越好。

预热的价值

因为影子表的数据是冷数据，这一部分数据并不在buffer pool中，需要逐步加载到内存中，因此需要预热过程。如果没有预热，会出现性能问题，但是这一部分并不是我们期待的，因为线上buffer pool中是包含了真实数据的。

执行预热

执行预热就是低流量的压测，让影子表的数据被访问到，并加载到buffer pool中。

其次就是执行预热前，需要先dump出线上的buffer pool，然后在压测完成重新load之前导出的buffer pool。

其他要点

预热的时候要注意因为buffer pool的空间是公用的，要注意不要让影子表的数据影响线上数据了。业务高峰期很难成功，因为线上的流量大，真实数据占用buffer pool的量比较大，预热数据的buffer很快就被线上请求踢出。

预热时要密切观察慢查询的量，有问题就需要降速或者停止，严重的情况还需要在DB上kill查询，并重新加载buffer pool。

Java世界一个很难绕过的问题就是依赖包，绝大部分项目总会或多或少的依赖第三方包。Maven或者Gradle等可以帮助我们轻松的管理第三方依赖，但是对于自己对外提供的包，特别是作为中间件或者基础组件等提供出去的包，还是会遇到一些第三方依赖的问题，主要有两个问题

• 包依赖比较少，而且依赖第三方包中的极少部分代码
• 一些关键依赖版本敏感，不希望使用方随意变更

第一个情况可以先打一个fatjar，然后通过ProGuard精简代码。

第二个情况就需要把第三方包的代码拷贝到自己的包中，在自己的代码中直接使用拷贝进来的三方包代码（pakcage name不一样），这样就可以最大程度保证稳定性。

当然大部分情况下对于第三方包的版本依赖没有那么敏感，上面说到的情况其实是大部分针对asm，cglib和objenesis等几个字节码增强的包。

具体的操作可以借助jarjar工具，先将三方包重新打包，然后修改Gradle的Jar任务，将重新打包后的jar复制到自己的包中。

task cglibRepackJar(type: Jar) { repackJar ->
    repackJar.baseName = "cglib-repack" repackJar.version = cglibVersion doLast() {
        project.ant {
            taskdef name: "jarjar", classname: "org.pantsbuild.jarjar.JarJarTask", classpath: configurations.jarjar.asPath
            jarjar(destfile: repackJar.archivePath) {
                configurations.cglib.each { originalJar -> zipfileset(src: originalJar) }
                rule(pattern: "net.sf.cglib.**", result: "com.huangyunkun.cglib.@1")
                rule(pattern: "org.objectweb.asm.**", result: "com.huangyunkun.asm.@1")
            }
        }
    }
} 

然后修改Gradle的Jar任务配置

jar {
dependsOn cglibRepackJar
from(zipTree(cglibRepackJar.archivePath)) {
include "com/huangyunkun/cglib/**"
}
}

当然在具体打包的时候还可以根据需要exclude一些不需要的模块。

参考：https://github.com/shevek/jarjar

全链路压测是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

全链路压测针对是线上真实环境，主要的目的是针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。简单来说就是为了快速准确找出系统的优化点。

全链路压测听起来很好，各个大厂都可以找到相关的博客或者分享文章，但是要实施全链路压测需要很大的工作量，对于系统需要进行改造。

由于全链路压测涉及整个技术生态，不同的公司使用的技术和基础设施各不相同，所以改造内容也不同，但是大致的改造是类似的，主要在以下几个方面：

流量标记

流量标记的作用是让所有服务或者说是代码在任何一个时刻都能知道当前是否为压测。因为实际业务中链路一般都比较长，从头开发这样的一个功能还是比较复杂。

目前大部分系统为了全链路追踪一般都是用了OpenTracing标准的某种实现，那么在OpenTracing中的Span中的Context就是一个绝好的信息载体。

对于对外暴露的HTTP API请求，需要从URL中获取到压测信息，然后将其传递到RPC或者其他调用层，RPC层依次传递对应的标志就行了。

RPC框架

RPC上的改动比较上，主要是需要用上下文传递压测标记。这里可以用RPC框架自带的上下文，当然用OpenTracing的比较方便，这一步改动不大。

数据库中间件

既然要做全链路压测，那么肯定不能只测试读接口，对于写接口，需要考虑到数据隔离的问题。

这个时候影子表是比较合适的选项，影子表是与真实表对应的一个概念，与真实表同构，只是名称不同。在MySQL的innodb引擎中，影子表与真实表存储的文件不同，但是共用buffer pool。总体而言，影子表的使用是安全，能够有效模拟真实表，同时又能起到逻辑隔离的效果：

数据库中间件需要支持的是影子表偏移的，而且还需要支持配置，因为根据业务和系统情况，并不是所有表都需要影子表，而且影子表的偏移各不相同。

其次就是和影子表有关的其他改造，比如初始化，预热，buffer pool恢复，数据构造和数据清理等都是需要考虑的。

MQ中间件

MQ中间件主要是两个问题，一个是压侧标识传递，另外一个是队列隔离。

日志组件

日志组件上主要是压测流量日志是否需要打印特定标识，是否需要单独的降级开关。

线程池

业务系统或多或少用到了线程池，而线程池一般都需要改造用于支持压测标识的传递。

Mock

一个完整的业务流程很难只和自己的系统打交道，外部系统一般不纳入压测中，比如第三方保险/语音电话服务/短信等等，有时候也会遇到下游系统并没有准备好加入压测链路，所以需要Mock。

具体的Mock返回数据要根据情况创造。

降级

降级并不是全链路压测必须的，但是提供降级开关可以在压测出现问题的时候中断部分接口，依然执行全链路压测，以免压测失败。

这周的一天早上一个定时任务突然报错，错误如下

### Error querying database. Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 67,409 milliseconds ago. The last packet sent successfully to the server was 60,060 milliseconds ago. ### The error may exist in file [xxxxx.xml] ### The error may involve defaultParameterMap ### The error occurred while setting parameters 

字面上看是数据库链接出了问题。

最近才把应用的数据库链接池从tomcat切换到druid，所以第一个怀疑的就是druid。

网上搜索搜索一下，发现大部分答案都基本是在连接取出之前需要进行测试，连接池一般支持这样的配置。稍微检查了一下，发现项目中已经配置了相关的配置，所以理论上不是这个问题导致的。

然后仔细研究了一下这个问题，发现这个问题其实蛮常见的，错误信息是一样的，但是具体对应的情况却是各不相同的。比如上文提到的是由于连接超时连接池再取出连接前没有进行测试，这只是一种情况，还有一种比较常见的情况是连接已经建立，但是由于慢查询或者服务器压力过大，导致长时间没有数据返回，占用数据库连接，进而达到数据库最大允许的连接数。

根据这个思路检查了一下数据库平台，从监控中可以看到有一个慢查询持续了60余秒，优化掉这个慢查询就解决了这个问题。

当然还有一些其他比较基本的情况，比如数据库地址错误，导致直接无法连接，或者是数据库配置有误，导致无法接受连接，不过这种问题一般出现在初次连接的时候，一般不会发生，在稳定运行的线上环境。

最近换了一个硬盘，重新装了一下系统。
自然各种环境和工具也要重新装。

apt install没法安装docker-ce，官方文档虽然详细，但是步骤挺多的。然后就发现官方的安装脚本，还支持镜像。

curl -fsSL get.docker.com -o get-docker.sh

sudo sh get-docker.sh –mirror Aliyun

Gatling是一个基于Scala，Akka和Netty的开源负载和性能测试框架，从功能上和JMeter很类似，只不过因为是基于DSL书写，从配置上来说灵活性比较好，当然相对的上手难度其实要大一些。

最近项目上使用了一下Gatling，用的时候还是遇到一些小问题。

Gradle插件运行

Gatling官网的运行方式是下载整个Gatling，然后编写脚本以后，直接运行。这个操作不是很方便的，找到一个Gradle插件可以快速运行，其中Gatling的版本，参数等都可以通过build.gradle的参数配置，使用上是比较灵活的。

插件的配置如下：

plugins {
    id 'scala'
    id "com.github.lkishalmi.gatling" version "3.0.2"
}

gatling {
    toolVersion = '3.0.0'
    jvmArgs = [ '-server', '-Xms512M', '-Xmx512M' ]
    simulations = {
        include "**/*.scala"
    }
}

目录结构的要求是src/gatling/simulations，这个需要自己改一下

读取配置

配置可以是很多东西，比如比较常见的是不同环境不同的数据，比如URL，用户认证信息，或者是压测的压力情况都应该在配置，而不是硬编码在代码中。

配置文件地址src/galting/resource/application.properties

使用的时候直接调用

val conf = ConfigFactory.load()
val httpConf = http.baseUrl(conf.getString("baseUrl"))
  ...
  ...

配置的内容可以文本，也可以是数字等。

参数传递

有时候测试一些API需要有关联，会存在一些参数传递。比如首先调用创建API，获取返回值中的id，然后测试修改API，需要在请求数据中包含该id。

Gatling提供的方法是session，可以自己写入，也可以从返回中提取。

val xx = scenario("XX管理")
    .exec(
      http("新建XX")
        .post("/xx/create")
        .check(status.is(200))
        .check(jsonPath("$.code").is("0"))
        .check(jsonPath("$.data.id").saveAs("xxId"))
    )
    .exec(
      http("更新XX")
        .post("/xx/update")
        .formParam("id", session => session("xxId").as[Int])
        .check(status.is(200))
        .check(jsonPath("$.code").is("0"))
    )

然后需要把session中的值注入请求中，而请求比较大，是存放在文件中的，可以使用ElFileBody

.exec { session => session.set("title", "标题" + ThreadLocalRandom.current.nextInt(10000)) }
  .exec(
    http("添加内容")
      .post("/content/save")
      .body(ElFileBody("json/save.json")).asJson
      .check(status.is(200))
  )

用户配置

Gatling可以指定模拟的用户量，比较简单的是atOnceUsers，这是一次性模拟一定数量的用户，但是很多时候我们需要一个缓慢增长的过程，比如用户在3秒中从1增加到100

setUp(
    scn.inject(
        rampUsers(10) over (5 seconds), 
        constantUsersPerSec(20) during (15 seconds), 
        rampUsersPerSec(10) to 20 during (10 minutes), 
        splitUsers(1000) into (rampUsers(10) over (10 seconds)) separatedBy (10 seconds),
        heavisideUsers(1000) over (20 seconds)
    ).protocols(httpConf)
)

具体用哪种看情况，但是一定要引入如下的包，不然seconds这些时间控制会一直报错

import scala.concurrent.duration._

Gatling测试结果

Gatling的默认测试结果是一个网页，可视化效果比起来JMeter要方便不上，但是有时候需要自定义的情况，可以直接从Gatling的结果文件中进行加工。以下是一些加工效果