首页 > 解决方案 > Golang 中的多租户

问题描述

我目前正在用 Go 编写一个需要处理多个租户的服务。我已经决定使用一个数据库共享表方法,使用“tenant_id”鉴别器进行租户分离。

该服务的结构如下:

gRPC server -> gRPC Handlers -
                              \_ Managers (SQL)
                              /
HTTP/JSON server -> Handlers -

两台服务器,一台 gRPC(管理)和一台 HTTP/JSON(公共 API),每台服务器都运行在自己的 go-routine 中,并具有各自的处理程序,可以利用不同管理器的功能。管理器(我们称其为“库存管理器”)都存在于不同的根级包中。据我了解,这些是我的域实体。

在这方面我有一些问题:

  1. 我找不到任何支持多个租户的 Go 的 ORM。在 sqlx 包之上编写我自己的包是一个有效的选项吗?

  2. 未来的其他服务也需要多租户支持,所以我想无论如何我都必须创建一些库/包。

  3. 今天,我使用公共 API 服务器的 ResolveTenantBySubdomain 中间件来解析租户。然后,我将解析的租户 ID 放在一个上下文值中,该上下文值与对经理的调用一起发送。在管理器的不同方法中,我从上下文值中获取租户 ID。然后将其与每个 SQL 查询/执行调用一起使用,如果租户 ID 丢失或无效,则返回错误。我什至应该为此目的使用上下文吗?

  4. 解析gRPC服务器上的租户,我相信我必须使用UnaryInterceptor函数进行中间件处理。由于 gRPC API 接口只能被其他后端服务访问,我猜这里不需要通过子域解析。但是我应该如何嵌入租户 ID?在标题中?

真的希望我问的是正确的问题。问候,卡尔。

标签: sqlgomulti-tenant

解决方案


我找不到任何支持多个租户的 Go 的 ORM。在 sqlx 包之上编写我自己的包是一个有效的选项吗?

Go 中的 ORM 是一个有争议的话题!一些 Go 用户喜欢它们,另一些则讨厌它们,并且更喜欢手动编写 SQL。这是个人喜好问题。在这里询问特定的库建议是题外话,无论如何,我不知道有任何多租户 ORM 库 - 但没有什么可以阻止您使用包装器sqlx(我每天都在一个完全执行此操作的系统上工作)。

未来的其他服务也需要多租户支持,所以我想无论如何我都必须创建一些库/包。

以适合您的编程和接口模式的方式从这些内部服务中抽象出这种行为是有意义的,但这里没有更多细节可以更具体地回答。

今天,我使用公共 API 服务器的 ResolveTenantBySubdomain 中间件来解析租户。然后,我将解析的租户 ID 放在一个上下文值中,该上下文值与对经理的调用一起发送。在管理器的不同方法中,我从上下文值中获取租户 ID。然后将其与每个 SQL 查询/执行调用一起使用,如果租户 ID 丢失或无效,则返回错误。我什至应该为此目的使用上下文吗?

context.Context主要是关于取消,而不是请求传播。虽然根据该函数的文档,您的使用是可以接受的,但使用当前实现的包来​​传递值被广泛认为是一种不好的代码气味。与其使用缺乏类型安全和许多其他属性的隐式行为,不如通过将租户 ID 传递给相关的函数调用,在下游数据层的函数签名中显式化?WithValue context

解析gRPC服务器上的租户,我相信我必须使用UnaryInterceptor函数进行中间件处理。由于 gRPC API 接口只能被其他后端服务访问,我猜这里不需要通过子域解析。但是我应该如何嵌入租户 ID?在标题中?[原文如此]

gRPC 库不会对您的设计选择固执己见。您可以使用标头值(将租户 ID 作为“环境”参数传递给请求)或显式地将租户 ID 参数添加到需要它的每个远程方法调用。

请注意,以这种方式在您的服务之间传递租户 ID 会在它们之间创建外部信任——如果服务 A 向服务 B 发出请求并使用租户 ID 对其进行注释,则您假设服务 A 已执行必要的访问控制检查以验证用户那个租户确实在提出请求。在这个简单的模型中没有任何东西可以防止流氓服务 C 向服务 B 询问有关任意租户 ID 的信息。另一种实现方式将实现更复杂的不信任人策略,从而为每个服务提供足够的访问控制信息,以就是否应满足特定租户的特定请求做出其自己的策略决定。


推荐阅读