[Azure] Multi-Tenancy Application #1, 設計概念 — FAQ

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是多租戶（Multi-Tenancy）？

• A簡: 多租戶是一套應用切割資源，安全隔離，讓多個客戶共享同平台與基礎設施的架構。
• A詳: 多租戶指一套應用（與其基礎設施）同時服務多個獨立客戶（租戶），在邏輯層面進行隔離，確保資料安全與體驗獨立。相較單租戶每客戶一套系統，多租戶能有效降低成本、提升維運效率與擴展彈性。常見的隔離設計包含：每租戶一個資料庫（Separated DB）、共用資料庫但分不同 Schema（Separate Schemas）、或共用資料庫與 Schema 以欄位區分（Shared Schema）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, A-Q16, B-Q1

A-Q2: 什麼是 SaaS（Software as a Service）？

• A簡: SaaS 透過雲端交付軟體服務，使用者訂閱即可用，常結合多租戶以提升效率。
• A詳: SaaS 是一種軟體交付模式，供應商在雲端託管應用，客戶以訂閱方式使用。SaaS 常採多租戶設計，以在同一套平台服務多客戶，降低營運與維護成本，並加速功能佈署。SaaS 的關鍵是標準化、可配置、可擴展與隔離安全，代表案例包含 CRM、HRM、LMS 等雲端服務。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q5, B-Q10

A-Q3: 什麼是 PaaS（Platform as a Service）？

• A簡: PaaS 提供應用執行與開發平台，簡化佈署與維運，利於快速建置多租戶系統。
• A詳: PaaS 是雲端提供的應用平台與運行環境，涵蓋 OS、執行框架與部分中介軟體，開發者專注於程式與資料。以 Azure 為例，使用 PaaS 可快速佈署 Web App、資料庫並自動伸縮，減少基礎建設負擔，支援多租戶應用的需求，如分租戶連線、路由與監控等。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q20, B-Q10

A-Q4: 什麼是「租戶」（Tenant）？

• A簡: 租戶是共享同一應用的獨立客戶實體，擁有隔離的資料與配置。
• A詳: 租戶代表使用同一套多租戶應用的客戶實體，可能是公司、部門或組織。每個租戶擁有獨立的資料、使用者與設定，並透過租戶識別（TenantID）在應用與資料層實現隔離。正確的租戶解析與授權，是避免資料外洩與保證體驗一致的關鍵。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, B-Q5

A-Q5: 為什麼雲端 SaaS 常採多租戶架構？

• A簡: 多租戶降低成本、集中維運、加速佈署更新，並能彈性擴充客戶數。
• A詳: 多租戶能以同一平台服務多客戶，節省硬體、授權與運維成本；佈署一次，即可全體租戶受惠，縮短傳遞新功能與修補的時間；資源集中管理，更利於監控與自動化。相對地，需嚴謹設計資料隔離、擴充性與客製化能力，才能兼顧安全與彈性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, A-Q16

A-Q6: 資料隔離在多租戶中的意義是什麼？

• A簡: 確保不同租戶的資料互不可見，避免混用與外洩，是安全與合規核心。
• A詳: 資料隔離確保租戶間資料不互相可見或影響，避免程式錯誤或惡意攻擊造成外洩。隔離可在不同層次實作：資料庫級（最強）、Schema 級（中等）、資料列/欄位級（最弱）。選擇取決於安全需求、成本與維運複雜度。強隔離多用於高合規場景，弱隔離適合成本敏感的 SaaS。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q6

A-Q7: Separated DB、Separate Schema、Shared Schema 有何差異？

• A簡: 依隔離層級與成本不同，分資料庫級、Schema 級與同表欄位級三種模式。
• A詳: Separated DB 每租戶一個資料庫，隔離最強、成本最高；Separate Schemas 共用資料庫但不同 Schema，隔離中等、成本較低；Shared Schema 共用資料庫與 Schema，以 TenantID 欄位區分，成本最低、風險最大。三者在安全、擴充、備份、查詢複雜度與維運流程上皆有明顯差異。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, A-Q9, A-Q10

A-Q8: 什麼是 Separated DB 模式？

• A簡: 每租戶一個獨立資料庫，最強隔離，維運與成本相對較高。
• A詳: Separated DB 將每個租戶的資料放在獨立資料庫。優點是強隔離、易於備份/還原、合規友善；缺點是資料庫數量多，連線、授權與佈署成本提升。常應用於高安全、高合規或大型客戶要求資料完全獨立的場景。需搭配良好的自動化佈署與連線管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q9

