多项目的实现和部署方式

昨天那个“多租户”的话题，今天继续跟同事讨论了一下，把思路整理得更明确一点：

目前产品还没有实现数据路由（数据路由的概念见上一篇博客：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并发很低），有需要的话再水平伸缩

评论

3 楼 kyfxbl 2013-07-11  

vavi 写道

刚刚在散步的时候，我也在想这个问题。我觉得不仅仅需要从技术上考虑，还需要从业务上考虑。

我是赞成表上加一个项目字段的。

下面是我的分析：
“一套系统支持多项目”我觉得这个需求的出发点应该是“目前及很长一段时间内数据量不会太大”。如果未来某个项目数据较大的，可以将其单独安装一套独立的app和db，专门给单项目使用；如果前者也达到瓶颈了，我觉得再具体问题具体分析，比如是否考虑SSD,RAC啥的。

目前重点还是应该解决业务问题，在目前产品的企业应用中谈高性能，架构可扩展，长治久安，我感觉有点不现实，不靠谱。

淘宝的架构在不断的进化，演进中，我们目前的很多问题只是空想（当然，我心中也有个疑问，假如是存在slave数据库的话，究竟多大数据量的情况下，单DB会撑不住。然后结合目前可能的数据增长规模，再做些评估，预测）。 并且很多网上问题不是架构问题，而是业务细节实现问题。

细节落实不到位，架构再NB也不行。

欢迎讨论哈。

另外特别同意你说的“细节落实不到位，架构再NB也不行”，我们现在不就是这个问题吗，呵呵，架构师太NB了，什么都敢说

2 楼 kyfxbl 2013-07-11  

vavi 写道

刚刚在散步的时候，我也在想这个问题。我觉得不仅仅需要从技术上考虑，还需要从业务上考虑。

我是赞成表上加一个项目字段的。

下面是我的分析：
“一套系统支持多项目”我觉得这个需求的出发点应该是“目前及很长一段时间内数据量不会太大”。如果未来某个项目数据较大的，可以将其单独安装一套独立的app和db，专门给单项目使用；如果前者也达到瓶颈了，我觉得再具体问题具体分析，比如是否考虑SSD,RAC啥的。

目前重点还是应该解决业务问题，在目前产品的企业应用中谈高性能，架构可扩展，长治久安，我感觉有点不现实，不靠谱。

淘宝的架构在不断的进化，演进中，我们目前的很多问题只是空想（当然，我心中也有个疑问，假如是存在slave数据库的话，究竟多大数据量的情况下，单DB会撑不住。然后结合目前可能的数据增长规模，再做些评估，预测）。 并且很多网上问题不是架构问题，而是业务细节实现问题。

细节落实不到位，架构再NB也不行。

欢迎讨论哈。

非常赞同，目前我们的产品还是应该更多地考虑业务问题。去过几个项目看过，应用情况惨不忍睹。在这种情况下，谈高性能和伸缩，确实有点脱离实际

不过最近会考虑这个问题，倒也不是完全因为在空想。主要是上上周听了淘宝的一个分享，引申开的。另外最近不是派我去验证云部署嘛，跟这事也有关系，2者一联系，就想到了这个话题

1 楼 vavi 2013-07-10  

刚刚在散步的时候，我也在想这个问题。我觉得不仅仅需要从技术上考虑，还需要从业务上考虑。

我是赞成表上加一个项目字段的。

下面是我的分析：
“一套系统支持多项目”我觉得这个需求的出发点应该是“目前及很长一段时间内数据量不会太大”。如果未来某个项目数据较大的，可以将其单独安装一套独立的app和db，专门给单项目使用；如果前者也达到瓶颈了，我觉得再具体问题具体分析，比如是否考虑SSD,RAC啥的。

目前重点还是应该解决业务问题，在目前产品的企业应用中谈高性能，架构可扩展，长治久安，我感觉有点不现实，不靠谱。

淘宝的架构在不断的进化，演进中，我们目前的很多问题只是空想（当然，我心中也有个疑问，假如是存在slave数据库的话，究竟多大数据量的情况下，单DB会撑不住。然后结合目前可能的数据增长规模，再做些评估，预测）。 并且很多网上问题不是架构问题，而是业务细节实现问题。

细节落实不到位，架构再NB也不行。

欢迎讨论哈。