最近一直比较关注分布式事务相关的内容，恰好阿里开源了GTS的开源实现 Fescar 。阿里的背书是Java届非常认可的，所以项目本身短短时间便收到了将近6k的star ⭐。抱着学习的心态对它的原理进行了解，同时因为现在的微服务框架Spring Cloud大行其道，所以分析下Fescar 整合Spring Cloud部分的源码机制。本文首发在阿里巴巴中间件公众号。

线上项目需求不停迭代，在版本升级过程中我们要避免请求的失败，整体微服务平滑的升级。我认为一个比较优雅的停机过程应该是，服务在注册中心下线->容器避免接受新请求->等待当前请求持续处理完毕->销毁bean等其余收尾工作。下面我将阐述下较为合理的优雅关机的实现方案。

线上项目采用Spring Cloud作为整套的微服务体系，在微服务体系中，链路追踪是定位问题的绝佳手段。但是我们在引入Sleuth以及Zipkin的过程中发现Ribbon的重试机制发生了改变，导致Ribbon节点的重试到错误节点，引起最终请求失败。花费了几天的定位，发现是Sleuth以及Zipkin引入的Spring-Retry的组件引起的重试的bug，导致本应处于断路状态的节点的状态被错误清除。

现有项目迁移Docker后遇到了GC问题，无论是YGC还是CMSGC，都出现了STW过长的情况，影响到了线上服务。现在将整个优化过程记录下，以做参考。图片内容可能不是当时的现场，因为服务较多而且中间也走了一些弯路导致截图乱掉了，但是情况原因是一致的。