多租户

MatrixOne 的设计采用了单一集群多租户的方式。在这个设计中，租户（Account）是一个逻辑概念，作为资源分配和数据库管理的单位。MatrixOne 的多租户模式能够为不同的租户提供独立的数据库实例，并采用逻辑隔离的方式确保各租户数据的安全性和独立性，有效防止数据泄露和篡改的风险。

业务需求

在企业的业务发展到一定规模，数据量不断增长的同时，业务部门或项目组增加，企业可以根据各自的业务需求和规模，进行灵活的租户管理，满足不同的业务部门或项目组的独立性要求。在 MatrixOne 的多租户模式下，企业可以轻松管理各租户的数据资源，从而使得数据分析、报告等业务流程更加流畅和准确。同时，这种方式还有助于企业提高业务效率，降低管理成本，实现企业资源的最大化利用。

功能优势

• 降低运营成本：多个用户可以共享一个数据库集群，避免了多套集群的部署和管理，从而减少硬件和软件的投入成本。

• 资源及负载隔离：多租户模式提高了数据的安全性和可靠性，不同用户的数据和负载相互隔离，即使某个用户的数据出现问题或负载过高，也不会影响其他用户。

• 动态资源分配：多租户还可以提高数据库的可扩展性，每个租户可以独立扩展或收缩自己的资源，面对不同级别的负载可以实现资源使用的最大化。

• 租户统一管理：虽然每个租户之间是隔离且独立运行的，但管理人员仍然可以通过系统租户对其他租户进行统一的管理，比如快速创建新租户，批量删除老租户等。

• 租户数据共享：在某些联邦统计查询的场景下，租户之间需要进行数据共享。MatrixOne 提供完整的租户数据分享及订阅的机制，满足更灵活的业务分析需求。

• 跨地域部署：在一些业务跨很多地域的场景下，租户需要与地域进行关联，提供就近的服务。MatrixOne 支持同一个集群下不同的租户分布在不同的地域上，就近对业务进行服务。

技术架构

MatrixOne 的多租户系统包含两种类型不同的租户：系统（sys）租户和普通租户。系统租户是由 MatrixOne 集群内置的，集群启动后系统会默认登录该租户。该租户的主要职责包括：

• 存储和管理与集群相关的系统表。
• 管理集群级别的功能，例如创建/删除租户、修改系统配置等。

相比之下，普通租户则是由系统租户创建的。在使用时，普通租户可以被视为一个数据库实例，需要指定租户名称才能连接。普通租户具备如下特性：

• 可以创建自己的用户。
• 可以创建数据库、表以及其他所有客体对象。
• 拥有独立的 information_schema 等系统数据库。
• 拥有独立的系统变量。
• 具备数据库实例所应具备的其他特性。

多租户资源隔离

MatrixOne 的分布式集群采用 Proxy 模块和 CN 资源组技术架构实现了多租户资源隔离。

当用户连接时，连接会经过 Proxy 模块，Proxy 会根据 CN 的租户标签信息将连接转发到对应 CN 资源组上的某个 CN 上，根据负载均衡的原则选择负载最轻的 CN。在 MatrixOne 集群架构中，CN 是以容器化部署的，因此 CN 之间具有隔离性。一个租户使用的 CN 资源组是一组打上该租户标签的 CN。如果资源不足，需要进行扩展，可以通过水平扩展该 CN 资源组来满足需求，而不会抢占其他 CN 资源组的资源。

该架构图如下所示：

应用场景

MatrixOne 的多租户能力可在以下多个应用场景中体现优势。

多租户 SaaS 应用

在为大量企业客户提供服务的 SaaS 应用中，多租户模型设计是非常关键的。

传统架构

传统的多租户架构在数据库层面为每个租户存储和管理数据。通常有多种设计模式，如共享数据库模式（每个租户共享一个数据库，但拥有自己的数据表/列）或独立数据库模式（每个租户拥有自己的数据库）。

这两种传统模式都存在一定挑战：

• 租户共享数据库模式依靠应用层靠 SQL 及应用层代码区分租户逻辑，数据和资源隔离程度较低，尤其容易出现某个租户负载突然大幅增加的时候，抢占其他租户的资源，导致整个系统性能下降。但是租户共享数据库模式仅使用一套数据库集群，资源成本和运维管理难度都较低，升级/扩容/应用改动都仅需要做一次即可完成全局更改。
• 租户独立数据库模式将每个租户都以独立数据库实例进行支撑，资源和数据的隔离度非常高，但资源成本和运维难度都较大。当租户数量超过百个时，统一的升级等运维动作将会非常耗费时间。

MatrixOne 架构

MatrixOne 的多租户能力带来了全新的架构方式。租户仍然共享一个 MatrixOne 集群，并且可以通过系统租户进行统一的租户运维和管理。另外，通过自带的多租户能力实现数据及资源的隔离，同时每个租户可以独立进行资源扩缩容，进一步降低运维难度。这种方式不仅满足对隔离性的需求，还能满足低资源和运维成本的需求。

微服务应用架构

微服务应用架构是一种通过开发一系列小型服务来实现一个应用的软件架构模式。每个小型服务通常在自己的进程中运行，并通过轻量级的 HTTP API 进行通讯。这些服务通常以业务模块为界限，可以单独开发部署，并使用自动化的部署工具进行发布。微服务方法可以帮助企业更快地推出新产品和服务，使得开发团队与业务目标保持一致。

与 SaaS 应用不同，微服务应用同样会面临数据库共享或独立的问题。通常建议为每个微服务准备一个单独的数据库，这种模式更适合微服务架构，因为每个服务都是独立开发、部署和扩展的。当需要升级或更改数据架构时，不会影响其他服务。当需要对某个服务进行扩展时，也可以对该服务进行局部扩容。此外，如果某些服务需要特殊的数据库能力，如 Elastic Search 或向量搜索等，这种模式也提供了更灵活的可能性。

然而，微服务最终服务于同一个业务，不同服务之间必然需要共享数据，因此也会遇到与 SaaS 应用多租户相同的困境。

MatrixOne 提供的多租户能力可以很好地平衡这两个矛盾点，既可以保证每个微服务的数据和资源扩展独立性，又可以保持一定的共享性。

集团子公司/业务部门

许多集团公司采用区域子公司或业务部门来分离业务，这些子公司和业务部门通常都是独立运作的，拥有完整的生产、销售和技术支持团队，还会使用自己的 IT 系统。然而，集团公司需要全面掌握子公司的业务状况，因此需要子公司定期上报大量业务数据。

这种 IT 架构在数据库设计方面面临与前两种场景完全相同的问题，即共享和隔离之间需要权衡。此外，在这种场景中还需要考虑地理位置因素，子公司通常有自己的区域属性，需要在附近提供服务。例如，制造企业通常位于北上广深等大城市，但是各个工厂可能分散在不同的二三线城市，这些工厂需要与 ERP、MES 等系统紧密配合。因此，这些系统往往需要在工厂本地部署，而总部需要清楚地掌握各个工厂的情况，因此这些系统需要向集团公司上报数据。传统的部署架构通常采用独立部署数据库的方法，而数据同步和上报则由应用层实现。

MatrixOne 的多租户能力可以很好地解决数据库共享/隔离的困境。由于可以将租户需要的 CN 节点就近部署到子公司所在地区，在网络连通的情况下，可以与集团公司的其他组件天然形成一个集群，既方便本地化业务使用，也满足高效数据上报和统计的需求。

参考文档

更多关于多租户的文档可以参见：

• 多租户应用场景
• 快速开始：创建租户，验证资源隔离