A-Q9: 什麼是 Separate Schemas 模式？

• A簡: 共用同一資料庫，但以不同 Schema 隔離各租戶的資料表。
• A詳: Separate Schemas 在單一資料庫中為每租戶建立一組表（不同 Schema）。優點是成本介於中間、隔離清楚，工程失誤造成資料混用機率低；缺點是部署與遷移腳本較複雜，表集合量級隨租戶數成長。適合在安全與成本間取得平衡的 SaaS 產品。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q14

A-Q10: 什麼是 Shared Schema 模式？

• A簡: 所有租戶共用相同表結構，以 TenantID 欄位區分資料。
• A詳: Shared Schema 讓所有租戶共用同一組表，透過 TenantID 欄位區分資料。優點是成本與設計最簡潔；缺點是查詢必須嚴格帶租戶過濾，否則極易資料外洩。擴充常需名值（EAV）資料模型，增加查詢與索引難度。適用於成本敏感、客製化較少的場景。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q12

A-Q11: 三種模式的成本差異是什麼？

• A簡: Separated DB 成本最高，Separate Schemas 次之，Shared Schema 最低。
• A詳: 成本包含資料庫授權/服務費、維運人力、佈署自動化與監控。Separated DB 需為每租戶維護 DB 與備份，成本最高；Separate Schemas 共享 DB 資源，成本適中；Shared Schema 共享最大，最省成本但需投入更多工程控制與測試以避免外洩風險。選擇取決於商業模型與風險承受度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q15

A-Q12: 三種模式的安全隔離差異？

• A簡: DB 級隔離最強、Schema 級次之、欄位級最弱且最依賴程式正確性。
• A詳: DB 級隔離靠物理/邏輯資料庫邊界，工程誤操作也難跨界；Schema 級隔離以不同命名空間與權限降低混用風險；Shared Schema 依賴應用層過濾與資料庫權限，任何漏加 TenantID 的查詢都可能外洩。合規越嚴的情境越傾向使用更強隔離。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q12

A-Q13: 在資料擴充（Extensibility）上的差異？

• A簡: DB/Schema 模式可直接加欄位；Shared Schema 常用名值模型或預留欄位。
• A詳: Separated DB 與 Separate Schemas 可採傳統加欄位與遷移流程，維持良好型別與查詢效率。Shared Schema 難以為個別租戶加欄，常以預留欄位或名值（EAV）模型因應；但 EAV 使查詢與索引複雜，需權衡易用性與彈性。選擇依客製化強度與維運能力決定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q7, B-Q8

A-Q14: 何謂 Name-Value（EAV）資料模型？

• A簡: 以屬性名稱與值記錄動態欄位，提升彈性但犧牲查詢與型別安全。
• A詳: EAV 將動態屬性拆成屬性定義與屬性值兩表，以 name/value 方式儲存，使每租戶可擴充不同欄位。優點是結構彈性大；缺點是查詢需多表 Join 或聚合，型別與約束不易表達，索引策略困難。常用於 Shared Schema 的客製化需求，宜慎用並輔以快取與預計算。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, C-Q8

A-Q15: 為何 Shared Schema 中的查詢容易出錯？

• A簡: 因高度依賴程式加上租戶過濾，漏寫 TenantID 即可能資料外洩。
• A詳: Shared Schema 所有租戶資料同表共存，每次查詢都須以 TenantID 正確過濾。任何遺漏或條件拼寫錯誤，都會將他租戶資料帶入結果或統計。避免方法包含：ORM 全域過濾、視圖/儲存程序固定條件、測試覆蓋、靜態分析與最小權限等防呆機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, D-Q1

A-Q16: 多租戶應用的核心價值是什麼？

• A簡: 降低成本、縮短交付、集中維運，並支援規模化成長與彈性配置。
• A詳: 多租戶讓供應商以單一平台服務多客戶，節省基礎設施與人力；全域佈署提升交付速度；集中監控與自動化使品質一致。對客戶而言，享有雲端彈性與持續更新。前提是良好的隔離、安全、防呆與擴充設計，以避免資料外洩與效能退化。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q7

A-Q17: 何時應選擇 Separated DB？

• A簡: 高合規、高保密、大客戶獨立需求，或需獨立備份/還原時。
• A詳: 當客戶要求資料物理或邏輯完全隔離、需獨立維運或審計，或有高價值資料需最小化共用風險時，選擇 Separated DB 較合適。其劣勢是成本與自動化需求提高，宜建立佈署腳本、連線池管理與備份編排。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, B-Q1, B-Q9

A-Q18: 何時應選擇 Separate Schemas？

