DTSE Tech Talk丨第3期：解密資料隔離方案，讓SaaS應用開發更輕松-有解無憂

摘要：解讀云上前沿技術，暢聊開發應用實踐，專家團隊授課，答疑解惑，助力開發者使用華為云開放能力進行應用構建、技術創新，

圍繞當下許多企業青睞的SaaS應用開發，華為云DTSE技術布道師李良龍為大家帶來《SaaS應用開發》系列課程第3期《SaaS資料路由設計實作》的分享，

本期直播詳解

一個合格的SaaS應用開發必定伴隨著租戶資料的隔離，同時租戶的開銷及成本預算各不相同，隨著業務規模的變化，我們該如何選擇租戶資料隔離的方式，如何實作隔離？相信在這期直播里，你可以找到解答，

從7個租戶模式了解資料路由的使用

在第一期的《SaaS云原生應用典型架構》技術分享中，我們了解到SaaS多租戶模式，幫助企業選擇合適的SaaS系統匹配企業的客戶和業務特點，如：獨享資源模式、全共享模式、資料層共享模式等，此時，我們往往會遇到不同租戶間的資料隔離問題，如何正確的進行資料路由，才能保證租戶的資料隔離，

在SaaS應用開發時應用層和資料層的租戶路由設計以及實作方面，我們會遇到幾種情況：

當租戶獨享應用層和資料層時，這個時候租戶的資料是天然隔離的，不會被其他租戶影響，此時是不需要路由的；
當多個租戶涉及到應用層和資料層的資源共享的時候，就需要對租戶的資料進行隔離，不管是應用層共享或者資料層共享，還是資料層和應用層都存在共享，正確的資料路由才能保證租戶隔離，

并且，不同的資源共享模式、共享程度，在同樣資源的情況下所容納的租戶數量不一樣，所以每一個租戶平均成本不一樣，最終的總TCO成本也會不一樣，所以往往使用這種混合模式，需要根據租戶的需求和預算進行不同程度的資源共享，以達到在保證租戶業務正常穩定運行的前提下，成本最小化，收益最大化的目的，

上圖中租戶1使用獨立的應用層和資料層，不涉及資源共享，所以無需要考慮資料路由，圖中的租戶2-7，都涉及到了資源共享，其中租戶3和租戶4共享資料庫實體，但是占用不同schema；租戶5和租戶6共享資料庫實體，但不使用schema隔離，在業務表中使用租戶標識隔離，共享應用層和資料庫實體時，在處理業務邏輯程序中需要將租戶的資料庫相關操作指向正確的目標庫，避免資料污染等一系列問題，此時即需要進行路由，?

不是所有資料都需要路由

當租戶進行資料操作時，可能涉及到關系型資料庫的讀寫，nosql，快取，訊息佇列，服務之間的呼叫等等場景，在這一條完整的鏈路中，資料的操作需要識別租戶的身份，實際上是說租戶的業務資料以及個性化配置是需要先識別租戶身份的，否則會引起租戶之間的資料污染，越權等等問題，

我們需要通過一些方式來識別租戶，并且要在整個業務鏈路中傳遞，直到不需要區分租戶為止，比如請求結束，那么路由到底承擔了什么角色，實際上起了什么作用呢，租戶路由不僅僅是要實作對租戶的資料進行正確的路由，而且是建立在一個可信的規則上的，可維護的，可統一管理的，而且可追溯，可以由一個超級管理員的角色來對租戶的資源進行分配并持久化，并能夠按照這些持久化的配置來作為租戶資料路由的依據，

綜上所述，SaaS應用之所以需要租戶路由，是多個租戶在一定程度上資源共享所導致，按共享程度有一個簡單的模型，隨著共享程度的升高，同樣資源可以容納的租戶數量會越來越多，那么每一個租戶所需要的成本就越低，隨著共享程度越高，就會導致針對租戶的運維難度增大，比如某一共享環境下租戶的資料需要回滾，要在不影響其他租戶的前提下完成，相比于獨享環境的租戶會復雜很多，

隨著共享程度越高，租戶之間的隔離程度就會越低，比如租戶資料使用行隔離時，不同租戶的資料放在同一個表中，租戶之間的資料最容易相互影響，這種模式可容納的租戶數量也是最多的，第二個是總擁有成本會隨著租戶的共享程度升高而降低，租戶的平均成本也隨之降低，這也是多租環境下，使用資源共享的一個比較重要的原因，?

租戶路由插件設計分享

上面介紹了為什么使用租戶路由來隔離租戶的資料，接下來為大家介紹一下租戶路由插件的設計思路，租戶路由插件大體可以分為動態資料源和資料路由策略兩個部分，今天重點介紹動態資料源，

