1 回答

TA貢獻1780條經(jīng)驗 獲得超5個贊
我找不到任何支持多租戶的 Go ORM。在 sqlx 包之上編寫我自己的可能是一個有效的選項嗎?
Go 中的 ORM 是一個有爭議的話題!有些 Go 用戶喜歡它們,有些則討厭它們并且更喜歡手動編寫 SQL。這是個人喜好問題。在這里詢問特定的庫推薦是題外話,無論如何,我不知道任何多租戶 ORM 庫——但是沒有什么可以阻止你使用包裝器的(我每天都在一個系統(tǒng)上工作,它正是這樣做sqlx
的).
未來的其他服務(wù)也將需要多租戶支持,所以我想我無論如何都必須創(chuàng)建一些庫/包。
以適合您的編程和接口模式的方式從這些內(nèi)部服務(wù)中抽象出這種行為是有意義的,但這里沒有進一步的細節(jié)來更具體地回答。
今天,我通過為公共 API 服務(wù)器使用 ResolveTenantBySubdomain 中間件來解析租戶。然后,我將已解析的租戶 ID 放在上下文值中,該值隨調(diào)用管理器一起發(fā)送。在管理器的不同方法中,我從上下文值中獲取租戶 ID。然后將其用于每個 SQL 查詢/執(zhí)行調(diào)用,或者如果租戶 ID 丟失或無效則返回錯誤。我是否應(yīng)該為此目的使用上下文?
context.Context
主要是關(guān)于取消,而不是請求傳播。根據(jù)該函數(shù)的文檔WithValue
,雖然您的使用是可以接受的,但人們普遍?認為使用context
當(dāng)前實現(xiàn)的包來傳遞值是一種不好的代碼味道。與其使用缺乏類型安全和許多其他屬性的隱式行為,不如通過將租戶 ID 傳遞給相關(guān)函數(shù)調(diào)用來在下游數(shù)據(jù)層的函數(shù)簽名中顯式顯示?
在 gRPC 服務(wù)器上解析租戶,我相信我必須使用 UnaryInterceptor 函數(shù)進行中間件處理。由于 gRPC API 接口只會被其他后端服務(wù)訪問,我想這里不需要通過子域解析。但是我應(yīng)該如何嵌入租戶 ID?在標(biāo)題中?[原文如此]
gRPC 庫不會對您的設(shè)計選擇固執(zhí)己見。您可以使用標(biāo)頭值(將租戶 ID 作為“環(huán)境”參數(shù)傳遞給請求)或?qū)⒆鈶?ID 參數(shù)顯式添加到需要它的每個遠程方法調(diào)用。
請注意,以這種方式在您的服務(wù)之間傳遞租戶 ID 會在它們之間建立外部信任——如果服務(wù) A 向服務(wù) B 發(fā)出請求并使用租戶 ID 對其進行注釋,則您假設(shè)服務(wù) A 已執(zhí)行必要的訪問控制檢查以驗證用戶該租戶確實提出了請求。在這個簡單的模型中沒有任何東西可以防止流氓服務(wù) C 向服務(wù) B 詢問有關(guān)某個任意租戶 ID 的信息。另一種實施方式將實施更復(fù)雜的無人信任政策,由此為每個服務(wù)提供足夠的訪問控制信息,以就是否應(yīng)滿足特定租戶范圍內(nèi)的特定請求做出自己的政策決定。
- 1 回答
- 0 關(guān)注
- 248 瀏覽
添加回答
舉報