• A簡: 需兼顧隔離與成本，且可承擔中等複雜佈署與遷移。
• A詳: 若安全需求高於 Shared Schema，但又不想承擔每租戶一庫的成本與複雜度，Separate Schemas 是務實選擇。它降低資料混用風險，同時維持可接受的維運成本；但需管理大量表集合與一致性的遷移流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q2, B-Q14

A-Q19: 何時應選擇 Shared Schema？

• A簡: 成本敏感、租戶差異小、可用工程護欄嚴控查詢風險時。
• A詳: 若多數租戶使用相同資料結構、客製化低，且團隊能以 ORM 全域過濾、權限管控與完善測試守住風險，Shared Schema 可提供最佳成本效率與可擴展性。但必須面對 EAV、索引與查詢複雜度帶來的工程挑戰。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q3, B-Q12

A-Q20: Azure 與 ASP.NET MVC 在多租戶中的角色？

• A簡: Azure 提供平台與資料服務，MVC 提供路由與邏輯實作租戶解析與隔離。
• A詳: 在 Azure 上可用 PaaS/資料庫服務承載多租戶應用；ASP.NET MVC 透過路由、Filter 與 DI 注入租戶上下文，實作租戶解析與授權。結合配置中心與自動化佈署，能快速上線新租戶與統一維運。此組合降低門檻並提升交付速度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, C-Q1

A-Q21: 什麼是租戶感知（Tenant-aware）查詢？

• A簡: 任何查詢都需帶入當前租戶識別，保證只讀寫該租戶資料。
• A詳: 租戶感知查詢要求在資料存取時自動或強制加入 TenantID 條件，避免跨租戶讀寫。可透過 ORM 全域過濾、視圖、儲存程序或 Row-Level Security 等手段實作。對 Shared Schema 更是強制要求；對其他模式也能作為額外的安全網。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, B-Q12, C-Q2

A-Q22: Schema 級與 DB 級隔離有何不同？

• A簡: DB 級邊界更硬、權限更清晰；Schema 級共享多，需更嚴謹權限控管。
• A詳: DB 級隔離透過不同資料庫實現，用戶、登入與備份皆可獨立管理；Schema 級仍共享實例與資源，需嚴格設定 Schema 權限、命名規則與部署腳本以避免混用。兩者在故障域、備份範圍與成本上亦有差異。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, A-Q9, B-Q6

A-Q23: 多租戶與單租戶應用的最大差異？

• A簡: 多租戶需處理共享資源下的隔離、安全、擴充與維運標準化。
• A詳: 單租戶關注單一客戶需求；多租戶要兼顧多客戶，要求可參數化、強隔離、安全與自動化。資料模型需能支援擴充，部署與遷移要跨租戶一致，監控與費用分攤也更複雜。工程與產品管理的協同更關鍵。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q14

A-Q24: 為何設計多租戶是挑戰？

• A簡: 要同時滿足安全隔離、擴充彈性、維運自動化與成本效益。
• A詳: 多租戶涉及跨層面的取捨：資料隔離等級、擴充資料的彈性、查詢與索引複雜度、遷移一致性、備份恢復策略與監控告警。任何環節不足都可能導致外洩、效能退化或維運成本飆升，因此需系統化設計與完善測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q12, B-Q14

A-Q25: Salesforce 與多租戶的關聯？

• A簡: Salesforce 成功推廣 SaaS，也讓多租戶設計模式廣為人知與採用。
• A詳: Salesforce 透過雲端 CRM 的成功，示範了多租戶在商業上可行與可擴展。其經驗促使業界重視資料隔離、客製化與升級一致性等議題，形成多租戶設計的實務共識，進而推動 SaaS 普及。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q5

Q&A 類別 B: 技術原理類

B-Q1: Separated DB 的運作流程是什麼？

• A簡: 解析租戶後選擇對應資料庫連線，於 DB 邊界提供最強隔離與獨立維運。
• A詳: 原理說明：以租戶識別（子網域、路由、Header）解析出 TenantId，查租戶設定表取得該租戶的連線字串。關鍵步驟：1) Tenant 解析；2) 取得連線資訊；3) 建立 DbContext/連線；4) 執行操作；5) 依租戶做備份/監控。核心組件：TenantResolver、ConnectionProvider、DbContextFactory、Provisioning/Backup 模組。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q3

B-Q2: Separate Schemas 的運作流程與組件？

