Golang 中的多租户

Question

我目前正在用 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？在标题中？

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

Answer 1

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

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

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

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

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

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

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

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

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