继续之前的分析 kingshard的连接问题调查(一) 中的推测，是由于JDBC的connection pool中的链接失效导致发生如下错误
communications link failure the last packet sent successfully to the server was 0 milliseconds ago
为了验证这个推测，在本地模拟了一个测试场景，具体如下：
当过了30秒之后，Mysql服务端就有如下的日志信息：
文章ApacheHttpClient的连接池引起Jetty工作线程被耗尽 中提到的，
如果应用中没有对如下代码中：
HttpResponse response = httpClient.execute(httpHost, httpPost);
response 对象执行如下方法，释放链接：
EntityUtils.consumeQuietly(response.getEntity());
就会导致connection不能回归到connection pool中。
今天对这些不能回归的connection从系统层面进行分析，
看看是处于什么状态。
模拟多次接口调用后，Jetty的工作线程都阻塞在 connectionPool中的get方法调用上：
大家好，我是王震华，从事IT行业有12年的历史，这个博客主要记录我工作、生活中的 所思所想，有些观点可能不正确，甚至有些偏激，所以请读者独立思考，去伪存真。
邮件地址: weiyan.2017@yandex.com
在基于Spring Boot开发的项目中，为了便于后期的维护， 需要将项目按照模块进行划分，先将项目按照业务逻辑模块进行划分， 然后根据划分的业务模块再基于Maven的Module形式组织工程。
下面主要记录我将UC项目中单Module的Spring Boot工程，调整成多Module的形式的过程， 以及碰到的问题和解决过程。
将项目按照如下三个大的module进行划分： API/Core/Web， 其中API定义所有的模块的行为但是不定义如何实现的，Core是基于API中接口的具体实现， Web是提供Http接口服务模块。基于这个边界的定义，自然我们就有如下的上下关系：
web
^
|
|
core
^
|
|
api
API模块举例说明，比如我们在该模块中，有一个子模块为api-authentication， 该模块主要定义了和用户认证逻辑的所有业务接口，比如：
kingshard是一个基于mysql读写分离的中间件，公司目前按照目前的体量和发展速度， 急需要一个能够支持读写分离的中间件支撑业务的发展需要，在各种背景下，我们目前选择了 kingshard作为首先验证的一个中间件。 为了验证kingshard的稳定性，先在内网的环境部署kingshard服务， 然后让项目使用kingshard进行验证，内网的开发环境、测试环境都是使用频次比较高的环境，打算在这两个环境中验证1-2个星期看稳定性如何。在这个过程中频繁出现如下的 错误：
12月20日下午2点到4点左右，商城商品的商品评论不能被加载出来，当时生产环境有3个商品服务的实例，根据日志报错信息来看，有大量的超时
报错信息，超时是由于调用用户中心的服务接口导致的，再排查用户中心的服务的状态，发现用户中心的3个服务的网络流量比平时都大了10倍，
为了尽快恢复服务，将用户中心的服务再平行扩展出一个节点，然后再将商品评论的3个服务中的两个重启，保留一个服务作为问题调查的现场。然后线上
圣诞节快到了，小王要快递寄送一个礼物给他的女朋友小于， 他先在商品精心挑选了一个礼物后，然后又用彩纸将礼物 精心包裹起来。然后再打电话给快递员小张上门收快递， 小张收到要寄送的物品后，又用快递专用的盒子将小王的 礼物包裹起来，最后在包裹外面贴上快递单，包含如下信息：
目的地址
发送地址
发件人
收件人
发件人联系电话
收件人联系电话
到此为止，发送的环节都已经结束了。
快递公司收到快递后经过内部的分包和合包转运过程， 将礼物送到了小于的手上。小于先将快递公司的包装解拆掉， 再将小王的彩纸包装拆掉，然后就看到了小王送的圣诞礼物。
寄送快递时的步骤是封包过程，收取快递是一个解包过程， 这是现实生活中的一个例子。而我们的IP包也有一个同样的过程， 数据发送方先将原始数据组织好，然后通过TCP/IP 协议在每一层 进行封包，经过分组协议交换传输后，到达应用接受方，接受方 再一层层的解包，最后取到原始信息
在一个组织中，我们经常会看到有小组长、 项目经理、总监这些角色，每个角色的管理范围都不一样， 小组长管理自己手下的几个人，项目经理管理手下几个组长，总监负责管理手下的几个PM， 这种组织架构就是分层的概念的体现。
分层设计的好处是，每个人都有一个明确的汇报对象， 总监只需要问责几个PM就可以把所有的事情梳理清楚， 而无需过问到每一个具体一线员工。 试想如果不是这样的汇报机制， 我们假设有10个事情是总监在推进的， 这10个事情需要10个开发人员负责实施， 其中每个事情都有交叉协作的地方， 如果没有PM、小组长这两层，总监需要关注很多人和事， 精力就会分散在各个事情的细节上， 注意力都纠结在局部事情上， 无暇从全局考虑事情，所以最后也可能不会有一个好整体结果,所以进行分层的汇报机制设计是很有必要的事情。
今天项目发布正式环境，在生产环境执行flyway的db migration脚本的时后，出现了如下的错误
caused by java.sql.sqlexception statement violates GTID consistency create temporary table and drop temporary table can nonly be executed outside transactional conext
经过分析这是由于mysql开启了GTID的特性导致db migration脚本中的如下开头语句都报错
CREATE TEMPORARY TABLE ....
这个语句存在的目的是为了从一个表迁移数据到另外一个表中，然后再删除该临时表。