在Druid数据库连接池中有两个参数，分别为： testWhileIdle，timeBetweenEvictionRunsMillis 根据字面意思理解是连接池会定时的对处于idle状态的连接进行一次存活检测， 目的是为了防止返回一个已经关闭的JDBC的连接给应用使用。 但是在本地验证该参数的行为的时后，发现并不是如上的期望。 如果配置了该参数，Druid会在每一次应用获取连接的时后，进行一次存活检测， 如果发现连接不可用，那么就从connection pool中重新获取一个connection返回给应用。 如下是本地的验证的一个过程。
在本地启动Java应用，应用直连数据库，配置Druid每间隔30秒进行一次链接检测， 配置数据库的max_timeout为60秒，validationQuery为SELECT 1，如下：
继续之前的分析 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、小组长这两层，总监需要关注很多人和事， 精力就会分散在各个事情的细节上， 注意力都纠结在局部事情上， 无暇从全局考虑事情，所以最后也可能不会有一个好整体结果,所以进行分层的汇报机制设计是很有必要的事情。