目前产品还没有实现 数据路由（数据路由的概念见上一篇博客： http://kyfxbl.iteye.com/blog/1901642），所以这就限定了 一套应用，只能操作一套数据库表
现在要实现多项目集中部署，就只有2种办法：
方法1
把多项目的数据放在同一套表里，用字段来区分。这是产品当前的做法，也是大部分网站的做法（因为网站的大部分数据必须共享，不能隔离）
这种办法的优点，是应用和数据库都只有1套（不考虑伸缩的情况下），不需要重复部署，硬件成本比较低
但是缺点是，数据增多以后，数据库IO会成为瓶颈，无法接入新的项目。由于我们产品是企业应用，所以有一个折中的办法，就是再部署一套应用+数据库，来放新的项目
如上图，2套应用环境是完全隔离的，app1无法访问database2的数据，网站显然是不能这么处理的，但是我们可以这么做
方法2
每个项目一套表，为每个项目部署一套完整的应用
跟上面相反，这种方法的优点是每个项目有自己的数据库，等于是提前分表了，性能比较好；缺点是需要大量的硬件，成本非常高
这里数据库隔离，可以是以schema区分，放在同一个数据库里；也可能直接放在不同的数据库里。前者稍微节省了一点db server的硬件，本质上是一样的。app server无论如何节省不了
结论：
受限于 “应用只能访问一套数据库”，无论哪个方案，app server都存在浪费。区别只是，第一种方法用增加项目标识的做法，把N个项目的数据放在了一个数据库里，所以app server的数量，也可以除以N。其实本质上是一样的
另外，多套数据库，并不是一定放在不同的db server里，也可以用schema区分，放在同一个db server里
本质的分水岭，还是在于能否让一套应用透明地访问多套数据库。所以最终的方案还是需要实现数据路由，届时就可以用下面的方式来部署：
把业务表拆分，按需扩容db server。app server很长时间都只需要一台（HTTP并发很低），有需要的话再水平伸缩