J2EE平台SQL查询语句集中管理解决方案（性能预评估、支持集群环境热部署）（一）

J2EE企业级软件架构越来越鼓吹N层体系架构，很多架构师陷入了为架构而架构的怪圈，引入越来越多的没有测试过的开源组件，增加越来越多的适配层，导致系统底层架构没有人能驾驭，平台性能问题一旦出现，就找借口是数据量大、并发访问高，通过加硬件救急！

本文先对Java平台SQL查询语句集中管理提出一个实用方案。其背景是目前的J2EE架构大量使用hibernate等ORM框架，SQL/HQL分散在各模块的Java类中，而且很多采用拼SQL的方式（非预编译即PreparedStatement方式执行），导致至少带来如下两个严重问题：

 

1. SQL性能无法预测，至少运行前无法检测（目前大部分现象都是出现性能问题到生产环境采集SQL，但是由于业务的周期性，存在SQL的覆盖率问题，另外采集毕竟是个相对专业的技术活）；
2. 查询逻辑变化，由于SQL/HQL散落在代码的各个角落，必然导致维护起来很麻烦，且数据库设计人员无法知道程序员的SQL语句是否正确；
3. 不支持热部署，尤其是在集群部署环境下，部署工作运维人员头疼！

解决思路我画了一个图：

 

大概描述一下：

 

1. 由core_query表统一管理SQL查询语句；
2. 开发一个管理界面维护core_sql表，并更新至分布式缓存；
3. 应用启动时从core_query表加载SQL语句至缓存，应用从缓存中获取SQL语句；
4. SQL语句采用命名查询的概念，即每条SQL语句都有一个唯一的名称，可以采用名称空间命名；
5. 应用调用采用spring提供的jdbcTemplate的queryForList(String queryName, Object[] args)方法进行查询，返回类型为：List<Map>，尤其在jstl，显示数据与List<User>完全一致；
6. 每条SQL语句可以扩展支持查询缓存；

实现目标：

1. 事前准确评估性能：所有查询语句统一管理，便于在设计开发阶段准确评估性能问题，避免系统运行过程中出现的性能瓶颈；
2. 查询逻辑变更后维护方便；
3. 支持热部署，支持集群环境热部署；

一些经验：

1. 所有select语句（除通过主键load单条记录外），全部采用命名查询，由core_query表统一存储管理；
2. 单条记录的insert、delete、update和load，可以采用ORM技术，在dao层完成数据库读写；
3. 批量的delete和update语句，采用命名查询方式；
4. 专注查询，避免了 SQL 或者 HQL 代码分散于整个应用程序中的情况；

待续...

 

评论

2 楼 hxl1013 2012-10-09  

之前用过将SQL集中在properties中，和你的差不多意思~只是存储目的地不同而已

1 楼 iwangxiaodong 2012-10-09  

我用的是MyBatis,它采用了xml来统一管理SQL语句,而且,将xml文件纳入Tomcat监视范围可热插拔修改!