不幸的是，这个词在俄语中没有一个很好的对应词。 维基百科给出 “多租户，多租户。” 这有时称为“多重所有权”。 这些术语可能有点令人困惑，因为主题本身并不与租赁或拥有相关。 这是软件架构及其操作组织的问题。 后者同样重要。
当我们开始设计 1C:Enterprise 中的云（服务）工作模型方法时，我们开始形成对多租户的理解。 这是几年前的事了。 从那时起，我们的理解不断扩大。 我们不断发现这个主题越来越多的新方面（优点、缺点、困难、特点等）。
有时，开发人员将多租户理解为一个非常简单的主题：“为了将多个组织的数据存储在一个数据库中，您需要向所有表添加一列包含组织标识符的列，并在其上设置过滤器。” 当然我们也是从这个时候开始研究这个问题的。 但他们很快意识到这只是一块空地（顺便说一句，这也不容易）。 总的来说，这是一个“整个国家”。
多租户的基本思想可以这样描述。 一种典型的应用是为一个家庭设计的小屋，该小屋使用其基础设施（墙壁、屋顶、供水、供暖等）。 多租户应用程序是一栋公寓楼。 其中，每个家庭都使用相同的基础设施，但基础设施本身是为整个房子实施的。
多租户方法是好是坏？ 对此你可以找到截然不同的观点。 似乎根本就没有什么“好坏”之分。 您需要在要解决的特定任务的背景下比较利弊。 但这是一个单独的主题......
从最简单的意义上来说，多租户的目标是通过“社会化”基础设施成本来降低维护应用程序的成本。 这与通过使用生产解决方案（可能进行定制和修改）而不是“按订单”编写来降低应用程序的成本是相同的。 只有在一种情况下发展是社会化的，而在另一种情况下则是剥削。
此外，我们再说一遍，与销售方式没有直接联系。 多租户架构还可以用于企业或部门的IT基础设施中，以实现大量类似分支机构和控股企业的自动化。
可以说，多租户不仅仅是组织数据存储的问题。 这是应用程序作为一个整体如何运行的模型（包括其体系结构的重要部分、部署模型及其维护组织）。
在我们看来，多租户模型最困难和最有趣的事情是应用程序的本质“分叉”。 部分功能适用于特定数据区域（公寓），并且对其他公寓中有居民的事实“不感兴趣”。 有些人将房子视为一个整体，同时为所有居民服务。 同时，后者不能忽视这样一个事实：这些毕竟是独立的公寓，有必要确保必要的粒度和安全性。
在 1C:Enterprise 中，多租户模型是在多种技术级别上实现的。 这些是1C：企业平台的机制，“和””、机制 （标准子系统库）。
这些项目中的每一项都有助于公寓楼整体基础设施的建设。 为什么这是在多种技术中实现的，而不是在一种技术中（例如在平台中）实现的？ 首先，因为我们认为某些机制非常适合针对特定部署选项进行修改。 但总的来说，这是一个困难的问题，我们不断面临一个选择——在什么级别上更好地实现多租户的这个或那个方面。
显然，机制的基本部分需要在平台中实现。 嗯，例如，实际的数据分离。 人们通常从这里开始谈论多租户。 但最终，多租户模型“遍历”了平台机制的重要部分，需要对其进行完善，在某些情况下甚至需要重新思考。
在平台层面，我们准确地实现了基本机制。 它们允许您创建在多租户模型中运行的应用程序。 但为了让应用程序在这样的模型中“生活和工作”，你需要有一个系统来管理它们的“生活活动”。 1cFresh 技术和 BSP 级别的统一业务逻辑层负责这一点。 正如公寓楼的基础设施为居民提供了他们所需的一切一样，1cFresh 技术也为他们在多租户模型中运行的应用程序提供了所需的一切。 为了使应用程序能够与该基础设施进行交互（无需进行重大修改），相应的“连接器”以 BSP 子系统的形式放置在其中。
从平台机制的角度来看，很容易注意到，随着我们积累经验并开发云用例“1C：企业”，我们正在扩展该架构中涉及的机制的组成。 让我们举一个例子。 在多租户模型中，应用服务参与者的角色发生了显着变化。 负责操作应用程序的人员的角色（责任级别）显着增加。 他们有必要拥有更强大的应用程序控制工具。 因为应用程序用户（居民）首先信任与他们合作的提供商。 为此，我们实施了一个新的 。 这种机制允许提供商管理员将应用程序开发人员的自由限制在所需的安全级别 - 实质上是在某个沙箱内隔离每个租户的应用程序操作。
同样有趣的是管理在多租户模式下运行的应用程序的架构（在 1cFresh 和 BSP 技术中实现）。 这里，与传统的部署模型相比，对管理流程自动化的要求显着提高。 这样的过程有几十个：创建新的数据区域（“公寓”）、更新应用程序、更新监管信息、备份等。当然，对可靠性和可用性水平的要求也在不断增加。 例如，为了确保应用程序和控制系统组件之间的可靠交互，我们实现了保证交付的异步调用系统技术。
一个非常微妙的点是数据和流程社交化的方式。 乍一看似乎很简单（如果对某人来说）。 最大的挑战是数据和流程的集中化与去中心化之间的平衡。 一方面，集中化可以降低成本（磁盘空间、处理器资源、管理员工作量......）。 另一方面，它限制了“租客”的自由。 这正是应用程序“分叉”的时刻之一，开发人员需要同时考虑应用程序的狭义（服务于一套“公寓”）和广义（同时服务于所有“租户”） 。
作为这种“困境”的一个例子，我们可以引用监管和参考信息。 当然，让房子的所有“房客”都共用它是一个很大的诱惑。 这使您可以将其存储在一份副本中并立即为每个人更新。 但碰巧有些居民需要具体的改变。 奇怪的是，实际上，即使对于监管机构（政府机构）指定的信息，也会发生这种情况。 事实证明这是一个难题：社交还是不社交？ 当然，让信息对每个人来说都是通用的，而对那些需要它的人来说则是私有的，这是很诱人的。 这已经导致实施非常困难。 但我们正在努力解决这个问题...
又如定期流程执行的设计（按计划执行、由控制系统发起等）。 一方面，它们可以针对每个数据区域单独实现。 更简单、更方便。 但另一方面，如此细的粒度会给系统带来很大的负载。 为了减轻负担，需要实施社会化流程。 但它们需要更仔细的研究。
当然，这提出了一个非常重要的问题。 应用程序开发人员如何确保多租户？ 为此他们需要做什么？ 当然，我们努力确保技术和基础设施问题的负担尽可能落在所提供技术的肩上，而应用程序开发人员只考虑业务逻辑任务。 但与其他重要的体系结构问题一样，应用程序开发人员需要对多租户模型的工作有一定的了解，并且在开发应用程序时需要付出一些努力。 为什么？ 因为有些点是技术无法在不考虑数据语义的情况下自动提供的。 例如，同样定义了信息社会化的边界。 但我们尽力将这些困难控制在较小的范围内。 已经有此类应用程序的实施示例。
在 1C:Enterprise 中实现多租户的一个重要点是，我们正在创建一种混合模型，其中一个应用程序可以在多租户模式和正常模式下运行。 这是一项非常艰巨的任务，需要单独讨论。
来源： habr.com