• A簡: 解析租戶後將資料操作路由至對應 Schema，透過權限與命名隔離。
• A詳: 原理說明：所有租戶共用同 DB，以 schema 前綴（如 t123.Orders）區隔。關鍵步驟：1) 租戶解析；2) 組合 Schema 名稱；3) ORM 映射至動態 Schema；4) 以最小權限限制跨 Schema。核心組件：SchemaNameProvider、動態映射（EF Fluent API）、Migration Orchestrator、權限管理與命名規範。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, C-Q4, C-Q5

B-Q3: Shared Schema 的運作流程與風險控制？

• A簡: 所有租戶共用表，透過 TenantID 過濾並以全域護欄防止漏過濾。
• A詳: 原理說明：在共用表上所有 CRUD 必須攜帶 TenantID 篩選。關鍵步驟：1) 租戶解析；2) 建立租戶上下文；3) ORM 層套用全域過濾；4) 寫入時自動填入 TenantID；5) 以視圖/儲存程序固定過濾。核心組件：TenantContext、QueryFilter、Repository、審計與權限。風險控制：測試、靜態分析與最小權限。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q15, C-Q2, C-Q6

B-Q4: 租戶解析（Tenant Resolution）如何運作？

• A簡: 依子網域、路由或請求標頭辨識租戶，建立租戶上下文供全程使用。
• A詳: 原理說明：在中介層或 MVC Filter 擷取線索（如 acme.app.com、/t/acme、Header:X-Tenant），對照租戶註冊表取得租戶配置。關鍵步驟：1) 擷取線索；2) 驗證與查表；3) 建立 TenantContext；4) 注入 DI 容器；5) 供後續資料層使用。核心組件：TenantResolver、TenantStore、Pipeline Filter/Handler。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, C-Q1

B-Q5: 租戶識別（TenantID）設計原則？

• A簡: 全域唯一、不可猜、短小易索引，與顯示名稱分離並穩定不變。
• A詳: 原理說明：TenantID 作為資料關聯與過濾鍵。關鍵設計：1) 唯一且不可預測（GUID/ULID 或雪花 ID）；2) 與租戶代號/名稱分離；3) 作為索引首欄以利篩選；4) 避免重用或重命名；5) 在寫入流程自動填入。核心組件：IdGenerator、索引策略、審計欄位。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q21, C-Q7

B-Q6: 在資料庫層進行隔離的機制有哪些？

• A簡: 利用 DB 邊界、Schema 權限、視圖/儲存程序與嚴格命名策略實現隔離。
• A詳: 原理說明：DB 級隔離靠不同資料庫；Schema 級以命名空間與權限限制；Shared Schema 則以視圖加固定過濾、儲存程序封裝操作、角色權限最小化。關鍵步驟：定義安全邊界、建立最小權限角色、封裝存取路徑。核心組件：角色/權限、視圖、SP、命名規約。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, A-Q12

B-Q7: 多租戶資料擴充（Extensibility）機制與取捨？

• A簡: 直加欄位最簡；EAV 最彈性但複雜；預留欄位折衷，需依需求選擇。
• A詳: 原理說明：擴充可用三路徑：1) 傳統加欄（DB/Schema 模式首選）；2) EAV（Shared Schema 客製化）；3) 預留欄位（通用但可讀性差）。關鍵步驟：定義需求類型、選擇模型、設計索引與查詢模式。核心組件：遷移工具、EAV 表結構、查詢模板與快取。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, A-Q14, C-Q8

B-Q8: 名值（EAV）模型的技術原理與索引？

• A簡: 以屬性定義與值表存動態欄，靠組合索引與預計算維持效能。
• A詳: 原理說明：Entity、Attribute、Value 三表結構，查詢需以 AttributeId、TenantId、EntityId 組合關聯。關鍵步驟：設計複合索引（TenantId, AttributeId, EntityId）、避免跨多屬性深度 Join、以物化檢視/快取加速常用查詢。核心組件：索引、聚合管線、快取與封裝 API。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q14, C-Q8

B-Q9: 備份與還原在三種架構中的差異與流程？

• A簡: Separated DB 可逐租戶備份；Schema 模式需選集還原；Shared 需邏輯匯出。
• A詳: 原理說明：DB 模式可直接 per-DB 備份/還原。Schema 模式可透過同庫內選集腳本或複製表進行。Shared Schema 多以租戶範圍匯出（BCP/ETL）與重播來還原。關鍵步驟：定義 RPO/RTO、設計租戶範圍的備份策略、定期演練。核心組件：Backup Orchestrator、ETL/匯出工具、審計日誌。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, C-Q9

B-Q10: 新租戶上線（Provisioning）的技術流程？

