SaaS模式實現架構
https://blog.csdn.net/xwq911/article/details/50630266
1、 數據庫層：
數據庫這一層的設計模式是很清晰的，無外乎只有3種方案：
（1） 所有客戶的數據都存放在一個數據庫的同一套表中， 在表中增加Company_id等標志字段，表明該記錄是屬於哪個客戶的。
優點：數據源和數據庫的管理都比較簡單。和原來的應用沒有差別。
缺點：數據權限比較復雜，增加程序的復雜性。如果應用比較復雜，很多數據表都需
要加入客戶標志字段，很多查詢都需要包括該字段，會比較麻煩。如果有遺漏，、特別是查詢條件中遺漏該字段，就會造成一個客戶看到另一個客戶的數據。
（2） 每個客戶獨立一個數據庫：
在應用服務器中配制不同的數據源，或者使用不同的連接池。
優點：不同客戶的數據物理分離，安全性比較好。
缺點：數據庫連接的利用效率不高。Performance 問題會很大
(3) 多Schema，單數據源
這個方案基本是方案2的變種。同一個數據庫下可以有多個Schema
優點：除了方案2的優點以外，共享數據源或連接池，效率更高。
缺點：和方案一比較起來，數據庫連接池開銷會比較大
所有以上方案都是所有客戶共享同一個應用（WAR或EAR）。
這里我選擇方案三,並結合了方案一，對於登陸/驗證/權限，所有的客戶共享一個Schema,而對於業務數據，則每個客戶一個Schema.
我做了200個不同的Schema，用戶名和密碼分別是demo1/demo1 到demo200/demo200,大家可以按照不同的用戶名和密碼登陸。
這台機器就是一台式機，不是專用服務器，網絡也是放在我家里的小區寬帶上，是通過無線路由器上的網，所以網速可能不太穩定。
原文地址
https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns
前言
在設計多租戶SaaS應用程序時，您必須仔細選擇最適合您應用程序需求的租戶模型。租戶模型確定每個租戶的數據如何映射到存儲。您選擇的租戶模式會影響應用程序設計和管理。以后切換到另一個模型有時代價昂貴。
關於可選擇的租戶模型的討論如下。
A，怎么選擇一個合適的租戶模型
一般來說，租賃模式不會影響應用程序的功能，但它可能會影響整體解決方案的其他方面。以下標准用於評估每個模型：
可擴展性（Scalability）
租戶的數量級
每個租戶的存儲級別
整體存儲
工作負載
租戶隔離性（Tenant isolation）
數據隔離和性能（是否一個租戶的負載會影響到其他租戶）
單租戶成本（Per-tenant cost）
數據庫成本
開發復雜度（Development complexity）
數據結構的變化
查詢語句的變化
運維復雜度（Operational complexity）
性能監控
數據結構schema管理
租戶數據恢復
災備
可定制化程度（Customizability）
根據租戶的需求自定義架構的容易程度
這個租戶的討論集中在數據層。但考慮一下應用層。應用程序層被視為一個整體實體。如果將應用程序划分為許多小型組件，您的租戶模型選擇可能會發生變化。對於租戶和存儲技術或使用的平台，您可以對其他組件進行不同的處理
B，獨立的單租戶應用+獨立的單租戶數據庫
應用層隔離
在這個模型中，對於每一個租戶，整個應用程序需要重復安裝一次。應用程序的每個實例都是獨立實例，因此它不會與任何其他獨立實例交互。每個應用程序實例只有一個租戶，因此只需要一個數據庫。租戶擁有自己的數據庫。
這里寫圖片描述
每個應用程序實例都安裝在獨立的Azure資源組中。資源組可以屬於軟件供應商或租戶擁有的訂閱。無論哪種情況，供應商都可以為租戶管理軟件。每個應用程序實例都配置為連接到其相應的數據庫。
每個租戶數據庫都作為獨立數據庫進行部署。該模型提供了最大的數據庫隔離。但隔離需要為每個數據庫分配足夠的資源來處理其高峰負載。這里重要的是，彈性池不能用於部署在不同資源組或不同訂閱中的數據庫。這種限制使得這種獨立的單租戶應用程序模型成為從整體數據庫成本角度來看最昂貴的解決方案。
供應商管理
即使應用程序實例安裝在不同的租戶訂閱中，供應商也可以訪問所有獨立應用程序實例中的所有數據庫。訪問是通過SQL連接實現的。這種跨實例訪問可以使供應商能夠集中化架構管理和跨數據庫查詢以用於報告或分析目的。如果需要這種集中式管理，則必須部署一個目錄，將租戶標識符映射到數據庫URI。 Azure SQL數據庫提供了與SQL數據庫一起使用以提供目錄的分片庫。分區庫被正式命名為彈性數據庫客戶端庫（ Elastic Database Client Library）。
C，支持多租戶的應用+每一個租戶獨立數據庫
這個模式使用具有多個數據庫的多租戶應用程序，均為一個租戶一個數據庫。為每個新租戶提供一個新的數據庫。通過為每個節點添加更多資源來垂直擴展應用程序層。或者通過添加更多節點來橫向擴展應用程序層。縮放基於應用程序的工作負載，並且與個體數據庫的數量或規模無關。
這里寫圖片描述
租戶的可定制化
與獨立的應用程序模式一樣，使用單租戶數據庫可以提供強大的租戶隔離。可以為租戶定制和優化任何給定數據庫的模式。此自定義不會影響應用中的其他租戶。也許租戶可能需要超出所有租戶所需的基本數據字段的數據。此外，額外的數據字段可能需要一個索引。
使用每個租戶一個數據庫，為一個或多個獨立租戶定制架構很容易實現。應用程序供應商必須設計程序來小心管理架構自定義。
彈性池
當數據庫部署在同一資源組中時，可以將它們分組為彈性數據庫池。這些池提供了跨多個數據庫共享資源的具有成本效益的方式。該池選項比要求每個數據庫足夠大以容納它所經歷的使用高峰要便宜。即使匯集的數據庫共享資源訪問權限，他們仍然可以實現高度的性能隔離。
這里寫圖片描述
Azure SQL數據庫提供了配置，監視和管理共享所需的工具。池級別和數據庫級別的性能指標均可在Azure門戶中以及通過Log Analytics獲得。這些指標可以深入了解總體和租戶特定的性能。各個數據庫可以在池之間移動，為特定租戶提供預留資源。這些工具使您能夠以經濟高效的方式確保良好的性能。
運維的可伸縮性
Azure SQL Database平台具有許多旨在管理大量數據庫的管理功能，例如超過100,000個數據庫。這些功能使每租戶數據庫模式合理。
例如，假設系統只有一個1000租戶數據庫作為其唯一的一個數據庫。數據庫可能有20個索引。如果系統轉換為擁有1000個單租戶數據庫，則索引數量將增至20,000。在SQL Database中，作為自動調整（Automatic tuning）的一部分，默認情況下啟用自動索引功能。自動索引為您管理所有20,000個索引及其正在進行的創建和刪除優化。這些自動化操作發生在單個數據庫中，並且不會被其他數據庫中的類似操作所協調或限制。自動索引處理繁忙數據庫中的索引與繁忙數據庫中的索引不同。如果這種巨大的管理任務必須手動完成，那么這種類型的索引管理定制對於每租戶數據庫規模而言將是不切實際的。
另外在可伸縮性管理上，還擁有以下特色：
- 內置備份
- 高可用
- 磁盤加密
- 性能遙測
自動化
管理操作可以通過devops模型編寫和提供。這些操作甚至可以自動化並在應用程序中公開。
例如，您可以自動將單個租戶恢復到較早的時間點。恢復只需要恢復存儲租戶的一個單租戶數據庫。這種恢復對其他租戶沒有影響，這證實了管理運營處於每個租戶的細粒度級別。
D，支持多租戶的單應用+支持多租戶的單數據庫
另一種可用模式是將多租戶存儲在多租戶數據庫中。應用程序實例可以具有任意數量的多租戶數據庫。多租戶數據庫的模式必須具有一個或多個租戶標識符列，以便可以選擇性地檢索來自任何給定租戶的數據。此外，該模式可能需要一些僅由租戶子集使用的表或列。但是，靜態代碼和參考數據僅存儲一次，並由所有租戶共享。
犧牲了租戶的隔離
數據：多租戶數據庫必然會犧牲租戶隔離。多個租戶的數據一起存儲在一個數據庫中。在開發過程中，確保查詢不會暴露來自多個租戶的數據。 SQL數據庫支持行級安全性，它可以強制將查詢返回的數據限定為單個租戶。
處理：多租戶數據庫跨所有租戶共享計算和存儲資源。數據庫作為一個整體可以被監控，以確保它的性能可以接受。但是，Azure系統沒有內置的方法來監視或管理單個租戶使用這些資源。因此，多租戶數據庫會增加遭遇嘈雜鄰居的風險，其中一個過於活躍的租戶的工作負載會影響同一數據庫中其他租戶的性能體驗。附加的應用程序層的監視可以監視租戶層的性能。
更低的成本
一般來說，多租戶數據庫的租戶成本最低。獨立數據庫的資源成本低於同等規模的彈性池。此外，對於租戶只需要有限存儲的情況，潛在的數百萬租戶可能存儲在單個數據庫中。沒有彈性池可以包含數百萬個數據庫。但是，每個池中包含1000個數據庫的解決方案（包含1000個池）可能會達到數百萬的規模，有可能變得難以管理。
以下將討論多租戶數據庫模型的兩種變體，分片多租戶模型是最靈活和可擴展的。
E，支持多租戶的單應用+支持多租戶的單數據庫（不分片）
最簡單的多租戶數據庫模式使用單獨的獨立數據庫來為所有租戶托管數據。隨着越來越多的租戶被添加，數據庫被擴大了更多的存儲和計算資源。這種放大可能是所需要的，盡管總是有一個最終的限制。但是，在達到這個限制之前，數據庫變得難以管理。
針對單個租戶的管理操作在多租戶數據庫中實施起來要復雜得多。大規模的這些行動可能會變得無法接受地緩慢。一個很壞的例子就是嘗試只恢復某一個租戶的某一時間點的數據。
F，支持多租戶的單應用+支持多租戶的單數據庫（分片）
大多數SaaS應用程序一次只能訪問一個租戶的數據。此訪問模式允許租戶數據分布在多個數據庫或分片中，其中任何一個租戶的所有數據都包含在一個分片中。結合多租戶數據庫模式，分片模型允許幾乎無限的規模。
這里寫圖片描述
管理分片
分片增加了設計和運營管理的復雜性。需要在其中維護租戶和數據庫之間的映射的目錄。此外，還需要管理程序來管理碎片和租戶人口。例如，必須設計程序以添加和刪除分片，並在分片之間移動租戶數據。一種擴大規模的方法是添加一個新的分片並將其填入新租戶。在其他時候，您可能會將人口稠密的分片分成兩個密度較小的分片。幾個租戶搬遷或停產后，可能會將人口稀少的分片合並在一起。合並將導致更具成本效益的資源利用率。租戶也可能在分片之間移動以平衡工作量。
SQL數據庫提供了一個拆分/合並工具，與分片庫和目錄數據庫一起使用。提供的應用程序可以拆分和合並分片，並可以在分片之間移動租戶數據。該應用程序還在這些操作過程中維護目錄，在移動它們之前將受影響的分片租戶標記為離線。移動后，應用程序再次使用新映射更新目錄，並將租戶標記為重新聯機。
更小的數據庫更容易管理
通過將租戶分布在多個數據庫中，分片多租戶解決方案可生成更輕松管理的小型數據庫。例如，將特定租戶恢復到以前的時間點現在涉及從備份恢復單個較小的數據庫，而不是包含所有租戶的較大數據庫。可以選擇數據庫大小和每個數據庫的租戶數量來平衡工作負載和管理工作。
shema中的租戶標識符ID
根據所使用的分片方法，可能會對數據庫模式施加額外的約束。 SQL Database拆分/合並應用程序要求Schema包含分片KEY，通常是租戶標識符ID。租戶標識符ID是所有分片表主鍵中的主要元素。租戶標識符使分離/合並應用程序能夠快速定位和移動與特定租戶相關聯的數據。
分片的彈性池
分片多租戶數據庫可以放置在彈性池中。一般來說，在一個池中擁有許多單租戶數據庫的成本效率與在少數多租戶數據庫中擁有許多租戶相當。當有大量相對不活躍的租戶時，多租戶數據庫是有利的。
G，混合分片多租戶數據庫
在混合模型中，所有數據庫在其Schema中都有租戶標識符。這些數據庫都能夠存儲多個租戶，並且數據庫可以被分割。所以在架構意義上說，它們都是多租戶數據庫。然而在實踐中，其中一些數據庫只包含一個租戶。無論如何，存儲在給定數據庫中的租戶數量對數據庫架構沒有影響。
移動租戶
在任何時候，您都可以將特定租戶遷移到自己的多租戶數據庫。在任何時候，您都可以改變主意並將租戶移回包含多個租戶的數據庫。在供應新數據庫時，您還可以將租戶分配給新的單租戶數據庫。
當可識別的租戶群體的資源需求存在較大差異時，混合模式就會發光。例如，假設參與免費試用的租戶無法保證與訂購租戶相同的高性能水平。該政策可能適用於免費試用階段的租戶存儲在所有免費試用租戶共享的多租戶數據庫中。當免費試用租戶訂閱基本服務級別時，租戶可以轉移到另一個租戶較少的多租戶數據庫。支付高級服務級別的用戶可以轉移到其新的單租戶數據庫。
池
在這種混合模式中，用戶租戶的單租戶數據庫可以放置在資源池中，以降低每個租戶的數據庫成本。這也是在數據庫每租戶模型中完成的。
H，租戶模型的比較
指標 獨立應用 單租戶單數據庫 分片多租戶
可擴展性 中等1-100s 非常高1-100000s 無限1-1000000s
租戶隔離性 非常高 高 低
每一個租戶的數據庫成本 高 低，使用池 最低
性能監控和管理 只能一個一個租戶進行 綜合和單個 綜合和單個（偏綜合）
開發復雜度 低 低 中等
運維復雜度 從低到高，取決於租戶規模 從低到中等 從低到高，單租戶的管理比較復雜