I. 什么是多租户？

多租户是一个概念或者说使用场景，它是在探讨与实现在多用户或多组织的环境下，如何共享相同的系统或组件，并且实现一定程度的隔离。

一个租户通常是逻辑上的一组用户，比如是一个集团中的各BU，一个公司中的各个部门，或者一个部门里的用户集合、多个 vip 用户的集合等。在 toB 产品的设计中，租户一般和组织架构相关联，可以根据组织实际情况进行划分，灵活度较高。但是一个租户内的用户一般具有相同的系统共享和隔离程度。

多租户通常是在共享程度与隔离程度之间做权衡选择：

1. 共享程度越高，租户成本自然越低，技术实现难度越高，运维难度越大。
2. 隔离程度越高，租户成本自然越高，技术实现难度越低，运维难度越低。

以某 Saas 服务为例，可以定义三种多租户模式:

第一个示例使用每租户的独立应用程序和其自己的数据库。

第二个示例使用多租户应用，并且每个租户都具有一个数据库。

第三个示例使用多租户应用，并且具有分片式多租户数据库。

三种模型，从左向右，资源共享程度依次变高，当然成本也就逐步下降，但与之带来的就是技术难度也在大幅增加。

image

II. Byzer 引擎如何实现多租户设计

Byzer 作为一门面向 Data Pipeline 和 AI 的编程语言，它的引擎在设计的时候，就考虑到了多租户的需求，下面我们来聊聊 Byzer 引擎的多租户设计

2.1 多租户设计原理

实现多租户的设计原理，实际上是需要做到计算资源的共享和隔离，然后通过一种路由机制，可以根据不同的策略，将用户的请求路由到指定的计算集群即可。

基于这个原理，我们来看看 Byzer 引擎的多租户架构图：

Byzer 引擎的多租户架构图

Byzer-router 的源码位于这里： https://github.com/byzer-org/byzer-lang/tree/master/streamingpro-cluster

在多租户的设计下，整体架构会分为 4 层：

• 应用 Client 层：
  • 这一层的作用是为了识别当前的用户是谁
  • 用户的信息维度会在用户 ID （User ID）的基础上，多一个租户 ID （Tenant ID）。
• 应用后端 Server 层：
  • 这一层主要是整体应用的逻辑层，负责和 Client 层进行 API 的交互，实现一些业务逻辑
  • 同时会负责和 Byzer 引擎交互，业务逻辑请求一般会在转化成 Byzer 语言脚本，提交给引擎进行执行
• 路由层：
  • 这一层主要负责配置不同的策略，根据不同的策略，将后端 Server 层提交的脚本进行分发给不同的引擎
• 引擎层：
  • 一组或多组 Byzer 引擎，接受由路由层转发的 Byzer 语言脚本进行执行，然后将执行的结果进行返回
  • 多组引擎可以部署在不同的物理资源中

那么从这个架构里可以看出，关键点其实就是在于路由层，那下面我们来看看 Byzer 的路由层是怎么设计的。

2.2 Byzer Router 设计原理

Byzer Router 实际上是通过在元数据库（MySQL）中，维护了租户 ID 和 引擎 Tag 的映射关系，来完成对不同租户的请求分发到不同的引擎实例。不同的引擎实例可以打上不同的 Tag，也可以打上相同的 Tag，原则是一个 Tag 用来标记一组 Byzer 引擎实例。

假设我们这里的映射关系如下：

映射关系

当应用的 Server 后端提交了一个任务请求，会包含 Tenant ID， User ID，Byzer Script 以及回调接口等信息，经过 Byzer Router 时，Byzer Router 会通过 Tenant ID，也就是 Tenant_A 找到对应的引擎 Tag_A, 将请求分发给 Tag_A 对应的引擎集群。

此时发现 Tag_A 标记了 Engine_A1 和 Engine_A2 两个集群，那么此时就会根据 Byzer Router 配置的分发策略将请求分发给指定的引擎。目前策略有如下的几个类型：

• 全员分发策略：将任务同时发给一个 Tag 标记的所有引擎实例
• 资源空闲策略：将任务发给一组引擎实例中当前 cpu 使用率最低的引擎实例
• 任务空闲策略：将任务发给一组引擎实例中当前任务数量最少的引擎实例

需要注意的几点是：

• Byzer Router 是一个可选组件，只有当需要多租户或需要实现定制化的资源需求时才需要
• 如果只是实现引擎的高可用需求，一般只需要引入 Load Balancer 即可
• 当前策略是非常容易扩展实现的，用户可以根据自己的需求来实现不同的策略，比如 Round Robin 策略。
• Byzer Router 的是需要用户根据自己的需求，来手动维护租户和 Tag 的映射表

我们现在了解了任务请求分发的机制和策略之后，接下来我们来看看隔离的机制。

2.3 Byzer 引擎隔离机制

一个 Byzer Engine 从本质上来讲等价于一个 Spark Service 实例，所以在 Byzer 引擎中有两层隔离机制：

软隔离 -- Byzer 引擎实例内部资源隔离机制：

单个 Byzer Engine 实例会以 User ID 为粒度进行如下三个层面的隔离：

1. 变量隔离

• 根据 User ID 来隔离变量，临时表名
• 原理是 Byzer Engine 会针对每个用户创建一个独立的 SparkSession 对象。

2. 存储隔离

• 根据 User ID 来隔离 HDFS/对象存储中的文件目录
• 原理是 Byzer Engine 会给每个用户创建一个独立的目录，用户所有读写都是在自己的目录完成。譬如两个不同用户都往 /tmp/abc 写数据，引擎其实会将该目录生成在用户各自的目录，避免脚本之间的互相影响。

3. 任务****隔离

• 不同用户共享同一个 Byzer 引擎实例时，其实也共享该引擎实例的资源
• 不同用户之间的任务的隔离这个主要依赖于 Spark 自身的任务调度策略， 一般推荐使用公平调度策略（另外一个是 FIFO 调度策略）。

硬隔离 -- 多个 Byzer 引擎实例资源隔离机制：

可以通过部署多个 Byzer 引擎实例在不同的物理集群资源上来实现硬隔离，每个引擎可以独占硬件资源来保证资源的占用不存在冲突。结合 Byzer Router 的 Tag 机制，我们又可以将硬件隔离的引擎组合在一起进行资源共享。所以如果存在资源硬隔离的需求时，我们可以结合上述两种方式来使用，实现灵活的分发策略。

通常我们可以结合上述两种方式使用，利用 Tag 机制，实现灵活的分发策略。

III. Byzer 基于 K8S 部署的多租户架构

Byzer 是天然支持 K8S 的部署的云原生架构，当 Byzer 的引擎部署在 K8S 中时，和上述的架构没有大的变化，一般只需要在后端 Server 层和 Byzer Router 层中间加一层 7 层的 Ingress 来当做 Gateway 使用即可。

_____________________________END _____________________________

以上为 Byzer-lang 多租户设计原理的详细讲解，希望对社区的小伙伴们有所帮助～
欢迎大家加入 Byzer Slack 社区开发讨论组，参与 Byzer 社区的前沿技术话题讨论

https://join.slack.com/t/byzer-org/shared_invite/zt-10qgl60dg-lX4fFggaHyHB6GtUmer_xw