• A簡: 註冊→核驗→配置資源（DB/Schema/設定）→種子資料→監控與帳單對接。
• A詳: 原理說明：依架構建立相應資源。關鍵步驟：1) 接收租戶資料與驗證；2) 建立 DB/Schema 或寫入租戶表；3) 執行遷移/建立表；4) 匯入種子與權限；5) 建立監控與成本標籤；6) 通知啟用。核心組件：Provisioning Service、Migration Runner、Config Store、觀測性整合。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, C-Q4, D-Q8

B-Q11: 效能最佳化：Shared Schema 的索引與分割？

• A簡: 以 TenantID 為前綴複合索引，必要時分割/分片，並避免跨租戶掃描。
• A詳: 原理說明：確保所有主要查詢以 TenantID 起手，建立（TenantID, Key/Date）複合索引，減少掃描。關鍵步驟：找出熱查詢、設計覆蓋索引、考慮分割（Range/Hash）或邏輯分片。核心組件：索引設計、統計資料、查詢計畫監控、分割策略與慢查詢告警。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q7, D-Q2

B-Q12: 設計安全護欄避免漏加 TenantID 的機制？

• A簡: ORM 全域過濾、固定視圖/SP、靜態分析與最小權限四重防線。
• A詳: 原理說明：以多層防護避免人為疏失。關鍵步驟：1) ORM 設全域查詢過濾；2) 以視圖/SP 封裝資料存取；3) 程式碼掃描關鍵表的無租戶條件查詢；4) DB 權限限制直接查表。核心組件：QueryFilter、Safe Repository、SQL 風險規則、RBAC 與審計。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q15, C-Q2, C-Q6, D-Q1

B-Q13: 記錄與稽核：如何標註租戶脈絡？

• A簡: 日誌與審計欄位需帶 TenantID，串接追蹤 ID 以便追查與告警。
• A詳: 原理說明：在應用與資料層記錄租戶上下文。關鍵步驟：1) Log/Telemetry 附帶 TenantID、UserID、TraceId；2) 資料表審計欄位（CreatedBy/At, TenantID）；3) 集中化日誌查詢與告警。核心組件：Log 中介軟體、審計攔截器、觀測性平台（Metrics/Trace/Logs）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, D-Q8

B-Q14: 版本升級與資料庫遷移在多租戶的策略？

• A簡: 擬定跨租戶一致的 Migration 流程，支援前後相容與分批回滾。
• A詳: 原理說明：遷移需避免跨租戶不一致。關鍵步驟：1) 識別向前/向後相容變更；2) 分層推出（金絲雀）與回滾計畫；3) 為 DB/Schema 模式製作 per-tenant 或 per-schema 腳本；4) 對 Shared 模式做好資料對應與填補。核心組件：Migration Orchestrator、版本旗標、健康檢查與變更審批。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q4, D-Q4

B-Q15: 成本模型：為何 Shared Schema 成本最低？

• A簡: 最大化資源共享、單一結構佈署最簡，機器與授權使用效率最高。
• A詳: 原理說明：共用資料庫與表結構避免多實例資源閒置，佈署與監控集中化降低運維成本。關鍵步驟：密集監控熱點、以索引與分割維持效能、強化工程護欄以降低外洩風險。核心組件：集中式部署、共享資源池、成本監控與告警。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q11

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何在 ASP.NET MVC 以子網域解析租戶？

• A簡: 透過路由/Filter 擷取子網域，查表取得租戶設定，注入 TenantContext。
• A詳: 步驟：1) 於 Global.asax 或 Startup 設置自訂路由/Filter；2) 從 Host 解析子網域；3) 查租戶表取得 TenantId 與配置；4) 建立 TenantContext 注入 DI；5) 於控制器透過服務使用。程式碼：var sub = request.Url.Host.Split(‘.’)[0]; var t = tenantStore.Find(sub); 注意：驗證租戶狀態、避免 DNS 萬用解析誤判、加上快取與失敗回退。最佳實踐：將解析邏輯封裝於中介層。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, A-Q20

C-Q2: 如何在 EF6 實作租戶過濾（Repository 範例）？

• A簡: 以 Repository 注入 TenantId，統一加 Where(t => t.TenantId==ctx.Tid)。
• A詳: 步驟：1) 定義 ITenantContext 暴露 TenantId；2) Repository 的 Query 基底方法自動加過濾；3) Save 時填入 TenantId。程式碼：query.Where(e => e.TenantId==tenantContext.Id); 注意：避免 DbSet 暴露、封裝 Raw SQL；最佳實踐：單元測試覆蓋查詢是否帶租戶條件，避免繞過護欄。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q12, A-Q21

