如何为一系列相关但独立的网站构建可扩展的基础设施？
因此，我的公司正在讨论建立一个为许多不同客户提供服务的电子商务平台。每个客户端都有不同的外观和感觉，以及自己的一组用户，但支持代码（即：管理服务、身份验证服务器、结账服务、可能的管理页面等）和一些用户将是共享的，因此错误修复可以同时应用于所有网站，主要管理员可以登录所有网站。
由于整个 StackExchange 网站集（流量相当高）运行在少量服务器（我相信是两台）上，我想知道通过一个 Web 应用程序甚至一个数据库提供许多不相关（但相似）的网站会涉及到什么。
为了拥有一个数据库，我想象每个表都会有一些列来标识实体属于哪个领域，并且每个 SQL 调用都会按该列进行过滤。这似乎会成为维护的噩梦，并且（对我来说不太重要）DBA 的地狱。
另一种选择是使用一个 Web 应用程序，但使用多个数据库，我想该领域可以绑定到特定的数据源，其中可以指定所有非共享数据。然后，当发出任何请求时，可以加载适当的数据源，并且 Web 应用程序将像只有单个源一样运行。这还有一个额外的好处，那就是可以轻松水平扩展，因为在必要时可以生成完全相同的 Web 应用程序，但可以生成一组不同的领域和数据源。只需复制 Web 应用程序并移动数据库，即可轻松将网站迁移到新服务器。
我想知道还有哪些其他可能性，以及具体的例子（如果有的话）。
注意：我不是在谈论 Twitter 规模的可扩展性，也不是在谈论硬件/语言等，而是在谈论设计方法和模式。
So, my company is talking about building an ecommerce platform that will serve many different clients. Each client would have a different look and feel, and its own set of users, but the backing code (ie: adminstration services, authentication servers, checkout services, possibly admin pages, etc.), and some users would be shared, so a bug fix could be applied to all sites at the same time, a primary admin could log into all websites.
As the entire StackExchange set of websites (with pretty high traffic) run off a small number of servers (two I believe) I wonder what it would involve to serve up many unrelated (but similar) websites through one webapp, or even one database.
In order to have one database, I imagine that every table would have columns identifying which realm the entity belonged to, and every SQL call would filter by that column. That seems like it would become an maintenance nightmare, and (less importantly for me) a DBA's hell.
Another option, with one webapp, but multiple databases, I imagine the realm could be tied to a specific data source, where all non-shared data could be specified. Then when any request was made, the appropriate datasource could be loaded and the webapp would run as if there was only single source. This would have an added benefit of being easily horizontally scalable since the exact same webapp, but a different set of realms and datasources, could be spawned when necessary. Websites could be easily moved to new servers as well by simply copying the webapp and moving the database.
I wondering what other possibilities there are, as well as, specific examples if they're out there.
Note: I'm not talking about Twitter-scale scalability, nor about hardware/languages/etc, but rather design methodologies and patterns.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您所说的架构称为“多租户”架构。有差异。构建多租户应用程序的方法。从广义上讲，数据层可以通过 3 种方式构建：
每个都有其自己的优点/缺点。查看 Microsoft 撰写的有关多租户的文章。 http://msdn.microsoft.com/en-us/library/aa479086.aspx
一般来说，我建议选择 3，因为它提供了真正的多租户。如果您有一些表预计会变得非常大，您可以根据 clientid 对该表进行分区（例如：如果您想要 10 个分区，则可以根据 clientid 的 mod 进行分区）
The architecture you are talking about is called "multi-tenant" architecture. There are diff. ways of going about architecting a multi-tenant application. Broadly speaking, data tier can be architected in 3 ways:
Each has its own advantages/ disadvantages. Take a look at this article by Microsoft on multi-tenancy. http://msdn.microsoft.com/en-us/library/aa479086.aspx
Broadly speaking, I would suggest option 3 as it offers true multi-tenancy. If you have some tables that you expect to become very large, you can partition that table based on the clientid (for eg: if you want 10 partitons, you could do partition based on mod of clientid)