阿里云效上hsf对切发布（无损上线hsf）的测试记录

项目上线一年多，发布流程还是强行关闭+重启，一问都说hsf做不了优雅下线，我疑惑，阿里再怎么菜，也不会连对切发布都做不到吧？对于软件项目，这应该是跟呼吸同样重要的功能。

于是我调查了EDAS文档，发现有无损上线hsf应用的功能，问了下运维，说这不是真的无损，还是会有hsf中断的现象，领导也开始计划要提前灰度环境的实施计划，以完成无损上线的目标（这将是一场资源浪费，但是别无他法）。我不信，一定要眼见为实试一试。

发动口才说服了运维，他把文档里面的步骤都做了。

这个无损上线归根结底还是多台负载机对切发布。公司里只有线上项目有负载，刚好组内有两个废弃的线上项目，我可以拿来测试。

step1 http请求不能挂

加上了文档说的健康检查/health接口，发布上线，然后每秒轮询这个接口（虽然是健康检查接口，但是跟其他http接口别无二致）

上线期间一秒都没挂，完美

step2 hsf请求不能挂

这个是最重要的，请求出去的不要紧（大概），请求进来必须正常处理并且返回，这样才能在不停机的状态下发版，用户开心，咱开发也不慌。
于是我在被测项目上写了个跑10秒的发呆的hsf方法（正常业务方法能跑10秒已经很难得了）

然后在另一个项目中调用了这个hsf接口，暴露出http接口。

这样，就完成了对于hsf的测试环境。

测试结果

6个http请求轮流调用。发布期间均成功返回，可见该【无损上线】流程应该没有问题

step3 挂了（尽量）能恢复

虽然整套流程没有什么问题，但是那也是在我的知识范围内的，我是一个非常胆小的技术人，因此还必须加装最后手段。
业务方法外面原来有aop，本来是打印hsf请求的tracelog的，现在要给他另一个重任：记录运行中的hsf线程。

这段代码跟对付并发的差不多，请求来了记一笔，处理完了删除那笔记录，只是没用setnx而是普通的put，而且多记录了时间戳、hsf线程id，这样就不会有去重的功能了。

上面都是键，值是放请求内容，这样就可以在服务器中断的时候提供更多的信息用来修数据。

伪代码：
around(pjp){
key = “RUNNING:” + pjp.getSignature().getDeclaringTypeName() +"-" + HH:mm:ss:SSS + “-” + traceId
redis.put(key, pjp.getArgs()) // 记录请求
try{ pjp.proceed() }catch(e){} // 执行业务代码
redis.del(key) // 删除请求
}

然后就是正式上线目标项目了，keys里面RUNNING:*的key没有一直赖着不走的，那就说明无损上线成功了。