单租户与多租户 SAAS
单租户与多租户 SAAS
原文：https://medium.com/hackernoon/exploring-single-tenant-architectures-57c64e99eece
快速—说出一个你知道的使用单租户架构的创业公司。有吗？是啊，我也是。
如今，多租户架构是运营初创公司的标准方式。创建一个数据库，配置一些服务器，添加一个负载均衡器，再加上一些缓存，然后就到此为止。
但是为什么呢？
多租户优于单租户的地方在哪里？是成本吗？复杂？保安？尺度？
最近，我开始开发一个新产品，多租户架构感觉非常复杂。必须有一个更好的解决方案——一种更快的启动和运行方式，不会给我们以后带来扩展问题。
现在，我实话实说。我已经开发软件和运营网站 15 年了，我从来没有处理过“互联网规模”的问题。见鬼，我甚至几乎不用处理缓存。在过去的五年里，我一直在研究 Kumu，除了 embeds 之外，Kumu 的流量可以由一台大型服务器处理。这是一个强大的、复杂的工具，增长一直很稳定，但它不是那种会像病毒一样传播的东西。
我们期待指南针会是一个不同的故事。
Compass 帮助您可视化您的松散团队的沟通。与 Kumu 不同——在 Kumu 中，你从小规模开始，逐步积累数据，并在浏览器中本地处理大多数计算——Compass 在你注册的第二秒钟就接入数据的消防软管，大多数计算在服务器端处理。
Compass 可能永远不会达到我们预期的规模，但如果达到了，我们也要做好准备。如果它像病毒一样传播，我们不想在半夜被叫醒去灭火。我们有的生活，还有的妻子，还有的孩子，还有的爱好，还有许多 其他 我们更愿意做的事情。比如睡觉。(至少在努力。)
因此，我们没有试图构建一个应该扩展的系统，而是提前投入一些时间让设计一个任何规模的系统:一个旨在消除等式中的规模的系统(或者至少让它成为其他人的责任)。
为此，我们一直在探索 AWS 之上的两种潜在架构:
- 多租户(典型的 SAAS 模式，支持共享资源池中的所有团队，如负载平衡器、网关、子网、kinesis、lambdas、redshift、ECS、EC2、自动扩展组、安全组、cloudfront 等— 老实说，如果我要列出所需的每项 AWS 资源，会有几十项—这就是探索更简单的单租户架构的原因
- 单租户(每个团队都有一个专用的 EC2 实例，直接暴露在互联网上，一切都通过 Docker 在本地运行)
本文的剩余部分将探讨我们在这两种架构之间的权衡。如果有我们错过的大事件，请在评论中提及！
费用
作为一家自举创业公司，成本是一个很大的问题。如果做错了，它会在你走出大门之前就让你残废。做对了，你就可以在沙滩上啜饮鸡尾酒，而你仍然穿着泳衣。(或者你可以有效地利用这笔钱来创造就业机会和增加产品。你是老板。)
对于多租户架构，运行系统的成本是固定的。你预先支付了很多，但好消息是你每增加一个新客户都会降低增加下一个客户的边际成本。除了客户支持之外，增加新客户并不会让你付出任何代价。
对于单租户架构，增加新客户的边际成本永远不会下降。搞定了。每个新客户都需要一个新实例，而每个新实例都需要付费。更糟糕的是，每个客户的成本实际上是上升的！更大的团队需要更大的实例。虽然我们可能能够在 t2.nano 上支持 10 到 20 人的团队，但我们需要一个更大的实例来支持拥有数百名成员的团队。
因此，由于多租户降低了每个客户的成本，它显然是赢家，对吗？
嗯……不，不完全是。
除了底层基础设施的成本，还有这些叫做的东西。而且它们很贵。
单租户架构是一种更简单的架构，具有更少的移动部件。较小的团队可以支持较简单的系统。这些团队可以由开发人员组成，而不是专门的系统管理员——这与您已经在本地运行的开发系统完全相同。
这让我们想到了下一个问题:平价。
平价
奇偶校验是环境之间相似性的概念。多租户架构的一个主要缺点是我们需要支持的环境之间缺乏对等性:
- 开发 (一切都在你自己的机器上本地运行)
- staging (一切都在云中运行，但没有设计成可扩展的)
- 生产
- 企业 (一切都在人家机器上运行)
这些环境中的每一个都有其自身的复杂性。把它们加在一起，就很清楚为什么系统管理员能拿到高薪了。
您可能会说您并不真正需要一个暂存环境。因为这就是测试的目的，对吗？
你也可以说，在这个阶段担心内部部署的企业版本还为时过早。在很多情况下你是对的。但是在 Compass 的例子中，我们正在处理包含敏感信息的消息。因此，我们已经收到了内部版本的请求。因为企业客户通常是你最大和最忠诚的客户，我们不把他们纳入我们的初始规划是愚蠢的。
单租户显然是赢家，因为它为您提供了跨所有环境的平等性和通往企业的便捷之路。作为一个资源有限的小团队，我们认为这相当不错。
维护
对于多租户，部署通常是全有或全无。多租户系统的维护可能会很可怕。您只需推出一个更新，每个客户都会立即使用新系统。如果你搞砸了，你就拖垮了整个系统。去过那里，做过那个。发生的时候可不好玩。
对于单租户，维护是增量式的。如果你搞砸了，通常只会搞垮一个团队。您不是部署单个应用程序更新，而是部署 N 个应用程序更新。不是迁移一个数据库，而是迁移 N 个数据库。从表面上看，这听起来会给你带来更多的工作，但是由于系统是孤立的和相同的，大部分工作可以自动化。您需要的只是一些工具来编排更新。
单租户维护的一个美丽的副作用是，你可以免费获得增量部署和有针对性的测试版本。没有必要摆弄负载平衡器或修改内部特性标志。
弹性
这两种架构都提供了自己的弹性形式。
多租户在团队层面创造弹性。每个团队由多个实例提供服务，分布在多个地区/区域，并由负载平衡器托管。除非出现系统范围的中断，否则团队不太可能遇到问题。
单租户在系统层面创造弹性。 除了 DNS 级别的 DDOS 攻击之外很少有方法可以让整个系统瘫痪。一个团队可能会遇到问题，但是这些问题不太可能超出那个单一的实例。
为了应对灾难，我们可以加入 EBS 备份、健康检查和恢复实例，该实例可以将松弛事件填充到队列中，直到配置了新的服务器。现在，我们在团队和系统层面都有了一个简单、有弹性的系统。
Team and system resilience? Yesssss
另外，一般来说，一个愤怒的顾客比一群愤怒的暴民更容易应付。因此，在这里为单租户再记一笔。
恢复
在 Kumu 上，每个项目都有一个独立的 CouchDB 数据库支持。多年来，我们发现这种隔离非常有价值。有时我们会把事情搞砸。有时候顾客会把事情搞砸。不管是谁的错，当每个客户的数据被物理隔离时，灾难恢复会容易得多，而不是简单地在单个数据库中进行逻辑隔离。数据库恢复变成了简单的文件系统副本，而不是脆弱、复杂的数据库查询。
安全性
就我而言，简单是最好的安全。复杂的系统经常给人一种不真实的安全错觉。
如果所有的东西都在一台机器上本地运行，并且该机器被基于密钥的 SSH 访问锁定，并且该机器暴露的唯一另一个端口是端口 443——那么我不会因为担心安全漏洞而在晚上失眠。
是的，机器直接暴露在互联网上。但是只要系统的任何部分暴露在外，直接暴露并不必然比间接暴露更不安全。你很容易搞砸任何一个。
如果两个系统有相似的曝光度，而其中一个明显更简单，我每次都会选择更简单的系统。表面积更小。复杂性降低。更容易审计。售出。
结论
和大多数事情一样，这里没有圣杯。这两种架构各有利弊，都是正确问题的可靠解决方案。我过去一直使用多租户架构，但在这种情况下，它不像是适合工作的合适工具。
最终，作为工程师，我们的工作是找到优先级和约束之间的最佳结合点。对于 Compass 来说，最佳选择似乎是单租户。
对于多租户也有一个强有力的论点，但是现在，每个团队一个实例看起来是启动和运行的最快方式，同时最小化扩展问题。同样重要的是要注意，如果我们希望允许跨团队分析，单租户甚至不是一个选项。也就是说，以下是单租户为 Compass 提供的主要优势:
- 我们可以使用我们在开发中使用的相同 docker 容器来运行生产中的东西。
- 我们可以在测试阶段开发新功能并收集反馈时，逐个团队地推出更新。
- 我们可以在地理位置上靠近客户的地方调配实例，提高响应能力，同时避免对 CDN 的需求。
- 我们可以通过物理隔离每个团队的数据来缓解隐私问题。
- 由于我们没有免费计划，我们不介意每个月花几块钱来支持每个团队(特别是如果这样可以降低运营复杂性并缩短发布时间)。
这就是我们的现状。在这一点上，指南针只是一个原型，但我们希望在未来几周内建立后端。如果你有一个活跃的 Slack 团队，并且你有兴趣成为一名 beta 测试员，请告诉我！你可以通过推特上的 [email protected] 或 @rymohr 联系我。
您有大规模运行单租户架构的经验吗？如果是这样的话，我很乐意在下面的评论或者 HN 上的 相关帖子中听到！
