Byzer 多租户设计原理

2022-03-17 本文已影响0人 Byzer_Community

I. 什么是多租户？

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

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

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

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

以某 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 为粒度进行如下三个层面的隔离：

变量隔离

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

存储隔离

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

任务****隔离

不同用户共享同一个 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