关于软件设计的两三事：此“租户”非彼“租户”
梦好莫催醒，由他好处行
作者：闲宇非鱼
公众号：Brucebat的伪技术鱼塘
一、前言
无论是初出茅庐的毛头小子，还是混迹江湖多年的老油条，在成为打工人后大致都会遇到这样一个问题：租房。当然，今天的这篇文章并不是为了讨论租房的问题（毕竟闲宇自己的租房生涯基本都是用血与泪书写的），而是要和大家分享一个软件设计中和租房当中名称相同但意义完全不同的概念：租户。
二、什么是“租户”
租户或者说多租户（Multi-Tenancy）这样一个概念是随着SaaS（软件即服务）模式和云计算技术的发展逐渐形成的。在多租户架构中，基于提高成本效益、提升资源利用、增强可扩展性等目标因素的考量，允许多个独立的客户（部门、组织或者公司）共享同一个应用程序实例及其基础设施，但是每个客户的数据和配置都需要保持独立、相互隔离。这里每个独立的客户，就是租户。
三、为什么需要“租户”
常见的软件类型
到这里，相信大部分人会觉得租户和用户好像并没有太大的区别。那么下面让我们结合实际的使用场景来进一步了解一下到底为什么需要“租户”。
如果我们将市面上的软件根据使用群体来进行分类，可以将其分为以下三类：
ToC：使用者为个人；
ToB：使用者为组织或公司；
混合：使用者为个人或组织或公司；
第三种类型其实可以将其归为第二类当中，毕竟在逻辑上可以将个人作为一个人数为1的组织或公司，所以实际上的软件类型只有ToC和ToB两种类型。
对于ToC类型的软件来说，“用户”就是使用者的唯一粒度，基本不会存在比用户更大的使用者粒度。同时这些使用者所享有的服务、获取的内容基本是一致的（让我们先抛开各种VIP、SVIP的会员机制）。所以完全不需要提供一个更高维度的租户概念来进行数据和配置的隔离，用户维度完全足够处理当前场景。
对于ToB类型的软件来说，早期流行的部署使用方式是（当然现在依然很多）将整套软件部署到客户公司/组织的私有服务器上，然后通过内网方式对整个公司提供软件服务。基于这种方式进行的软件部署和服务提供其实和ToC类型的软件差别并没有太大，但是在软件服务实际推广和维护的时候就会出现非常大的问题。对于ToC类型的软件来说，软件的功能对于所有用户来说都是统一的，更新和维护也是统一的。但是对于独立部署到不同公司的ToB类型的软件来说，软件功能的更新和维护则没有办法做到统一。
早期ToB软件的痛点
出现这样一个情况的原因主要是在于不同公司在最初购买这套ToB软件的时候或多或少都会存在定制化需求，或是功能上的，或是存储要求上的。这就导致在实际交付给对应公司时看似好像是同一款软件，但实际的源代码/配置已经做了非常多的定制化调整。在这样一种存在软件多版本的情况下，软件的版本更新和日常维护就成了一个非常让人头疼的事情。
除了软件功能更新和维护方面的痛点，服务器资源的使用和调整同样也是一个非常让人头疼的问题。这个问题就不单单是让软件开发商感到头疼了，作为软件使用方的客户公司同样会非常头疼。由于不同的公司规模不同，软硬件承载要求也不尽相同，这也就导致了不同公司采购机器的数量和配置也会不同。由于没有办法像现在的弹性扩缩容一样非常简单地就完成服务器资源的调整，所以在一开始确定服务器资源的时候就会非常的慎重，毕竟客户在未来的使用过程中并不希望出现冗余的机器或是经常遇到资源不够的情况。即使在慎之又慎地完成了最初的采购和部署之后，随着公司规模的变化、软件功能的调整，服务器资源依旧会出现需要进行扩缩容等调整的情况，同时这样一个调整也是一个非常痛苦的过程。
多租户架构的优势
可以看到在这种按照组织维度进行软件售卖的时代在IT成本方面可以说是非常巨大的，而这个成本多数又是用在维护而不是软件迭代更新上，这就导致按照这种模式进行的软件开发投入和收益很难达成正比。
而随着互联网基础设施（主要是Web相关技术和网络基础设置）的不断演进、云计算和SaaS模式的不断发展，一个新的ToB软件架构模式的诞生在很大程度上缓解了上面谈到的问题，那就是多租户架构。
相比独立部署的软件架构来说，基于多租户架构开发的软件在软件维护和迭代以及硬件资源管理上都有了很大的提升：
硬件资源管理：在多租户架构中，不同租户贡共享一个应用程序实例及其基础设置。这就意味着所有租户使用的硬件资源都被统一管理（包含硬件的型号也能得到统一），不再需要像独立部署模式中的一样分散管理，运维成本得到了很大程度上的降低。需要注意，多租户架构模式中硬件资源的管理多数情况需要由软件开发商来负责，客户只负责使用对应应用，而在单租户的独立部署模式中很多时候会出现硬件资源需要软件开发商和客户公司协同管理的情况；
软件维护和迭代：在多租户架构中，提供给多个独立租户的应用只存在一个，这就意味着在进行软件开发时需要维护的正式版本也只有一个。对于经历过独立部署模式的开发者而言，这简直就是一个天大的喜讯。毕竟，开发者不需要再费尽心力地去维护不同公司不同版本的软件，不需要在开发相同功能时考虑各种版本、各种不同型号硬件的兼容问题，可以将所有的精力投入到新功能的开发和bug的修复中。产品更新迭代的速度因此得到了极大程度的提升；
四、多租户架构存在的问题
多租户架构就一定优于单租户独立部署模式吗？当然不是。因为在多租户架构中依然存在着许多单租户独立部署模式中不存在的问题。
资源共享带来的竞争问题：多租户架构实际上是一种逻辑隔离，在这个架构中多个独立客户实际是共享一个应用实例及其基础设施，而对应的基础设施资源并不会按照每个租户使用情况进行单独购买并在物理上进行隔离，这就会导致在并发较大或者存在多个资源消耗较大任务时不同租户之间出现基础资源的竞争问题。具体表现为：A租户可以正常使用，但B租户出现等待的情况；
数据安全问题：虽然存在非常多的数据加密手段，但是对于部分客户而言，架设在软件开发公司的服务器或者云服务器依然是不可控的，或者说存在数据泄露安全隐患的。相反，能够独立部署到客户自己公司的模式才是真正满足部分客户对于数据安全需求的模式；
不够定制化问题：相比独立部署模式的软件开发模式，多租户架构的软件会显得不够“定制化”。这里主要体现在两个方面：一个是软件功能上，一个是基础设施的选择上。前者取决于对应客户公司实际使用的需求（可能是某个非常冷门但是该用户非常需要的功能），后者则是基于客户公司对于数据安全或者其他安全问题的考量（比如要求使用该公司内部研发的数据库）；
五、总结
多租户架构可以说是互联网时代或者说云计算时代在架构设计方面一个非常大的进步，但是这并不意味着在所有场景下这样一个架构都会是最优解。在我们实际进行软件架构设计时，依然要针对实际的需求和场景进行判断和选择，不能盲目迷信那些备受推崇但实际并不符合自身需求的技术。
最后，新年将至，希望新的一年大家都能身体健康，早日暴富。新年快乐~~