C-Q3: 如何為每租戶配置不同的資料庫連線？

• A簡: 以租戶表存連線字串，TenantResolver 取得後由 DbContextFactory 建立連線。
• A詳: 步驟：1) 租戶註冊時保存 ConnectionString；2) 解析請求取 TenantId；3) DbContextFactory 接 TenantContext 選連線；4) 連線快取與健康檢查。程式碼：new DbContext(connStrFromStore); 注意：保護機敏連線（KeyVault）、連線池上限、避免熱切換。最佳實踐：對熱門租戶預熱連線。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q10

C-Q4: 如何在 EF Code First 映射至指定 Schema？

• A簡: 於 OnModelCreating 使用 ToTable(“Table”,”SchemaName”) 動態指定 Schema。
• A詳: 步驟：1) 於 DbContext 注入 ISchemaNameProvider；2) OnModelCreating：modelBuilder.Entity().ToTable("Orders", schemaProvider.Name); 3) 針對每租戶執行遷移以建立表。注意：避免硬編碼 Schema；遷移需支援多 Schema 目標。最佳實踐：統一命名規範與 Migration Orchestrator。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q14

C-Q5: 如何設計 Separate Schemas 的命名規範？

• A簡: 以可讀且唯一的 Schema 前綴，如 t_{shortId}，避免衝突並利於運維。
• A詳: 步驟：1) 決定 Schema 命名 t_{base36Id}；2) 為每表建立相同結構；3) 權限僅允許該 Schema；4) 監控依 Schema 維度。設定：CREATE SCHEMA t_ab12; GRANT SELECT ON SCHEMA::t_ab12 … 注意：避免使用易變更名稱；最佳實踐：以內部不可變 TenantKey 生成。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q6

C-Q6: 如何撰寫安全的 Shared Schema SQL 查詢？

• A簡: 使用參數化並固定加入 WHERE TenantID=@tid，避免跨租戶資料外洩。
• A詳: 步驟：1) 封裝查詢模板；2) 所有查詢強制帶 TenantID；3) 像：SELECT … FROM Orders WHERE TenantID=@tid AND Id=@id; 注意：禁止字串拼接、設定最小權限、建立檢查清單。最佳實踐：改以視圖：CREATE VIEW v_Orders AS SELECT * FROM Orders WHERE TenantID=SESSION_CONTEXT(‘tid’);
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q12, D-Q1

C-Q7: 如何為 Shared Schema 建立複合索引？

• A簡: 將 TenantID 作為索引前綴，依查詢再加主鍵或時間欄位形成覆蓋索引。
• A詳: 步驟：1) 盤點熱查詢；2) 建立索引：CREATE INDEX IX_Orders_Tenant_Date ON Orders(TenantID, OrderDate DESC) INCLUDE (Status,Amount); 3) 檢查計畫並調整；注意：避免過多索引造成寫入負擔、維護統計資訊。最佳實踐：定期審視索引使用率與重建策略。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q11, D-Q2

C-Q8: 如何實作簡單的 EAV 擴充欄位？

• A簡: 建立 Attributes、AttributeValues 兩表，依 TenantID 與 EntityId 關聯。
• A詳: 步驟：1) 建表：Attributes(Id, TenantID, Name, Type)、AttributeValues(Id, TenantID, EntityId, AttributeId, Value)；2) 索引：(TenantID, AttributeId, EntityId)；3) 查詢以 Pivot 或聚合；注意：控制屬性數量、避免熱查詢過度拼接。最佳實踐：對常用屬性落地實體欄位或物化檢視。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, A-Q14

C-Q9: 如何為 Shared Schema 做單一租戶備份？

• A簡: 以租戶範圍匯出（BCP/ETL）或快照後過濾資料，實作邏輯備份。
• A詳: 步驟：1) 標準化租戶匯出管線（含關聯表過濾 TenantID）；2) 使用 BCP/SSIS/Azure Data Factory 匯出；3) 保存結構版本；4) 還原時先清空目標租戶資料再匯入。注意：一致性（交易/快照）、稽核與校驗。最佳實踐：定期演練與檔案簽章。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q9, D-Q6

C-Q10: 如何在 Azure 上估算三種架構的成本？

• A簡: 估算 DB 實例/DTU、儲存、備份與維運人力；Shared 最省，Separated 最高。
• A詳: 步驟：1) 預估租戶數與使用曲線；2) Separated DB：每租戶一庫成本加總；3) Schema/Shared：以共享實例容量規劃；4) 計入備援、備份、監控與自動化成本；5) 做壓測校正。注意：尖峰與長尾、合規需求可能改變選型。最佳實踐：分層方案與動態升級路徑。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q15

