前陣子一個(gè)做SaaS的朋友找我喝酒說(shuō)他們系統(tǒng)上線半年突然有個(gè)客戶打電話來(lái)質(zhì)問(wèn)為什么我們公司的報(bào)表里能看到別人家的客戶名單查到最后發(fā)現(xiàn)當(dāng)初趕工期所謂“多租戶”只是登錄接口里加了一個(gè)租戶ID字段所有查詢按邏輯硬篩漏了一條統(tǒng)計(jì)SQL就把整個(gè)租戶的數(shù)據(jù)都拖出來(lái)了。這種事在業(yè)務(wù)開(kāi)發(fā)里太常見(jiàn)了尤其是從單租戶系統(tǒng)改造成多租戶、或者一開(kāi)始就沒(méi)想清楚隔離邊界的時(shí)候早晚要出事。這篇博文就圍繞“多租戶下的系統(tǒng)業(yè)務(wù)開(kāi)發(fā)”這件事把原理、方案、代碼改造、框架落地、問(wèn)題排查完整過(guò)一遍順便聊聊若依這類傳統(tǒng)后臺(tái)框架、以及Dify社區(qū)版1.10這種AI應(yīng)用平臺(tái)里多租戶的實(shí)際玩法希望能給正在做或準(zhǔn)備做多租戶改造的朋友一點(diǎn)參考。1. 多租戶到底是什么——從一次線上事故說(shuō)起1.1 一個(gè)人寫(xiě)的系統(tǒng)為什么要考慮多租戶先捋一下基本概念。多租戶Multi-Tenant指的是一套軟件系統(tǒng)同時(shí)服務(wù)多個(gè)客戶租戶每個(gè)租戶有自己的用戶、業(yè)務(wù)數(shù)據(jù)、配置彼此邏輯隔離但共享同一套代碼和運(yùn)行環(huán)境。注意“邏輯隔離”這個(gè)詞它和多用戶是兩碼事。普通系統(tǒng)里的用戶只是系統(tǒng)內(nèi)的一個(gè)賬號(hào)而租戶更像是一個(gè)完整的“隔離域”租戶下的用戶能看到的只是這個(gè)隔離域內(nèi)的資源。那什么時(shí)候需要考慮多租戶最典型的就是SaaS業(yè)務(wù)。你今天給A公司做了一套進(jìn)銷存系統(tǒng)明天B公司也想要傳統(tǒng)做法是再部署一套對(duì)吧系統(tǒng)兩套、數(shù)據(jù)庫(kù)兩套、服務(wù)器兩臺(tái)維護(hù)成本翻倍。但如果把系統(tǒng)改造成多租戶一套代碼、一套數(shù)據(jù)庫(kù)A公司和B公司登錄后各自看到各自的數(shù)據(jù)新增一個(gè)客戶就是新增一條租戶記錄成本低得多。還有一種場(chǎng)景是公司內(nèi)部的公共平臺(tái)比如集團(tuán)下面有很多子公司或者同一家公司有多個(gè)獨(dú)立事業(yè)部每個(gè)都想自己管自己的數(shù)據(jù)、自己配自己的流程你不可能給每個(gè)部門(mén)都部署一套那就是典型的多租戶需求。老實(shí)說(shuō)多租戶這個(gè)詞看起來(lái)很唬人但本質(zhì)上就三件事第一租戶的識(shí)別系統(tǒng)怎么知道當(dāng)前請(qǐng)求屬于哪個(gè)租戶第二數(shù)據(jù)隔離不同租戶的數(shù)據(jù)怎么互不干擾第三資源共享硬件、代碼、中間件都是共享的但租戶之間還不能打架。很多項(xiàng)目出事都是因?yàn)榈谌c(diǎn)沒(méi)處理好表面上大家共用一套系統(tǒng)實(shí)際上數(shù)據(jù)邊界一塌糊涂。1.2 三種主流隔離方案的取舍多租戶的隔離方案業(yè)界基本是三種獨(dú)立數(shù)據(jù)庫(kù)、共享數(shù)據(jù)庫(kù)獨(dú)立Schema、共享數(shù)據(jù)庫(kù)共享Schema。這三種方案的區(qū)分維度就是數(shù)據(jù)物理上怎么放隔離程度怎么控制成本怎么算。獨(dú)立數(shù)據(jù)庫(kù)每個(gè)租戶一個(gè)數(shù)據(jù)庫(kù)實(shí)例。隔離性最強(qiáng)一個(gè)租戶掛了不影響別人數(shù)據(jù)恢復(fù)也簡(jiǎn)單但成本最高數(shù)據(jù)庫(kù)連接數(shù)管理、升級(jí)維護(hù)都很麻煩。適合大客戶、金融醫(yī)療等強(qiáng)合規(guī)場(chǎng)景。共享數(shù)據(jù)庫(kù)、獨(dú)立Schema所有租戶共用一個(gè)數(shù)據(jù)庫(kù)實(shí)例但每個(gè)租戶有自己的Schema。隔離性中等成本中等MySQL里就是一個(gè)數(shù)據(jù)庫(kù)里建多個(gè)同名表結(jié)構(gòu)分別對(duì)應(yīng)不同租戶。但跨Schema的查詢、連接管理比純共享麻煩一點(diǎn)。共享數(shù)據(jù)庫(kù)、共享Schema所有租戶的數(shù)據(jù)放在同一組表里通過(guò)一個(gè)tenant_id字段來(lái)區(qū)分。成本最低查詢最方便運(yùn)維最簡(jiǎn)單但隔離性最弱稍微漏一個(gè)條件就會(huì)串?dāng)?shù)據(jù)。我做過(guò)的絕大多數(shù)項(xiàng)目最終都選了第三種也就是共享Schema加租戶ID。原因很現(xiàn)實(shí)SaaS系統(tǒng)租戶數(shù)量往往很多但單個(gè)租戶數(shù)據(jù)量不一定很大獨(dú)立庫(kù)和獨(dú)立Schema的成本和運(yùn)維壓力扛不住另外業(yè)務(wù)報(bào)表、運(yùn)營(yíng)統(tǒng)計(jì)經(jīng)常需要跨租戶匯總共享Schema在這種場(chǎng)景下寫(xiě)SQL實(shí)在太方便了。選了這個(gè)方案核心任務(wù)就變成了怎么保證所有SQL都帶上租戶條件一條都不能漏。方案隔離強(qiáng)度成本運(yùn)維復(fù)雜度適合場(chǎng)景獨(dú)立數(shù)據(jù)庫(kù)最強(qiáng)高高金融、醫(yī)療、大客戶獨(dú)享共享庫(kù)獨(dú)立Schema中中中中大型SaaS、數(shù)據(jù)量大共享庫(kù)共享Schema弱低低中小型SaaS、內(nèi)部平臺(tái)1.3 隔離級(jí)別的選擇決定后面所有代碼的走向在動(dòng)手之前一定要想清楚隔離級(jí)別怎么定因?yàn)檫@個(gè)決定會(huì)影響你后面所有的代碼走向。我見(jiàn)過(guò)最坑的項(xiàng)目就是表結(jié)構(gòu)里tenant_id字段加了但有些表是租戶隔離的有些表是全局共享的有些表又要求部分租戶可見(jiàn)最后代碼里全是if else新來(lái)的同事根本不敢動(dòng)。我的建議是一開(kāi)始就明確三類表一是租戶私有表比如訂單、客戶、項(xiàng)目這種必須嚴(yán)格按租戶過(guò)濾二是全局共享表比如系統(tǒng)字典、國(guó)家地區(qū)、通用配置所有租戶共用不需要tenant_id三是租戶配置表比如每個(gè)租戶的自定義字段、審批流程這類表不但要有tenant_id還要考慮版本和發(fā)布機(jī)制。理清這三類后面寫(xiě)代碼就清楚多了私有表一律走強(qiáng)制租戶攔截共享表保持原樣配置表單獨(dú)設(shè)計(jì)一套租戶級(jí)的管理API。另外補(bǔ)充一句隔離級(jí)別不只是表這一層文件存儲(chǔ)、消息隊(duì)列、緩存、搜索引擎比如Elasticsearch的索引、數(shù)據(jù)倉(cāng)庫(kù)都要一并考慮。很多系統(tǒng)表隔離做得挺好結(jié)果文件存儲(chǔ)的目錄路徑里沒(méi)帶租戶ID兩個(gè)租戶上傳的合同文件互相覆蓋這種事故我聽(tīng)過(guò)不止一次。2. 多租戶業(yè)務(wù)開(kāi)發(fā)的核心骨架租戶上下文與數(shù)據(jù)隔離2.1 租戶從哪來(lái)域名、Header、登錄態(tài)還是Token里租戶識(shí)別是整個(gè)多租戶開(kāi)發(fā)的起點(diǎn)。請(qǐng)求進(jìn)來(lái)的時(shí)候系統(tǒng)得先知道這是哪個(gè)租戶在操作這步?jīng)]做好后面所有隔離邏輯都無(wú)從談起。常見(jiàn)的識(shí)別方式有幾種我分別說(shuō)下優(yōu)缺點(diǎn)。第一種獨(dú)立域名/子域名。每個(gè)租戶一個(gè)二級(jí)域名比如tenantA.yourdomain.com、tenantB.yourdomain.com。請(qǐng)求進(jìn)來(lái)時(shí)系統(tǒng)從Host頭里解析出租戶標(biāo)識(shí)。好處是用戶感知強(qiáng)瀏覽器層面天然隔離適合ToB產(chǎn)品缺點(diǎn)是要處理域名解析、獨(dú)立SSL證書(shū)、以及域名和租戶的映射關(guān)系。第二種URL路徑前綴。比如/tenantA/order/list、/tenantB/order/list網(wǎng)關(guān)層根據(jù)路徑前綴識(shí)別租戶。這種方式實(shí)現(xiàn)簡(jiǎn)單但在前后端分離架構(gòu)下前端路由要跟著改后端接口設(shè)計(jì)也會(huì)被租戶路徑綁架我不太推薦。第三種Header或Token里帶租戶ID。前端登錄后后端把租戶ID寫(xiě)進(jìn)JWT或Header每次請(qǐng)求自動(dòng)攜帶。這種方式最靈活也是目前前后端分離項(xiàng)目的主流做法。租戶信息可以從登錄用戶信息中推導(dǎo)比如用戶表和租戶表是多對(duì)一關(guān)系登錄成功后把租戶ID放到用戶會(huì)話里后續(xù)請(qǐng)求就不用每次解析租戶域名了。實(shí)際項(xiàng)目里我經(jīng)常是“域名Toke”雙保險(xiǎn)域名用來(lái)做系統(tǒng)級(jí)的路由分流比如不同租戶可能使用不同版本的功能開(kāi)關(guān)Token里的租戶ID用來(lái)做數(shù)據(jù)級(jí)隔離。不管用哪種核心原則是租戶識(shí)別必須在請(qǐng)求的最前端完成而且不能信任前端傳來(lái)的租戶ID必須經(jīng)過(guò)服務(wù)端解析和校驗(yàn)否則別人改個(gè)Header就能訪問(wèn)其他租戶的數(shù)據(jù)。2.2 租戶上下文傳遞從Controller到Mapper的一整條線租戶識(shí)別出來(lái)之后要把它存到一個(gè)“請(qǐng)求級(jí)別”的上下文中保證本次請(qǐng)求從Controller到Service到Mapper任何一層都能隨時(shí)拿到租戶ID。我見(jiàn)過(guò)最簡(jiǎn)單的實(shí)現(xiàn)就是ThreadLocal 攔截器請(qǐng)求進(jìn)來(lái)時(shí)攔截器解析租戶信息放進(jìn)ThreadLocal請(qǐng)求結(jié)束時(shí)在finally塊里清理掉。為什么用ThreadLocal因?yàn)樗烊唤壎ó?dāng)前線程整個(gè)請(qǐng)求處理鏈路都在同一個(gè)線程里執(zhí)行同步場(chǎng)景下Service和Mapper里隨便取。但一定要記住兩件事第一必須清理ThreadLocal否則線程池復(fù)用會(huì)串租戶這是最典型的坑第二如果代碼里有異步操作比如線程池、Async、MQ消費(fèi)者ThreadLocal就傳不過(guò)去了得額外處理。租戶上下文類大概長(zhǎng)這樣public class TenantContext { private static final ThreadLocalString TENANT_ID new ThreadLocal(); public static void setTenantId(String tenantId) { TENANT_ID.set(tenantId); } public static String getTenantId() { return TENANT_ID.get(); } public static void clear() { TENANT_ID.remove(); } }攔截器里用法是public class TenantInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String tenantId parseTenantFromRequest(request); TenantContext.setTenantId(tenantId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { TenantContext.clear(); } }這個(gè)模式本身很簡(jiǎn)單但它是一個(gè)基礎(chǔ)設(shè)施后面所有的租戶過(guò)濾、數(shù)據(jù)審計(jì)、日志追蹤都會(huì)依賴它。建議從項(xiàng)目第一天就把它接好不要等到系統(tǒng)上線了再補(bǔ)。中間件能力前置永遠(yuǎn)比事后打補(bǔ)丁輕松。2.3 數(shù)據(jù)權(quán)限改造的幾個(gè)關(guān)鍵位置有了租戶上下文接下來(lái)就是最關(guān)鍵的數(shù)據(jù)隔離。如果你用MyBatis而且用的是MyBatis-Plus那省事很多它內(nèi)置了多租戶插件TenantLineInnerInterceptor只要配置好需要隔離的表和租戶ID字段它會(huì)在執(zhí)行SQL時(shí)自動(dòng)追加租戶條件連子查詢、join都會(huì)處理基本不用手動(dòng)改業(yè)務(wù)代碼。下面這段是MyBatis-Plus多租戶插件的關(guān)鍵配置Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); TenantLineInnerInterceptor tenantLine new TenantLineInnerInterceptor(); tenantLine.setTenantLineHandler(new TenantLineHandler() { Override public Expression getTenantId() { return new LongValue(TenantContext.getTenantId()); } Override public String getTenantIdColumn() { return tenant_id; } Override public boolean ignoreTable(String tableName) { // 全局表不需要租戶隔離返回true return ignoreTenantTableSet.contains(tableName); } }); interceptor.addInnerInterceptor(tenantLine); return interceptor; }用MyBatis-Plus的插件是省心但有幾個(gè)地方必須自己留意第一連表查詢?nèi)绻鸍oin的表不在租戶管理的表清單里或者ignoreTable配錯(cuò)了插件不會(huì)自動(dòng)處理第二原生SQL、自定義SQL、自己寫(xiě)的XML里如果有復(fù)雜嵌套查詢插件解析失敗或漏加條件的情況是有的第三批量任務(wù)、數(shù)據(jù)遷移腳本經(jīng)常繞過(guò)插件直接走原生連接這時(shí)候必須自己在SQL里顯式帶上租戶條件。如果你沒(méi)有用MyBatis-Plus或者框架是JPA、MP之外的那就得自己在SQL層統(tǒng)一處理了。比較實(shí)用的做法是把所有的Mapper查詢方法封裝成基礎(chǔ)層由基礎(chǔ)層自動(dòng)拼上tenant_id條件業(yè)務(wù)層的代碼不直接寫(xiě)查詢SQL而是調(diào)用基礎(chǔ)層方法。這樣至少能保證百分之九十的查詢帶上了租戶條件剩下的特殊查詢?cè)賳为?dú)人工審計(jì)。2.4 緩存、定時(shí)任務(wù)、消息隊(duì)列里的租戶問(wèn)題表結(jié)構(gòu)隔離做干凈了只能算完成了一半另一半在基礎(chǔ)設(shè)施層。緩存就是第一個(gè)重災(zāi)區(qū)。比如你用Redis緩存用戶信息、緩存配置、緩存報(bào)表結(jié)果key如果不帶租戶ID兩個(gè)租戶就互相覆蓋。我見(jiàn)過(guò)最離譜的情況是兩個(gè)租戶因?yàn)榫彺鎘ey相同登錄后看到的是對(duì)方的首頁(yè)配置。解決方案很簡(jiǎn)單也很粗暴所有緩存key的命名空間中強(qiáng)制拼接租戶ID比如user:info:tenantA:1001配置類緩存也同理。定時(shí)任務(wù)更麻煩。因?yàn)槎〞r(shí)任務(wù)不是由某個(gè)用戶請(qǐng)求觸發(fā)的沒(méi)有租戶上下文。那這個(gè)任務(wù)處理的數(shù)據(jù)是屬于哪個(gè)租戶的常見(jiàn)的做法有兩種一種是把定時(shí)任務(wù)設(shè)計(jì)成按租戶循環(huán)執(zhí)行就是任務(wù)啟動(dòng)后先查出所有租戶列表然后遍歷每個(gè)租戶在循環(huán)體內(nèi)臨時(shí)設(shè)置TenantContext執(zhí)行完再清掉另一種是定時(shí)任務(wù)只負(fù)責(zé)產(chǎn)生“任務(wù)數(shù)據(jù)”真正處理時(shí)還是通過(guò)MQ發(fā)到業(yè)務(wù)系統(tǒng)由業(yè)務(wù)系統(tǒng)按租戶維度消費(fèi)。兩種方式我都用過(guò)前者實(shí)現(xiàn)簡(jiǎn)單但一旦租戶數(shù)量多、任務(wù)執(zhí)行時(shí)間長(zhǎng)容易出現(xiàn)租戶上下文沒(méi)清理干凈的隱患后者更健壯但架構(gòu)復(fù)雜度高。消息隊(duì)列的情況和定時(shí)任務(wù)類似。消費(fèi)者收到一條消息這消息可能是某個(gè)租戶的業(yè)務(wù)操作觸發(fā)的那消費(fèi)者在消費(fèi)時(shí)怎么知道是哪個(gè)租戶推薦的做法是把租戶ID放到消息體里消費(fèi)端取到消息后先設(shè)置TenantContext再執(zhí)行業(yè)務(wù)邏輯最后清掉。千萬(wàn)不要在消息體里不帶租戶ID然后消費(fèi)時(shí)用消費(fèi)者的ThreadLocal去猜猜一次錯(cuò)一次。圍繞租戶上下文做基建是異步場(chǎng)景里最重要的工作沒(méi)有之一。3. 從經(jīng)典框架看多租戶落地若依多租戶拆解3.1 若依多租戶的適用場(chǎng)景若依RuoYi是國(guó)內(nèi)非常經(jīng)典的Java后臺(tái)管理腳手架基于Spring Boot MyBatis Vue內(nèi)置了用戶、角色、菜單、部門(mén)、字典、日志這些通用功能很多公司拿它當(dāng)項(xiàng)目底座在上面做二次開(kāi)發(fā)。最近若依社區(qū)版對(duì)多租戶做了不少功能擴(kuò)展應(yīng)用場(chǎng)景也明確了主要面向分公司、集團(tuán)下屬企業(yè)、以及代理商內(nèi)部多團(tuán)隊(duì)共用一個(gè)后臺(tái)的場(chǎng)景。拿一個(gè)實(shí)際案例來(lái)說(shuō)某公司用若依做了一套渠道管理系統(tǒng)要給全國(guó)幾十個(gè)渠道代理商用。每個(gè)代理商有自己的賬號(hào)體系、自己的業(yè)務(wù)數(shù)據(jù)但代理商之間不能互相看到數(shù)據(jù)。如果每個(gè)代理商部署一套系統(tǒng)光版本就要維護(hù)幾十份這顯然不現(xiàn)實(shí)。這時(shí)候若依的多租戶擴(kuò)展就派上用場(chǎng)了先由平臺(tái)管理員創(chuàng)建租戶代理商每個(gè)租戶再自己去維護(hù)子用戶和角色權(quán)限租戶之間的業(yè)務(wù)數(shù)據(jù)天然隔離。這種場(chǎng)景的核心訴求不是說(shuō)隔離要多徹底而是快速開(kāi)店、快速開(kāi)賬套運(yùn)營(yíng)成本要低。和上一章講的通用多租戶方案對(duì)比若依這類框架的優(yōu)勢(shì)在于它本身管理功能很齊全租戶管理界面、用戶管理、角色權(quán)限都是現(xiàn)成的你不需要從零去寫(xiě)一套租戶后臺(tái)。但它也有限制框架本身默認(rèn)是單租戶設(shè)計(jì)的你要做的實(shí)際上是一次“從單租戶到多租戶”的改造改造得不好業(yè)務(wù)層就會(huì)到處透?jìng)鱰enant_id代碼一團(tuán)糟。3.2 數(shù)據(jù)表結(jié)構(gòu)如何擴(kuò)展若依多租戶改造中最核心的表結(jié)構(gòu)動(dòng)作就是新增一張租戶表然后在需要隔離的業(yè)務(wù)表、甚至框架自帶的系統(tǒng)表上添加tenant_id字段。按照若依官方的擴(kuò)展方式租戶ID一般是字符串類型比如sys_tenant表里存租戶編碼和租戶名稱業(yè)務(wù)表里用tenant_id關(guān)聯(lián)到這表。下面是一個(gè)實(shí)用改造示例-- 租戶表 CREATE TABLE sys_tenant ( tenant_id varchar(32) NOT NULL COMMENT 租戶ID, tenant_name varchar(100) NOT NULL COMMENT 租戶名稱, status char(1) DEFAULT 0 COMMENT 狀態(tài)0正常 1停用, create_time datetime DEFAULT NULL, PRIMARY KEY (tenant_id) ) ENGINEInnoDB COMMENT租戶表; -- 業(yè)務(wù)表改造增加租戶字段 ALTER TABLE biz_order ADD COLUMN tenant_id varchar(32) NOT NULL DEFAULT COMMENT 租戶ID; CREATE INDEX idx_biz_order_tenant ON biz_order(tenant_id);這里有個(gè)容易忽略的點(diǎn)不是所有系統(tǒng)表都需要加tenant_id。像數(shù)據(jù)字典類型的表如果字典項(xiàng)是全局共用的就是全局表如果每個(gè)租戶需要維護(hù)自己的字典項(xiàng)那就要加tenant_id。很多團(tuán)隊(duì)在改造時(shí)為了省事把所有表都加一遍tenant_id結(jié)果查詢的時(shí)候全局表也被強(qiáng)制過(guò)濾導(dǎo)致某些基礎(chǔ)配置查不到數(shù)據(jù)。所以改造前一定要做一次全量盤(pán)點(diǎn)給每張表打上“租戶隔離、全局共享、租戶自定義”的標(biāo)簽寫(xiě)進(jìn)設(shè)計(jì)文檔里。另外一點(diǎn)加了tenant_id之后一定要順手建索引。這個(gè)字段在絕大多數(shù)查詢里都會(huì)作為等值條件出現(xiàn)沒(méi)索引的話數(shù)據(jù)量上來(lái)以后每個(gè)請(qǐng)求都是全表掃描數(shù)據(jù)庫(kù)會(huì)被拖垮。這個(gè)環(huán)節(jié)雖然簡(jiǎn)單但最檢驗(yàn)一個(gè)開(kāi)發(fā)者的細(xì)致程度。3.3 攔截器與MyBatis插件如何自動(dòng)帶租戶條件若依默認(rèn)的持久層是MyBatis要自動(dòng)追加租戶條件可以利用MyBatis-Plus的多租戶插件也可以自己在MyBatis的攔截器里寫(xiě)Interceptor。我自己更推薦直接用MyBatis-Plus插件因?yàn)槿粢辣旧砗芏郈RUD操作都已經(jīng)在MyBatis-Plus的BaseMapper里封裝好了插件能自動(dòng)覆蓋手動(dòng)寫(xiě)攔截器的話各種動(dòng)態(tài)SQL的解析兼容性是個(gè)大坑沒(méi)必要重復(fù)造輪子。使用插件的核心是配置忽略表和租戶ID列。若依的系統(tǒng)表里有一些表是不能按租戶過(guò)濾的比如系統(tǒng)用戶表是全局的但租戶的成員關(guān)系在中間表再比如菜單權(quán)限表如果每個(gè)租戶有自己的菜單就得加租戶ID如果是全局菜單就得忽略。配置ignoreTable時(shí)我建議維護(hù)一個(gè)集合明確列出所有不需要隔離的全局表而不是反過(guò)來(lái)只列需要隔離的表。因?yàn)閺陌踩嵌戎v漏配一張全局表最多是查詢數(shù)據(jù)多了點(diǎn)漏配一張租戶表就是數(shù)據(jù)泄露事故前者的風(fēng)險(xiǎn)遠(yuǎn)小于后者。實(shí)際改造中我還發(fā)現(xiàn)一個(gè)特點(diǎn)若依自帶的角色權(quán)限模型RBAC和多租戶模型疊加時(shí)會(huì)產(chǎn)生“租戶內(nèi)角色”和“系統(tǒng)級(jí)角色”的區(qū)分。也就是說(shuō)平臺(tái)管理員是超級(jí)角色而某個(gè)租戶的管理員只能管理自己租戶內(nèi)的用戶和角色。這個(gè)層次如果沒(méi)理清容易出現(xiàn)租戶管理員擁有全局權(quán)限的安全漏洞。改造時(shí)建議在角色表上增加租戶ID字段將系統(tǒng)角色和租戶角色分開(kāi)管理。3.4 改造業(yè)務(wù)代碼時(shí)最容易遺漏的三個(gè)點(diǎn)在基于若依改造業(yè)務(wù)代碼時(shí)有幾個(gè)點(diǎn)特別容易被遺漏我列出來(lái)提醒一下。第一是登錄接口。若依的登錄認(rèn)證默認(rèn)是用戶名加密碼但多租戶環(huán)境下不同租戶的用戶名可能相同比如A租戶有個(gè)adminB租戶也有個(gè)admin。如果還是只按用戶名查用戶登錄就會(huì)混亂。建議登錄表單中增加租戶編號(hào)或者通過(guò)子域名識(shí)別租戶在認(rèn)證邏輯里把“租戶ID用戶名”作為唯一憑證。第二是緩存的key要帶租戶ID。若依的Redis緩存用的很多比如登錄用戶的權(quán)限緩存、字典緩存、參數(shù)配置緩存。多租戶之后這些緩存重新設(shè)計(jì)key時(shí)一定要拼上租戶ID否則A租戶改了字典B租戶的字典也被帶偏了。第三是數(shù)據(jù)初始化。系統(tǒng)新接入一個(gè)租戶時(shí)需要給這個(gè)租戶生成默認(rèn)角色、默認(rèn)菜單權(quán)限、默認(rèn)配置。很多團(tuán)隊(duì)是手工在數(shù)據(jù)庫(kù)里插數(shù)據(jù)插漏了某個(gè)配置后面對(duì)賬的時(shí)候半天查不出來(lái)。盡量寫(xiě)成可重復(fù)執(zhí)行的初始化腳本或者在創(chuàng)建租戶的接口里串行調(diào)用初始化邏輯保證每個(gè)新租戶的初始狀態(tài)完全一致。若依的多租戶改造做起來(lái)并不難但它是“細(xì)節(jié)多、坑多”的類型。只要把表結(jié)構(gòu)、登錄、緩存、初始化這四塊想明白大部分問(wèn)題都能在前置階段規(guī)避掉。4. 從AI應(yīng)用平臺(tái)看多租戶新動(dòng)向Dify社區(qū)版1.104.1 Dify為什么需要多租戶Dify是這兩年非?；鸬拈_(kāi)源LLM應(yīng)用開(kāi)發(fā)平臺(tái)主打可視化編排AI工作流、快速創(chuàng)建知識(shí)庫(kù)問(wèn)答應(yīng)用。很多公司部署Dify社區(qū)版把它當(dāng)作公司內(nèi)部的AI應(yīng)用服務(wù)中心供不同產(chǎn)品線、不同項(xiàng)目組共用。問(wèn)題也隨之而來(lái)A項(xiàng)目組創(chuàng)建的知識(shí)庫(kù)和AgentB項(xiàng)目組能不能看到大家一起往里傳私有文檔憑什么互相泄露于是Dify社區(qū)版1.10開(kāi)始在多租戶上做文章核心目標(biāo)就是讓一個(gè)Dify平臺(tái)能安全地給多個(gè)團(tuán)隊(duì)、多個(gè)客戶使用。往深了想Dify這種AI應(yīng)用平臺(tái)的多租戶需求和傳統(tǒng)SaaS系統(tǒng)的多租戶需求本質(zhì)是一回事——資源隔離和權(quán)限控制。但它隔離的資源更“新潮”不只是數(shù)據(jù)庫(kù)表行還有自然語(yǔ)言處理相關(guān)的各種資產(chǎn)比如知識(shí)庫(kù)文檔、提示詞Prompt模板、工作流配置、大模型的API密鑰、外部工具連接配置、發(fā)布出去的Bot應(yīng)用。這些資產(chǎn)如果互相混在一起數(shù)據(jù)安全和邏輯混亂的問(wèn)題會(huì)很嚴(yán)重。舉一個(gè)實(shí)際場(chǎng)景。某家公司用Dify部署了面向不同行業(yè)的客服問(wèn)答應(yīng)用每個(gè)行業(yè)的知識(shí)庫(kù)內(nèi)容完全不同Prompt風(fēng)格也不同。如果沒(méi)有多租戶隔離A行業(yè)的客服應(yīng)用在檢索時(shí)不小心命中了B行業(yè)的知識(shí)庫(kù)內(nèi)容給用戶回復(fù)了完全不相關(guān)的答案這種體驗(yàn)會(huì)很糟糕。Dify社區(qū)版1.10的多租戶能力就是要從平臺(tái)層面解決這類問(wèn)題。4.2 多租戶對(duì)LLM應(yīng)用的關(guān)鍵影響在LLM應(yīng)用里多租戶隔離的一個(gè)特殊之處是它會(huì)影響“模型”和“知識(shí)”這兩個(gè)關(guān)鍵維度。先說(shuō)模型層面不同租戶對(duì)模型的需求不一樣有的客戶要求用私有化部署的模型有的客戶只用公開(kāi)的GPT接口有的團(tuán)隊(duì)成本敏感只允許用便宜的小模型。Dify這類平臺(tái)需要支持租戶級(jí)別的模型配置管理也就是每個(gè)租戶可以配置自己的模型供應(yīng)商和API Key其他租戶看不到也用不到。再說(shuō)知識(shí)庫(kù)層面這是最核心的部分。傳統(tǒng)多租戶的數(shù)據(jù)隔離是在關(guān)系數(shù)據(jù)庫(kù)的表上加tenant_id但知識(shí)庫(kù)的檢索邏輯通常在向量數(shù)據(jù)庫(kù)里比如Dify用Weaviate、Qdrant或Milvus存儲(chǔ)文檔的Embedding向量。向量數(shù)據(jù)庫(kù)比較常見(jiàn)的設(shè)計(jì)是“單集合Collection放全部租戶數(shù)據(jù)通過(guò)Metadata里的租戶字段過(guò)濾”或者“每個(gè)租戶一個(gè)獨(dú)立Collection”。這兩種方式各有取舍前者共享存儲(chǔ)但檢索時(shí)要依賴過(guò)濾條件漏了條件就會(huì)查到別的租戶的內(nèi)容后者隔離干凈但集合數(shù)量會(huì)隨著租戶增長(zhǎng)爆炸運(yùn)維成本高。從平臺(tái)工程的角度看Dify這種平臺(tái)的隔離設(shè)計(jì)通常是把租戶維度作為所有“資源對(duì)象”應(yīng)用、知識(shí)庫(kù)、文檔、工作流、工具的Owner然后在應(yīng)用層把tenant_id傳給向量數(shù)據(jù)庫(kù)的filter條件。這也提醒了我們?cè)贏I應(yīng)用平臺(tái)里做多租戶不只是給關(guān)系表加字段還要把隔離能力延伸到向量存儲(chǔ)、文件存儲(chǔ)、模型調(diào)用鏈路上。4.3 提示詞工程與模型配置的租戶隔離提示詞工程Prompt Engineering本來(lái)就是AI應(yīng)用開(kāi)發(fā)中很重要的一環(huán)多租戶模式下提示詞模板也成了需要隔離的資源。各個(gè)租戶的Prompt往往是基于各自的業(yè)務(wù)場(chǎng)景反復(fù)調(diào)優(yōu)過(guò)的里面可能包含業(yè)務(wù)術(shù)語(yǔ)、品牌術(shù)語(yǔ)甚至機(jī)密的流程信息。如果租戶A的Prompt能輕易被租戶B查看或復(fù)制這不是簡(jiǎn)單的功能缺失這就是泄密。從開(kāi)發(fā)角度講Prompt模板的隔離要注意“模板級(jí)”和“實(shí)例級(jí)”兩個(gè)層次。比如平臺(tái)管理員定義了全局公共模板租戶管理員可以復(fù)制、改寫(xiě)但不能影響其他租戶。這里的做法通常是在Prompt表上增加一個(gè)字段標(biāo)識(shí)作用域全局、租戶、私有查詢列表時(shí)根據(jù)當(dāng)前租戶ID做數(shù)據(jù)過(guò)濾同時(shí)允許通過(guò)“繼承”機(jī)制讓租戶基于全局模板創(chuàng)建自己的版本。至于模型配置Dify社區(qū)版1.10在這塊做得比較細(xì)支持在不同工作區(qū)內(nèi)配置不同的模型供應(yīng)商。多租戶環(huán)境下管理員為每個(gè)租戶配置模型配額比如每個(gè)租戶每月能調(diào)用多少次大模型接口、最多并發(fā)多少請(qǐng)求防止某個(gè)租戶把整個(gè)平臺(tái)的模型調(diào)用額度燒光。從業(yè)務(wù)開(kāi)發(fā)的角度看這種配額管理也提醒我們多租戶不僅是數(shù)據(jù)隔離還要做“資源治理”。4.4 從傳統(tǒng)SaaS到AI應(yīng)用平臺(tái)多租戶的變與不變聊完Dify我忍不住想說(shuō)說(shuō)傳統(tǒng)SaaS多租戶和AI應(yīng)用平臺(tái)多租戶之間的共性與差異。核心思路是不變的租戶識(shí)別、上下文傳遞、數(shù)據(jù)隔離、權(quán)限控制、資源配額這些方法論完全通用。變化在于隔離的“介質(zhì)”和“粒度”傳統(tǒng)SaaS主要隔離關(guān)系表里的結(jié)構(gòu)化數(shù)據(jù)AI應(yīng)用平臺(tái)還要隔離非結(jié)構(gòu)化文檔、Embedding向量、Prompt模板、模型通道。這就導(dǎo)出了一個(gè)很重要的問(wèn)題多租戶不是一個(gè)一次性做完的功能而是一套需要跟隨業(yè)務(wù)形態(tài)持續(xù)演化的架構(gòu)能力。你今天用若依框架可以把tenant_id加到100張表上明天你引入Dify做AI應(yīng)用你得重新審視文件存儲(chǔ)的路徑隔離、向量數(shù)據(jù)庫(kù)的Collection策略、大模型密鑰的租戶授權(quán)。多租戶的能力建設(shè)本質(zhì)上就是一套平臺(tái)級(jí)基礎(chǔ)設(shè)施在演進(jìn)它不會(huì)因?yàn)槟銚Q了一個(gè)技術(shù)棧或者多了一個(gè)中間件就消失反而會(huì)反復(fù)出現(xiàn)在你面前。Dify社區(qū)版1.10的多租戶是對(duì)“共建一套多租戶平臺(tái)”思想在AI場(chǎng)景的一次實(shí)踐。如果你之前只在傳統(tǒng)CRUD系統(tǒng)里用過(guò)若依的多租戶擴(kuò)展現(xiàn)在通過(guò)Dify的多租戶功能反過(guò)來(lái)觀察AI平臺(tái)的數(shù)據(jù)隔離和權(quán)限控制你會(huì)發(fā)現(xiàn)很多設(shè)計(jì)理念是相通的這對(duì)你以后設(shè)計(jì)平臺(tái)型產(chǎn)品會(huì)非常有幫助。5. 多租戶業(yè)務(wù)開(kāi)發(fā)中的常見(jiàn)問(wèn)題與排查技巧5.1 租戶條件沒(méi)帶上的典型表現(xiàn)多租戶系統(tǒng)上線后最常見(jiàn)的故障就是“串?dāng)?shù)據(jù)”核心原因逃不出這幾類第一某個(gè)查詢SQL是手寫(xiě)的沒(méi)有經(jīng)過(guò)MyBatis-Plus插件也沒(méi)手動(dòng)拼tenant_id第二join的子查詢里插件只處理了主表沒(méi)處理子表第三使用了聚合分析功能比如報(bào)表模塊SQL是從數(shù)據(jù)庫(kù)直接導(dǎo)出的沒(méi)有走應(yīng)用層。這幾種情況的表現(xiàn)都一樣某個(gè)租戶的頁(yè)面里出現(xiàn)了其他租戶的數(shù)據(jù)。排查的思路要先看日志。強(qiáng)烈建議在應(yīng)用的查詢?nèi)罩纠锇炎鈶鬒D、SQL、參數(shù)完整打出來(lái)這樣一旦出現(xiàn)串?dāng)?shù)據(jù)馬上能定位到是哪個(gè)接口、哪條SQL漏了租戶條件。如果沒(méi)有日志排查就會(huì)變成大海撈針要在成百上千條SQL里靠猜效率極低。其次是復(fù)現(xiàn)路徑讓用戶盡量復(fù)現(xiàn)一次把完整請(qǐng)求鏈路抓出來(lái)看SQL執(zhí)行計(jì)劃里有沒(méi)有按tenant_id索引去過(guò)濾。解決這問(wèn)題最忙的辦法就是上一道“兜底防線”。拿MyBatis-Plus來(lái)說(shuō)它的多租戶插件雖然會(huì)處理大部分SQL但原生SQL、自定義SQL沒(méi)法保證。我的做法是做一個(gè)SQL審計(jì)組件定期掃描慢查詢?nèi)罩竞腿縎QL日志凡是發(fā)現(xiàn)業(yè)務(wù)表查詢沒(méi)有帶租戶條件自動(dòng)告警更進(jìn)一步可以在測(cè)試環(huán)境編寫(xiě)自動(dòng)化測(cè)試用例模擬多租戶請(qǐng)求校驗(yàn)返回結(jié)果中不包含其他租戶的數(shù)據(jù)把問(wèn)題擋在發(fā)布之前。5.2 租戶上下文在異步線程里丟失前面提到ThreadLocal綁定當(dāng)前線程異步場(chǎng)景下會(huì)失效。這個(gè)問(wèn)題在代碼里一旦出現(xiàn)就是偶發(fā)性問(wèn)題特別難排查。比如一個(gè)導(dǎo)出Excel的操作Controller把請(qǐng)求提交給線程池處理線程池里的線程沒(méi)有租戶上下文數(shù)據(jù)查詢獲取租戶ID時(shí)拿到null查詢自然就沒(méi)帶租戶條件導(dǎo)出的數(shù)據(jù)可能包含所有租戶的。有些系統(tǒng)用Async注解或者用CompletableFuture、Spring的TaskExecutor都會(huì)遇到這個(gè)問(wèn)題。解決思路有幾種。最直接的是把租戶ID作為參數(shù)顯式傳給異步任務(wù)在線程內(nèi)部重新設(shè)置TenantContext執(zhí)行完清理如果用的是ThreadLocal可以用阿里開(kāi)源的TransmittableThreadLocalTTL它能在線程池創(chuàng)建任務(wù)時(shí)把父線程的上下文值拷貝給子線程。這兩種方式都可行但都要注意一點(diǎn)任務(wù)執(zhí)行完成后的清理動(dòng)作不能省否則線程池里的線程會(huì)被“污染”下一個(gè)用戶請(qǐng)求就可能拿到上一個(gè)租戶的上下文。我個(gè)人更推薦第一種顯式傳參。因?yàn)門(mén)TL雖然用起來(lái)方便但它是通過(guò)“魔法”透?jìng)魃舷挛拇a里看不到租戶來(lái)自哪里出了問(wèn)題很不好定位。顯式傳參雖然多寫(xiě)幾行代碼但鏈路清晰、可審計(jì)、可測(cè)試對(duì)系統(tǒng)長(zhǎng)期維護(hù)更有利。如果代碼庫(kù)里有大量異步的地方還可以封裝一個(gè)異步任務(wù)工具類統(tǒng)一處理租戶上下文的設(shè)置和清理。5.3 數(shù)據(jù)索引與查詢性能的取舍加了tenant_id之后必然帶來(lái)查詢性能的問(wèn)題。絕大多數(shù)多租戶查詢都是“tenant_id 業(yè)務(wù)條件”的組合如果只在業(yè)務(wù)字段上建了索引沒(méi)把tenant_id放進(jìn)去數(shù)據(jù)庫(kù)會(huì)先過(guò)濾出很多錯(cuò)誤租戶的數(shù)據(jù)再做二次過(guò)濾數(shù)據(jù)量大時(shí)性能會(huì)很差。這里有一個(gè)實(shí)用的索引設(shè)計(jì)原則所有高頻查詢的索引應(yīng)該把tenant_id放在索引的最前面而唯一性約束比如一個(gè)租戶內(nèi)訂單編號(hào)唯一就必須建聯(lián)合唯一索引(tenant_id, order_no)。另外報(bào)表類查詢往往需要按照時(shí)間維度聚合這時(shí)可以考慮(tenant_id, create_time)組合索引避免每個(gè)租戶去掃描整張表的數(shù)據(jù)。不過(guò)索引也不是越多越好。tenant_id作為索引前綴會(huì)顯著增加索引占用空間寫(xiě)放大也會(huì)變大。我曾經(jīng)維護(hù)過(guò)一張大表索引數(shù)量一度達(dá)到七八個(gè)每個(gè)索引都從tenant_id開(kāi)始結(jié)果寫(xiě)入性能明顯下降。權(quán)衡之下可以把一些不重要的查詢改成覆蓋索引或者考慮用分區(qū)表按租戶ID做Hash分區(qū)這樣即便某些SQL沒(méi)有走最佳索引也只會(huì)掃描對(duì)應(yīng)分區(qū)能控制住代價(jià)。5.4 租戶級(jí)配置與全局配置混淆多租戶系統(tǒng)里經(jīng)常會(huì)有兩類配置一類是全局配置比如系統(tǒng)級(jí)別的Logo、默認(rèn)語(yǔ)言、默認(rèn)時(shí)區(qū)另一類是租戶級(jí)配置比如租戶自己的域名、認(rèn)證方式、功能開(kāi)關(guān)、積分規(guī)則。如果這兩類配置放在同一張表里又沒(méi)有作用域字段就會(huì)出現(xiàn)一個(gè)租戶改了全局配置所有租戶都被影響的情況。我的經(jīng)驗(yàn)是配置表的設(shè)計(jì)要么分開(kāi)要么顯式加一個(gè)scope字段字段取值是GLOBAL或TENANT。讀取配置時(shí)先查租戶級(jí)查不到再查全局這樣既能實(shí)現(xiàn)“默認(rèn)全局覆蓋租戶自定義覆蓋”的效果又能保證配置項(xiàng)的靈活性。另外配置變更最好要有版本記錄和發(fā)布審批尤其是那些影響了所有租戶的全局配置一旦改錯(cuò)影響面是整個(gè)平臺(tái)的租戶。多租戶系統(tǒng)里配置的管理權(quán)限也要嚴(yán)格區(qū)分平臺(tái)管理員能改全局配置租戶管理員只能改自己租戶的配置。這個(gè)權(quán)限模型如果沒(méi)做好很容易出現(xiàn)租戶管理員修改了全局配置導(dǎo)致其他租戶功能異常的情況。權(quán)限的劃分要和數(shù)據(jù)庫(kù)層的作用域字段保持一致的邏輯不要只在前端做界面控制后端接口也要校驗(yàn)操作者的角色和租戶范圍。5.5 多租戶上線后的運(yùn)維監(jiān)控多租戶系統(tǒng)上線后的運(yùn)維比普通系統(tǒng)多了一個(gè)新維度按租戶監(jiān)控。以前你只需要關(guān)心系統(tǒng)整體負(fù)載、接口RT、數(shù)據(jù)庫(kù)連接數(shù)多租戶之后你還會(huì)關(guān)心某些租戶是不是在拖著整個(gè)系統(tǒng)跑——比如某個(gè)大租戶的數(shù)據(jù)量特別大查詢特別慢導(dǎo)致數(shù)據(jù)庫(kù)CPU飆升所有租戶的請(qǐng)求都變慢了。這種“一租戶出問(wèn)題平臺(tái)陪跑”的情況在多租戶架構(gòu)里尤其常見(jiàn)。建議在監(jiān)控體系里增加租戶維度的指標(biāo)比如各租戶的接口調(diào)用量、SQL慢查詢數(shù)量、緩存命中率、文件存儲(chǔ)用量定期輸出報(bào)表。一旦某租戶的數(shù)據(jù)量或請(qǐng)求量異常增長(zhǎng)運(yùn)維團(tuán)隊(duì)能提前介入不管是做數(shù)據(jù)歸檔、獨(dú)立資源池還是限流總比等到系統(tǒng)整體故障再拍腦袋強(qiáng)。我見(jiàn)過(guò)有團(tuán)隊(duì)在網(wǎng)關(guān)層直接實(shí)現(xiàn)了“租戶級(jí)限流”某個(gè)租戶的QPS超過(guò)閾值就自動(dòng)降級(jí)雖然做得粗暴了點(diǎn)但確實(shí)有效保護(hù)了整體系統(tǒng)的穩(wěn)定性。多租戶系統(tǒng)交付之后還有一個(gè)容易被忽視的長(zhǎng)期注意事項(xiàng)數(shù)據(jù)生命周期管理。不同租戶的數(shù)據(jù)保留策略可能不同有些租戶要求永久保存有些要求到期自動(dòng)清理數(shù)據(jù)或者歸檔。這些需求如果不提前梳理后面會(huì)被數(shù)據(jù)合規(guī)、服務(wù)器存儲(chǔ)成本等問(wèn)題追著跑。多租戶不應(yīng)該只關(guān)注“數(shù)據(jù)怎么隔離”還要關(guān)注“數(shù)據(jù)怎么治理”。6. 關(guān)于多租戶開(kāi)發(fā)的幾點(diǎn)個(gè)人體會(huì)做過(guò)多租戶項(xiàng)目之后我自己最大的感受是多租戶不是一個(gè)功能而是一種貫穿所有業(yè)務(wù)模塊的架構(gòu)約束。它對(duì)你系統(tǒng)的侵入是全面的從登錄認(rèn)證到數(shù)據(jù)庫(kù)表設(shè)計(jì)從緩存Key到異步任務(wù)從權(quán)限模型到運(yùn)維監(jiān)控每一層都要有租戶的維度。如果你只在某一層做了處理其他層還按單租戶的方式寫(xiě)代碼那么數(shù)據(jù)安全問(wèn)題就是一顆不知道什么時(shí)候會(huì)引爆的雷。如果你們團(tuán)隊(duì)正準(zhǔn)備做多租戶改造我建議先別急著寫(xiě)代碼干三件事第一把現(xiàn)有所有表和數(shù)據(jù)資源掃描一遍按“租戶隔離、全局共享、租戶自定義”分類出一份清晰的隔離清單第二梳理異步場(chǎng)景把所有線程池、定時(shí)任務(wù)、消息隊(duì)列的租戶上下文傳遞方案確定下來(lái)第三提前約定好租戶ID的生成規(guī)則和傳遞規(guī)范把它寫(xiě)進(jìn)團(tuán)隊(duì)的開(kāi)發(fā)規(guī)范文檔里。這三件事做完后面的開(kāi)發(fā)會(huì)順暢得多。還有一個(gè)小技巧是很多博客不會(huì)提的開(kāi)發(fā)階段就要養(yǎng)成“打印租戶ID”的習(xí)慣。每次接口請(qǐng)求的日志、每次SQL執(zhí)行的日志、每次緩存讀寫(xiě)的日志都把租戶ID帶上。這樣調(diào)試串?dāng)?shù)據(jù)、排查權(quán)限問(wèn)題的時(shí)候你才會(huì)發(fā)現(xiàn)這個(gè)習(xí)慣幫你省了多少時(shí)間。沒(méi)有任何監(jiān)控能取代一條條能還原現(xiàn)場(chǎng)、可檢索的日志鏈路。最后再分享一個(gè)判斷標(biāo)準(zhǔn)如果你的系統(tǒng)里新同學(xué)接手后能很快說(shuō)清楚“哪些表是租戶隔離的、哪些是全局的”這些代碼的隔離邊界是自然成立的多租戶改造就算成功了。反之如果連老員工都要靠翻代碼猜來(lái)猜去哪張表帶租戶ID那就說(shuō)明隔離設(shè)計(jì)還不到位系統(tǒng)遲早要出問(wèn)題。希望這篇關(guān)于多租戶業(yè)務(wù)開(kāi)發(fā)的分享能幫你少踩幾個(gè)坑。