关于租用模式的架构及数据库设计讨论
像XTOOLS、友商网、伟库网等这种租用模式的在线软件，能支持多客户、多业态并允许不同客户存在部分差异，单台服务器能容纳大量客户，在用户量大时也可以方便的通过增加服务器横向扩展。
1.采用何种数据库？
2.数据库如何设计,按客户划分还是按业务划分，多客户同一数据库还是每个客户一个数据库？
3.如果多客户共享同一数据库,如何有效隔离客户数据，避免超越边界访问其它客户数据？
4.如果多客户共享同一数据库,如何实现按客户数据备份、还原、分离？
5.采用何种WEB开发框架？
6.采用何种策略保证不影响系统稳定的情况下满足客制化？
在此抛砖引玉，欢迎讨论。

------解决方案--------------------
表分区

均衡负载 图片服务器 文件服务器 数据库服务器 web服务器
------解决方案--------------------
现在SaaS Multi-Tenant在数据存储上存在三种主要的方案，分别是—
方案一：独立数据库
这是第一种方案，即一个Tenant一个Database（见图3-14），这种方案的用户数据隔离级别最高，安全性最好，但成本也高。
优点：
为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
缺点：
增大了数据库的安装数量，随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。

方案二：共享数据库，隔离数据架构.即多个或所有租户共享Database，但一个Tenant一个Schema。
优点：
为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。
缺点：
如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；如果需要跨租户统计数据，存在一定困难。

方案三：共享数据库，共享数据架构.即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。
优点：
三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原。如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
CRM系统未来将以中低端市场为主，所以采用第三种方案，只要做好数据隔离比较好了。千万不可掉以轻心，SaaS下的安全性设计很重要。一般常见的安全性设计分为两类：系统级和程序级。
系统级：
使用HTTPS协议以SSL（Security Socket Layer）交换数据，增强通信安全；通过数字签名防止传输过程篡改；对用户身份识别的UserToken使用DES算法数据加密；业务数据定时自动备份。
程序级：
完整的权限配置，包括功能权限和数据权限；客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；辅助安全设计，比如密码控件、图片验证码、手机确认码等。
------解决方案--------------------
不知道 是不是你想要的 有没有帮到你
------解决方案--------------------
卷复制/卷镜像

　　通过快照备份仍然无法承受源卷的数据腐坏。ESVA也内置了卷克隆功能的特征从而完成数据库卷的一个完全拷贝。备份卷的大小同于整个源卷的大 小，如果源包含了大量数据这将花很多的时间。卷拷贝是一次性操作，它有助于在一个特定时间复制一个数据库卷到另一个空白空间。卷镜像可以帮助创建一个源镜 像卷，依靠定期分离和同步操作，用户可以保持备份卷与数据卷同步。除了数据保护外，这里的完全备份也能用为数据挖掘、发展和测试创建全部临时数据库环境。

　　远程复制

　　应对断电、硬件故障、人为或自然灾害导致站点完全失效，这时远程复制成为了一种更常见的习惯作法。ESVA的远程复制功能允许用户的备份卷可以跨越不同的阵列、机架甚至数据中心。无论什么样的距离或网络带宽，其他远程端可以通过ESVA创建的副本来远程维护ServerSecurity/Database/'>SQL Server数据库的拷贝。

　　数据库刷新代理

　　在开始备份一个数据库之前，首先把所有数据、执行日志和相关记录从内存刷新磁盘阵列。ESVA提供一个帮助ServerSecurity/Database/'>SQL Server在进行数据保护之前刷新数据的专门的数据库刷新代理，以确保高可用性和数据完整性。

　　日程安排

上述提到的所有数据库保护功能不仅仅允许用户手动操作，ESVA也提供了自动操作机制从而简化和精简了这些数据保护过程。用户能够创建日程安排 任务，例如：周期性的做快照、在一个特定时间开始一个拷贝任务、每隔几天对一个卷对进行同步。当需要时,这些计划可以自动进行数据保护以满足业务的连续 性,达到服务级别目标。

　　ESVA的数据保护技术可以快速完成，也能在不中断应用的情况下在线执行，它能够大幅度增长ServerSecurity/Database/'>SQL Server数据的可用性和为数据库维护提供最大的灵活性。这些功能在健全的ServerSecurity/Database/'>SQL Server保护的情景下起到重大的作用，为保持数据安全提供更有效率和经济的数据保护解决方案。

　　结论

　　ESVA计划提供了一个简化整个存储管理的统一的存储平台。虚拟技术因为可以在线扩展ESVA磁盘阵列系统，所以能够轻松的横向扩展容量和性 能。它为Microsoft ServerSecurity/Database/'>SQL Server数据库存储需求提供了一个卓越的解决方案，为高可用性和可扩展的数据库设计提供了稳定而可靠的存储。ESVA还为本地和远程的基于卷的保护配 备了一些数据保护功能，为ServerSecurity/Database/'>SQL Server的使用提供了一个具有成本效益、易于管理、高扩展性和高可用性的存储环境。


------解决方案--------------------
在我看来,即使是同一个产品,发布给不同的用户后,数据结构是会发生不同的变化的,
而这个变化是客户操作的,我们开发者并不一定知道

所以我希望每个客户拥有自己的数据库

而且一个web应用程序应该有能力随时访问不同的服务器上的不同的数据库,而不需要修改什么webconfig

从服务器运行压力方面,我想:
一个Webserver不够就2个,用户的入口是一致的,由认证服务器分配负载
------解决方案--------------------