Q&A 類別 D: 問題解決類（10題）

D-Q1: 報表出現其他客戶資料怎麼辦？

• A簡: 典型為漏加 TenantID 過濾；立即下線影響功能、修正查詢並加護欄。
• A詳: 症狀：報表或清單出現他租戶資料。原因：Shared Schema 查詢未帶 TenantID、視圖/SP 缺少過濾或權限過寬。解決：1) 立即停用受影響功能；2) 審查並補上租戶條件；3) 新增 ORM 全域過濾與視圖固定過濾；4) 補測試。預防：靜態分析、最小權限、查詢模板與審計告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, B-Q12, C-Q6

D-Q2: Shared Schema 查詢變慢怎麼優化？

• A簡: 建立 TenantID 前綴複合索引、避免跨租戶掃描、審視計畫與統計。
• A詳: 症狀：查詢延遲高、CPU 飆升。原因：缺少（TenantID, …）索引、統計過期、EAV 過度 Join。解決：1) 加複合索引；2) 更新統計、重建索引；3) 以物化檢視或快取加速；4) 調整查詢以 TenantID 起手。預防：索引治理、慢查詢告警、容量規劃與定期壓測。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q11, C-Q7

D-Q3: 每租戶獨立 DB 導致連線耗盡怎麼處置？

• A簡: 啟用連線池、限制並發、使用 DbContextFactory 與連線快取預熱。
• A詳: 症狀：高併發下連線用罄。原因：每請求新連線、缺少池化或過多冷啟。解決：1) 使用連線池與適當池大小；2) DbContext 範圍化重用；3) 熱門租戶預熱連線；4) 監控連線指標。預防：限制並發、連線重試策略、租戶流量整形與容量規劃。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, B-Q1

D-Q4: Separate Schemas 遷移腳本不同步怎麼解？

• A簡: 建立 Orchestrator 逐 Schema 執行與校驗版本，支援重試與回滾。
• A詳: 症狀：部分租戶表結構不一致。原因：手動執行、缺乏版本控制。解決：1) 引入集中式 Migration Orchestrator；2) 為每 Schema 記錄版本；3) 逐 Schema 執行與驗證；4) 發現失敗即回滾或重試。預防：CI/CD 自動遷移、變更審批與演練。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q14, C-Q4

D-Q5: EAV 導致查詢錯誤或結果不準怎麼辦？

• A簡: 檢查屬性定義一致性、加入唯一約束與索引，必要時落地實體欄位。
• A詳: 症狀：查詢結果缺漏或錯誤。原因：屬性定義重複、型別不一致、Join 邏輯錯。解決：1) 加唯一鍵（TenantID, Name）；2) 統一型別與轉換；3) 新增複合索引；4) 為熱屬性建立實體欄或物化檢視。預防：EAV 治理流程、Schema 驗證與查詢封裝。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, C-Q8

D-Q6: 多租戶備份成本過高如何降低？

• A簡: 分層備份策略：關鍵租戶高頻，其餘共享備份，搭配壓縮與增量。
• A詳: 症狀：存儲與頻寬費用攀升。原因：每租戶全量備份過頻。解決：1) 鑑別關鍵租戶；2) DB 模式用差異/交易備份；3) Shared 用租戶範圍匯出僅關鍵租戶；4) 啟用壓縮與保留策略。預防：週期性成本審視、備份演練與 SLA 對齊。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q9

D-Q7: 管理員無法跨租戶查詢如何設計？

• A簡: 提供受控的跨租戶視圖或資料倉儲，避免直接繞過隔離。
• A詳: 症狀：需要全域報表但被隔離限制。原因：權限與護欄阻止直查。解決：1) 建立管理員專用視圖/報表服務，透過受控管道匯總；2) 或抽取至資料倉儲彙整。預防：明確職責分離、審計與存取告警，避免生產庫直接跨租戶查詢。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: D-Q10, B-Q13

D-Q8: 新租戶開通失敗如何診斷？

• A簡: 查看 Provisioning 日誌、資源建立狀態與遷移版本，支援重試與回滾。
• A詳: 症狀：註冊完成但無法登入或資料表缺失。原因：連線無效、遷移失敗、權限不足。解決：1) 檢查流程日誌與告警；2) 驗證 DB/Schema 是否建立；3) 補執行遷移與種子；4) 權限修正後重試。預防：冪等腳本、健康檢查、超時與重試策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q13

