Hibernate性能问题思考

为什么80%的码农都做不了架构师？>>>   

对于古董级别的项目底层采用的ORM框架是Hibernate，数据源配置>=2(数据库过度设计，将定义表名、字段、类型等都通过数据库去存储，使用时查表构进行Java bean翻译构造，上层通过代码封装提供数据库访问的jar包实现了业务操作只需要传入表名、查询字段、条件就可以统一获取结果)。对于这样的项目完全是JDBC的套路，但是却使用了Hibernate，有点不可思议，系统根本不存在所谓的entity。系统内大量使用视图、存储过程来实现查询性能方面的提升，查询只有条件没有边界，这个数据库有多少你都可以查，这样的效率实在是没有保障。

现状

数据库执行逻辑

1、查询数据源

2、构造数据表Java Bean

3、执行业务SQL CRUD

业务CRUD逻辑

1、确定业务表名、构造SQL、输出字段

2、执行业务方法

思考

1、是否推翻底层数据库访问设计？不现实：因为业务上开发重构很多项目都基于此。

2、Hibernate是否要背锅？Hibernate的使用关系匹配、懒加载都没有用到，ehcache也只是对元数据表进行了缓存确实不能怪人家。

3、业务代码优化？这部分其实影响其实并不严重改造空间不大，许多业务除了移动端接口外都是用过DWR直接调用的Java封装。

改造

主要有以下点：
1、代码优化：比如依据代码检查findbugs进行方法重构等。
2、服务拆分：将移动端和后台管理系统分开部署，方便跟踪服务不可用问题，若分开部署依然出现可能是基础包ORM的问题。
3、业务操作：我认为系统内部的业务代码应该不是致命问题，还是在于基础封装包，可以对此包做深入研究。

转载于:https://my.oschina.net/boonya/blog/3013037