PaaS平台上多租户的数据拓展(自定义)

  SaaS系统风云一时,PaaS平台方兴未艾.各种标识为云计算的服务更是多于牛毛.在这篇文章中不会就云,PaaS,或SaaS做任何讨论,只想为多租户情况下的数据拓展设计一套解决方案.

   人们总是渴望自由,追求个性,SaaS尽管为大多数公司的通用应用提供了解决方式,但是这不足以吸引客户.因为客户除了需要很Basic的功能外.还需一些满足个性,符合实际情况的定制.比如.对于User. 除了常用的姓名\性别\年龄等,对于客户A,他可能希望里面还记录有"电话",而对于公司B,他可能还希望记录薪水等级等.这样的需求会层出不穷.我们可以有余下几种解决办法:

• 1.为每个客户的需求定制化相应的Java代码,这显然不可取.应为每次的变动都会带来代码的修改,如果客户量大,这将为系统的稳定和优化带来无穷的隐患,同时也基本上是不可能完成的任务.
• 2.为每张表设计时预留一定量的字段.然后需要拓展的时候,使用预留指端.这种方案能解决部分问题,但是如果真应用面对的真的是千差万别的客户,那预留多少字段合适呢?太少不能够用,太多,又必须考虑性能,维护的复杂性.等等.
• 3.为每张基本表表建立拓展表,比如一百列的,通用类型种占个二三十列.然后写程序的时候总是附带上查询拓展表.这种情况下有两个比较明显的缺点,拓展的数量有限制,查询是浪费了许多性能.而且对于分库分表时,会很难进行.同时程序必须对拓展表有感知.

    我们在实际使用中,为了解决不可预知的拓展问题,同时方便在运行时动态拓展,并综合分析了以上几种解决方案后,我们决定自己实现数据访问层.定义了一套数据访问接口,支持Sql和实体的增删改查!取代Hibernate,支持分库分表,动态路由.映射对象.同时也是最关键的是代码在编写阶段根本不会感知拓展数据的存在,同时也从开发和运行过程中实现了拓展方案的变更.

   举一个实际的例子来说: 我们有一个User表,然后又个客户希望上面拓展一个mail的属性,那么他可以在运行时定义这个拓展,我们可能把这个属性放在ext表的ext1字段上,但是对于程序员来说,他在编码阶段可以根本不关心这些.最终的结果中却包含相关拓展信息.而在二次开发阶段他的Sql代码也只需要是Select username,mail from user!而不是
select u.username,e.mail from user u left join ext e on ...

这个好处不言而寓. 假如有一天我们觉得mail很通用,那好 ,我们直接alter user表,加上mail字段,然后移过来所有在拓展表中的数据即可.整过过程中,我们我用重启服务器,简单得就像你只是在访问普通的页面. 同时,这种屏蔽,也为我们的优化带来了可能,我们可以把同一张表的多个拓展字段在运营的过程中移到同一张表中!

当然,任何一个方案都不能完美的解决所有问题,必须结合其他解决方案配合使用! 但是数据层面的拓展已经得到了完美解决.展示层我们用了另外的解决方案.

评论

2 楼 ztian 2011-08-24  

wanglei871103 写道

写得很好，这个问题也很普遍，但是是如何实现的数据访问层，能否详细说明呢？

我会在接下来的几篇文章中详细分析的.

1 楼 wanglei871103 2011-07-29  

写得很好，这个问题也很普遍，但是是如何实现的数据访问层，能否详细说明呢？