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?在标题中?

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


蝴蝶不菲
浏览 161回答 1
1回答

翻阅古今

我找不到任何支持多租户的 Go ORM。在 sqlx 包之上编写我自己的可能是一个有效的选项吗?Go 中的 ORM 是一个有争议的话题!有些 Go 用户喜欢它们,有些则讨厌它们并且更喜欢手动编写 SQL。这是个人喜好问题。在这里询问特定的库推荐是题外话,无论如何,我不知道任何多租户 ORM 库——但是没有什么可以阻止你使用包装器的(我每天都在一个系统上工作,它正是这样做sqlx的).未来的其他服务也将需要多租户支持,所以我想我无论如何都必须创建一些库/包。以适合您的编程和接口模式的方式从这些内部服务中抽象出这种行为是有意义的,但这里没有进一步的细节来更具体地回答。今天,我通过为公共 API 服务器使用 ResolveTenantBySubdomain 中间件来解析租户。然后,我将已解析的租户 ID 放在上下文值中,该值随调用管理器一起发送。在管理器的不同方法中,我从上下文值中获取租户 ID。然后将其用于每个 SQL 查询/执行调用,或者如果租户 ID 丢失或无效则返回错误。我是否应该为此目的使用上下文?context.Context主要是关于取消,而不是请求传播。根据该函数的文档WithValue,虽然您的使用是可以接受的,但人们普遍 认为使用context当前实现的包来传递值是一种不好的代码味道。与其使用缺乏类型安全和许多其他属性的隐式行为,不如通过将租户 ID 传递给相关函数调用来在下游数据层的函数签名中显式显示?在 gRPC 服务器上解析租户,我相信我必须使用 UnaryInterceptor 函数进行中间件处理。由于 gRPC API 接口只会被其他后端服务访问,我想这里不需要通过子域解析。但是我应该如何嵌入租户 ID?在标题中?[原文如此]gRPC 库不会对您的设计选择固执己见。您可以使用标头值(将租户 ID 作为“环境”参数传递给请求)或将租户 ID 参数显式添加到需要它的每个远程方法调用。请注意,以这种方式在您的服务之间传递租户 ID 会在它们之间建立外部信任——如果服务 A 向服务 B 发出请求并使用租户 ID 对其进行注释,则您假设服务 A 已执行必要的访问控制检查以验证用户该租户确实提出了请求。在这个简单的模型中没有任何东西可以防止流氓服务 C 向服务 B 询问有关某个任意租户 ID 的信息。另一种实施方式将实施更复杂的无人信任政策,由此为每个服务提供足够的访问控制信息,以就是否应满足特定租户范围内的特定请求做出自己的政策决定。
打开App,查看更多内容
随时随地看视频慕课网APP

相关分类

Go