1 回答

TA貢獻1780條經驗 獲得超5個贊
我找不到任何支持多租戶的 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 的信息。另一種實施方式將實施更復雜的無人信任政策,由此為每個服務提供足夠的訪問控制信息,以就是否應滿足特定租戶范圍內的特定請求做出自己的政策決定。
- 1 回答
- 0 關注
- 237 瀏覽
添加回答
舉報