上圖為動態資料源業務流程圖，動態資料源在配置方面使用yml配置，一個資料源可以被稱為一個資料源組，一個組包含一主多從，資料源配置可以將租戶與資料源的系結關系分開配置，這樣可以靈活的系結實作租戶與資料源的關系，松散配置方面，多個租戶可以系結同一個資料源組，可細化系結關系到schema，而且系結關系與資料源組配置的修改不相互影響，同時一個資料源組實際上是一組實體的多個連接池組成的，而且資料源組在滿足配置的情況下可以通過配置中心動態配置，

比如可以在不停機的情況下新增租戶，并將新增租戶系結到已經存在的資料源中；也可以新增資料源配置，將租戶指定到新增的資料源，通過資料庫管理工具如flyway，為租戶初始化資料庫資源，預置一些管理賬號、基礎配置等等，同時這個功能可以在租戶系結的資源改變的時候使用，比如某個租戶隨著業務的增長，需要從共享庫遷移到獨享庫等等場景，在配置的基礎上構建了動態資料源之后，業務訪問的程序中通過系結關系以及自定義擴展策略來選擇資料源，選擇schema，最后獲取資料庫連接，操作資料，比如讀寫分離，比如負載均衡，租戶與資料源的系結策略的擴展實作等等，

在配置結構中，支持自定義擴展連接池，而且連接池的配置屬性可以支持粒度細化到單個實體的，相同屬性細粒度的配置會覆寫粗粒度的配置，

在租戶標識傳遞方面，目前默認的是將租戶標識放在header中，在接收到請求之后將header中的租戶標識放入快取中，這個可以看作是一個會話級別的快取，僅需要在父執行緒中初始化并設定值，子執行緒也可以獲取到，并且需要在請求結束時清理掉，防止執行緒池中執行緒復用導致資料污染，

租戶與資料源以及schema的系結關系除了使用組態檔配置之外，還可以使用開放的擴展介面自行擴展系結邏輯，看到這里，有小伙伴會問，設計的路由插件為什么沒有關于行隔離的內容，

行隔離，是指通過在業務表中添加可以標識租戶身份的欄位，用于資料隔離，但并不代表所有的業務表都需要添加這個欄位，每一條業務資料都可以理解為是在基礎資料之上創建的，不是憑空出現的，只需要做到在業務表中可以傳遞租戶身份標識即可，

比如一個專案管理系統，根組織可以是SaaS的擁有者，也可以沒有這個根組織，不同的團隊可以理解成不同的租戶，在團隊之下新建部門，部門之下新建專案，專案之下關聯專案組的成員，以及專案的一些詳細資訊，在部門這一層，租戶標識實際上是團隊，在專案這一層的租戶標識實際上是部門，成員這一級的標識實際上是專案組，成員詳細資訊的標識實際上的成員ID，這樣也可以理解為租戶標識的傳遞，但是不需要額外的在每個表中去維護這些標識資訊，這些標識可以本來就是業務中天然攜帶的，更是侵入性的，所以正常的業務不用也沒必要單獨去考慮行隔離的實作，不推薦在業務處理程序中進行切換資料源，

他表示：

以微服務的設計來講，排除需要分庫分表的業務，如果在一個服務里面需要通過連接不同的業務庫來實作訪問不同業務的資料，這種方式是不合適的，應當基于微服務的設計思想，不同的業務模塊需要有不同的服務來管理，跨業務模塊操作資料時，需要通過服務呼叫、訊息通知等方式操作，不應該越權去處理其他業務模塊的資料，雖然通過配置可以實作這個功能，但是正常的業務場景是不推薦這么使用的，

談及資料路由插件在未來的演進方向時，現在插件是以SDK的方式提供，有其局限性，如不能跨語言，正在規劃中的sidecar版本的路由插件將會解決跨語言的問題，能夠完整的把SaaS應用的租戶路由管理起來，同時sidecar版本還帶能來一些新的能力，例如資源分配策略、路由策略、可視化，統一的資源管理分配等等，?

本節課程總結

獲益點

插件具有侵入性小，改造代價小，配置簡單靈活的特點，租戶規模不是很大時可以考慮使用路由插件，當租戶上一定規模之后，需要有完整的管理體系來管理租戶與資料源的關系，

使用插件時，只需要引入插件，然后將配置維護到插件指定的路徑下面，然后開啟插件的開關即可，如果有更高多的要求，可以實作我們的一些配置策略，包括資料源的動態重建等等，另外一種是sidecar模式的路由解決方案，適用于租戶數量比較多時使用，sidecar版本可以跨語言，更便捷的解決租戶資料路由的問題，

下節課程預告

下節課，我們邀請到了派拉軟體研發總監、CZTP零信任專家茆正華和華為云DTSE技術布道師程澤，為大家帶來《SaaS應用開發》系列課程第4期《身份應用云上技術架構實踐》的分享，深入介紹云原生架構下的身份管理平臺，為企業、機構、開發者構建云安全數字身份入口，賦能用戶全場景下的數字身份治理與鏈接服務，8月25日，我們不見不散，

DTSE Tech Talk丨第3期：解密資料隔離方案，讓SaaS應用開發更輕松