探讨

谢谢楼上的回复！
每客户一个数据库能有效隔离客户和方便定制，但一台服务器能容纳的数据库（客户）数量非常有限。

------解决方案--------------------
哦,忘了说了,前提是msSql,其他DBMS我不是很了解
------解决方案--------------------

探讨

现在SaaS Multi-Tenant在数据存储上存在三种主要的方案，分别是—
方案一：独立数据库
这是第一种方案，即一个Tenant一个Database（见图3-14），这种方案的用户数据隔离级别最高，安全性最好，但成本也高。
优点：
为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
缺点：
增大了……

------解决方案--------------------
表分区

均衡负载 图片服务器 文件服务器 数据库服务器 web服务器
------解决方案--------------------
mark, 学习
------解决方案--------------------

------解决方案--------------------
路过学习~
------解决方案--------------------
没有积分啦啊啊啊啊
------解决方案--------------------
学习了
------解决方案--------------------
.....................
------解决方案--------------------
学习学习，呵呵
------解决方案--------------------
顶顶顶顶
------解决方案--------------------
学习。。
------解决方案--------------------
这个得好好学习一下。
------解决方案--------------------
学习学习，顶了
------解决方案--------------------
学习，顶一下！
------解决方案--------------------
这个得好好学习一下。
------解决方案--------------------

探讨

多实例的开销似乎更大。

------解决方案--------------------
学习。
------解决方案--------------------
顶起！！！！

------解决方案--------------------
没看懂....
------解决方案--------------------
支持，学习。
------解决方案--------------------
学习一下 啊
------解决方案--------------------
学习一下 啊
------解决方案--------------------
学习学习
------解决方案--------------------
O(∩_∩)O哈！
------解决方案--------------------
完整的权限配置，包括功能权限和数据权限；客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；辅助安全设计，比如密码控件、图片验证码、手机确认码等
------解决方案--------------------
顶一下。。。
------解决方案--------------------
顶一下
------解决方案--------------------
Mark,等高人出现
------解决方案--------------------
来接分的，最近穷死了
------解决方案--------------------
楼上的观点觉个觉的不是很好。
baidu 下Shard架构
------解决方案--------------------
好东西，看看了
------解决方案--------------------
好帖 顶起来
这个总结起来还真不容易啦
------解决方案--------------------
不懂 我觉得你说得好像不太对
------解决方案--------------------
谢谢,很好东西,一直在找呢
------解决方案--------------------
学习。。。
------解决方案--------------------
fdsafda
------解决方案--------------------
http://www.blogjava.net/BlueDavy/archive/2009/07/24/288055.html 
可以参考一下ebay对于网站架构的设计，很多方面都又典型性
------解决方案--------------------
不错，学习中！
------解决方案--------------------
454545
------解决方案--------------------
好，实在太好了
------解决方案--------------------
同一个版本的MSSQL在同一个操作系统上可以多实例吗？

我个人觉得一般情况下客户的数据是分开存储好一些，如果都存储在同一张表，通过编码来实现数据呈现，
会涉及到权限问题。另外最主要从安全上考虑，并不能绝对保证编码不出错，而这种错误一旦出了是很严重的！
所以建议一个客户一个数据库，当然缺点就是代码更新维护起来麻烦一点，但是相对来说编个维护更新工具应该不难 

至于多个客户数据的统计问题，这个一般可以考虑建一个统计数据库（数据仓库我不懂）
先汇总各个客户数据库数据到这个数据库，再做二次统计，或者直接写复杂SQL实现

探讨

引用:
多实例的开销似乎更大。

有时候,只有你实际参与大量客户的DBMS的设计的时候,你才会发现,有些平时想当然的结论其实是恰恰相反的,
比如:在每个单方面上,有特殊要求的用户总是少数,
设计通用的DB的开销远远大于拆分设计,
而增加一个实例的开销是很低的,就连我的笔记本(赛扬1.6G/2G内存)还能顺畅的跑3个实例超过30个数据库,
还有一点,我说的并不……

------解决方案--------------------
xinyu207的胡言乱语：

1.采用何种数据库？
数据库产品本身不是问题，现在主流数据库都可以，有预算oralce 没预算mysql 逻辑设计上JiuchunYoung给出了很好的答案

2.数据库如何设计,按客户划分还是按业务划分，多客户同一数据库还是每个客户一个数据库？
zzxap说的不错 表分区 （参考Myspace的架构升级之路 http://tieba.baidu.com/f?kz=184775532）

3.如果多客户共享同一数据库,如何有效隔离客户数据，避免超越边界访问其它客户数据？
Schema
4.如果多客户共享同一数据库,如何实现按客户数据备份、还原、分离？
需要自己开发了
5.采用何种WEB开发框架？
下面是道听途说的..
选择前端负载服务器（nginx） 独立的静态资源服务器（lighttpd 处理js，img,html) 引入缓存服务器减少网络消耗（Memcache）应用服务器使用Apache 开发语言Php python 


6.采用何种策略保证不影响系统稳定的情况下满足客制化？
客制化?


------解决方案--------------------
学习，谢谢，对我有些帮助
------解决方案--------------------
关注中。。。
------解决方案--------------------
我开发过一款SaaS的产品，是仿salesforce.com的CRM，简化版本，
关于实现，MS有一个小示例程序Crab，你可以参考下其中的一些实现。
这个一时半会说不清楚，我们20个人的团队做了两年