D-Q9: 動態 SQL 注入導致資料外洩如何防範？

• A簡: 全面參數化、最小權限、禁用直接動態拼接與加強輸入驗證。
• A詳: 症狀：異常資料外洩或刪改。原因：字串拼接查詢被注入、缺少權限隔離。解決：1) 改用參數化或 ORM；2) 視圖/SP 封裝；3) 限制權限與審計；4) 安全測試。預防：安全代碼規範、靜態/動態掃描、WAF 與最小權限。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q6, B-Q6, B-Q12

D-Q10: 需要跨租戶彙總報表該怎麼做？

• A簡: 建立資料倉儲/湖或彙總表，由 ETL 週期抽取，避免直連生產。
• A詳: 症狀：產品需全域指標。原因：生產庫隔離限制跨租戶。解決：1) 定義跨租戶度量；2) 建立 ETL 從各租戶（DB/Schema/Shared 過濾）抽取；3) 在倉儲建彙總表；4) 供 BI/報表使用。預防：資料脫敏、存取審批與延遲一致性聲明。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q9, D-Q7

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是多租戶（Multi-Tenancy）？
  • A-Q2: 什麼是 SaaS（Software as a Service）？
  • A-Q3: 什麼是 PaaS（Platform as a Service）？
  • A-Q4: 什麼是「租戶」（Tenant）？
  • A-Q5: 為什麼雲端 SaaS 常採多租戶架構？
  • A-Q6: 資料隔離在多租戶中的意義是什麼？
  • A-Q7: 三種模式差異？
  • A-Q8: 什麼是 Separated DB 模式？
  • A-Q9: 什麼是 Separate Schemas 模式？
  • A-Q10: 什麼是 Shared Schema 模式？
  • A-Q11: 三種模式的成本差異是什麼？
  • A-Q12: 三種模式的安全隔離差異？
  • A-Q16: 多租戶應用的核心價值是什麼？
  • A-Q20: Azure 與 ASP.NET MVC 在多租戶中的角色？
  • A-Q21: 什麼是租戶感知（Tenant-aware）查詢？
• 中級者：建議學習哪 20 題
  • B-Q1: Separated DB 的運作流程是什麼？
  • B-Q2: Separate Schemas 的運作流程與組件？
  • B-Q3: Shared Schema 的運作流程與風險控制？
  • B-Q4: 租戶解析（Tenant Resolution）如何運作？
  • B-Q5: 租戶識別（TenantID）設計原則？
  • B-Q6: 在資料庫層進行隔離的機制有哪些？
  • B-Q7: 多租戶資料擴充機制與取捨？
  • B-Q9: 備份與還原的差異與流程？
  • B-Q10: 新租戶上線（Provisioning）的技術流程？
  • C-Q1: ASP.NET MVC 以子網域解析租戶
  • C-Q2: EF6 實作租戶過濾
  • C-Q3: 每租戶配置不同的資料庫連線
  • C-Q4: EF Code First 映射至指定 Schema
  • C-Q6: 撰寫安全的 Shared Schema SQL 查詢
  • C-Q7: Shared Schema 建立複合索引
  • C-Q8: 實作簡單的 EAV 擴充欄位
  • D-Q1: 報表出現其他客戶資料怎麼辦？
  • D-Q2: Shared Schema 查詢變慢怎麼優化？
  • D-Q3: 每租戶獨立 DB 連線耗盡怎麼處置？
  • D-Q4: Separate Schemas 遷移不同步怎麼解？
• 高級者：建議關注哪 15 題
  • B-Q8: 名值（EAV）模型的技術原理與索引
  • B-Q11: Shared Schema 的索引與分割
  • B-Q12: 設計安全護欄避免漏加 TenantID 的機制
  • B-Q13: 記錄與稽核：如何標註租戶脈絡
  • B-Q14: 版本升級與資料庫遷移策略
  • B-Q15: 成本模型：Shared Schema 成本最低
  • C-Q9: Shared Schema 的單一租戶備份
  • C-Q10: Azure 成本估算
  • D-Q5: EAV 導致查詢錯誤或結果不準怎麼辦？
  • D-Q6: 多租戶備份成本過高如何降低？
  • D-Q7: 管理員無法跨租戶查詢如何設計？
  • D-Q8: 新租戶開通失敗如何診斷？
  • D-Q9: 動態 SQL 注入導致資料外洩如何防範？
  • D-Q10: 需要跨租戶彙總報表該怎麼做？
  • A-Q24: 為何設計多租戶是挑戰？