基於AWS雲SaaS多租戶架構設計

基於AWS雲SaaS多租戶架構設計

租戶與用戶概念

單租戶與多租戶

多租戶的好處
採用多租戶架構方法將為你的SaaS應用程式帶來廣泛的有價值的好處。

讓我們來看看下麵的貢獻。

a) 利用多租戶架構策略，減少伺服器基礎設施成本。

與其為每個客戶創建一個SaaS環境，不如為所有客戶提供一個應用環境。這使你的AWS托管成本從數百台伺服器大幅減少到一個。

b) 一個單一的信任來源。

讓我們再次假設你有一個使用你的SaaS的客戶，想象一下，你會為每個客戶擁有多少個代碼庫？每個客戶至少有3-4個分支，這將是大量的開銷和錯位的代碼發佈。更糟糕的是，想象一下將你的代碼部署到整個租戶農場的過程；這是很複雜的。這是不可行的，而且很費時間。有了多租戶SaaS架構，你就可以避免這種類型的衝突，你會有一個代碼庫（信任源），和一個有幾個分支的代碼庫（dev/test/prod）。通過下麵的實踐，--用一個命令（一鍵部署）--你將在幾秒鐘內迅速完成部署過程。

c) 降低開發成本，縮短上市時間。
降低成本需要考慮一連串的決定，例如擁有一個單一的代碼庫、SaaS平臺環境、多租戶資料庫架構、集中存儲、API，以及遵循 "十二要素法"；所有這些都將使你減少開發人力成本，縮短上市時間，並提高運營效率。

SaaS web stack:基於AWS雲SaaS 多租戶架構

       亞馬遜S3和亞馬遜CloudFront CDN為您提供靜態內容。所有的靜態內容，包括圖片、媒體和HTML，將被托管在Amazon S3上，這是一個具有無限存儲和彈性的雲系統。在Amazon S3的前面，我們將包括AWS CloudFront，整合這一對元素是至關重要的，以便緩存整個靜態內容並減少帶寬成本。

消息隊列系統（MQS）
常見的MQS是Amazon SQS、RabbitMQ或Celery。我在這裡的建議是，利用需要你較少操作的服務，在這種情況下，就是Amazon SQS。有多種情況下，你需要非同步通信。從延遲或調度任務，到提高關鍵網路事務的可靠性和持久性，解耦你的單體或微服務應用程式，以及最重要的是：使用隊列系統來通信事件驅動的無伺服器應用程式（Amazon Lambda函數）。

緩存系統
AWS ElastiCache是一個完全可擴展、可用和可管理的緩存和數據存儲系統。它的目的是提高分散式緩存數據和記憶體數據結構存儲的應用性能。它是一個用於Memcached和Redis引擎的記憶體鍵值存儲。只需點擊幾下，你就可以完全自我管理地運行這個AWS組件。為你的SaaS應用程式包含一個緩存系統是非常必要的。

雲存儲系統
亞馬遜S3和亞馬遜CloudFront CDN為您提供靜態內容。所有的靜態內容，包括圖片、媒體和HTML，將被托管在Amazon S3上，這是一個具有無限存儲和彈性的雲系統。在Amazon S3的前面，我們將包括AWS CloudFront，整合這一對元素是至關重要的，以便緩存整個靜態內容並減少帶寬成本。

微服務-多租戶架構

多租戶架構+AWS服務+微服務+Amazon ECS（作為容器協調器）

在K8S上

無伺服器架構

基礎設施即代碼和自動化工具
使用哪種基礎設施即代碼工具並不重要，它們都很有用（Terraform和CloudFormation）；它們做同樣的工作，並被DevOps社區高度認可。我沒有一個贏家，它們都很好。然而，如果你想知道更多關於它們各自的優缺點，我推薦這篇關於Terraform vs Amazon CloudFormation的博客。

數據架構

資料庫
       固有的資料庫將是PostgreSQL和Amazon RDS。然而，我強烈建議，如果你有一個資深的開發團隊，並且預測你的SaaS應用程式的高流量，甚至數百個租戶，你最好用MongoDB構建你的資料庫。除此之外，利用下麵提到的關於多租戶資料庫的最佳實踐。在這種情況下，我會選擇亞馬遜RDS與PostgreSQL或DynamoDB（Mongodb）。

"如果你的SaaS應用程式預計會有很高的流量，你最好用MongoDB來構建你的資料庫"

GraphQL或Amazon AppSync
GraphQL是一種查詢語言，也是你的資料庫服務的RESTful API的替代品。這個新的和現代的生態系統被採納為客戶和資料庫伺服器之間的中間人。它允許你更快地檢索資料庫數據，減輕資料庫中的過度檢索，從GraphQL模式中檢索所需的準確數據，主要是通過比RESTful服務更快的迭代來提高開發速度。在多租戶微服務架構中採用單體後端應用是利用GraphQL或AppSync的最佳時機。因此，在改造你的SaaS應用程式時，不要忘記包括GraphQL!

單一資料庫---每個租戶一張表
      每租戶一個表的單一資料庫指的是純資料庫的多租戶和池化模型。這種資料庫架構是DevOps或軟體架構師的常見和預設的解決方案。當有一個小的初創公司或幾十個組織時，它是非常經濟的。它包括利用資料庫模式中每個組織的一個表。這種架構有特定的權衡，包括犧牲數據隔離、租戶之間的噪音和性能下降--這意味著一個租戶可以過度使用另一個租戶的計算和記憶體資源。最後，每個表名都有自己的租戶ID，這對於設計和架構來說是非常直接的。

關於數據隔離和合規性，假設你的一個開發人員犯了一個錯誤，把錯誤的租戶信息帶給了你的客戶。想象一下數據泄露的情況吧! - 請確保永遠不要暴露超過一個租戶的信息。這就是為什麼合規的SaaS應用程式，這種架構模型不被推薦，然而，因為其成本效益而被廣泛使用。

另一種單租戶資料庫架構：在單一資料庫的單一模式中的共用表。非常適合DynamoDB。(我們沒有涉及這種方法--僅供參考)

單一資料庫---每個租戶的模式
        每租戶一個模式的單一資料庫，也被稱為橋梁模型，是一種多租戶的資料庫方法，它仍然非常具有成本效益，比純租戶（DB池模型）更安全，因為你是用一個單一的資料庫，除了每租戶的資料庫模式隔離。如果你擔心數據分區，這個方案比之前的方案（每個租戶一張表）略好。同樣，在你的應用程式代碼配置中跨多個模式的管理也很簡單。

需要註意的一個重要區別是，在一個資料庫內有超過100個模式或租戶，會引起你的資料庫性能的滯後。因此，建議將資料庫一分為二（將第二個資料庫作為一個副本添加）。然而，這種方法最好的資料庫工具是PostgreSQL，它支持多個模式，沒有太多的複雜性。最後，這種 "每個租戶一個模式 "的策略在其所有租戶之間共用資源、計算和存儲。因此，它引起了嘈雜的租戶，利用了比預期更多的資源。

每個租戶的資料庫伺服器
       也叫孤島模式，即每個客戶需要一個資料庫實例。昂貴，但對隔離和安全法規來說是最好的。這種技術比其他多租戶資料庫架構的成本要高得多，但它符合安全法規；在性能、可擴展性和數據隔離方面是最好的。這種模式為每個租戶使用一個資料庫伺服器，這意味著如果SaaS應用程式有100個租戶，因此將有100個資料庫伺服器，成本極其高昂。

當需要PCI、HIPAA或SOC2時，利用資料庫孤島模式是至關重要的，或者至少找到一種變通方法，使用正確的IAM角色和最好的容器編排--無論是Kubernetes還是Amazon ECS命名空間--每個租戶一個VPC和到處加密。

AWS多租戶資料庫

亞馬遜RDS與PostgreSQL（最佳選擇）。
DynamoDB（對於具有單一共用表的單租戶資料庫來說是個不錯的選擇）
帶有Mysql的亞馬遜RDS
GraphQL如前所述，在這些資料庫前面使用它，可以提高數據檢索的速度、開發的速度和RESTful API的替代方案，這有助於減輕從被支持的伺服器到客戶端的請求。

應用程式代碼的改變
      一旦你在每一層都選擇了你的多租戶策略，讓我們開始考慮在代碼層面需要改變什麼，就代碼變化而言。如果你已經決定採用Django（來自Python）作為你的SaaS應用程式。那麼你需要做一些調整變化，以便從資料庫和應用層使你目前的應用與你的多租戶架構保持一致。幸運的是，網路應用語言和框架能夠捕獲來自請求的URL或子域。在運行時獲取這些信息（子域）的能力對於處理多租戶架構的動態子域至關重要。

通配符DNS子域。基於URL的SaaS平臺
      基本上，每個組織都必須有自己的子域，它們對識別組織相當有用。每個租戶，它是一個獨特的專用空間、環境和自定義應用程式（至少在邏輯上）；例如，"org1.saas.com"，"org2.saas.com"，等等。這種URL結構將動態地配置你的SaaS多租戶應用程式，這種DNS的變化將促進每個租戶的識別、認證和授權。然而，另一種解決方法被稱為基於路徑的每一個租戶，這並不推薦，例如，'app.saas.com/org1/...'，'app.saas.com/org2/...'，等等。

所以，在這個特殊的部分需要有以下內容。

在你的DNS管理記錄中應該有一個通配符記錄。
這個通配符子域將所有路由重定向到你的多租戶架構（無論是到負載均衡器、應用伺服器還是集群終端）。
同樣，一個標有（*）的CNAME記錄，指向你的'app.saas.com'或'saas.com/login'。星號（*）意味著通配符，指向你的應用域。
作為最後一步，另一個(A)記錄將你的'app.saas.com'功能變數名稱指向你的Amazon ECS集群、ALB或IP。

DNS記錄條目
*.saas.com CNAME 'app.saas.com
app.saas.com A 1.2.3.4 OR app.saas.com A（別名）balancer.us-east-1.elb.amazonaws.co

註意：（A）別名記錄是當你利用AWS的ALB/ELB（負載平衡器）。

網路伺服器設置與NGINX配置
       讓我們轉到網路伺服器，特別是Nginx。在這個階段，你將需要配置Nginx.conf和伺服器塊（虛擬主機）。為你的Nginx網站伺服器設置一個通配符vhost。確保它是一個別名（ServerAlias）和一個全能的通配符網站。你不必在Nginx中為每個租戶創建一個子域VirtualHost；相反，你需要為所有租戶設置一個通配符VirtualHost。當然，通配符模式將匹配你的子域，並相應地路由到你的SaaS應用文檔根的正確和獨特的補丁。

關於進一步的信息，我強烈推薦這篇博客，它講述了企業如何使用Apache多租戶和Nginx多租戶來支持SaaS應用。你會發現關於Nginx多租戶和Apache多租戶如何實現的寶貴信息，以及它們各自的DNS通配符記錄。

遵循12要素方法論框架，否則就死路一條!
     遵循12要素方法論代表了純粹的DevOps和雲原生原則，包括不可變的基礎設施、與Docker相同的開發/測試和prod、CI/CD原則、無狀態SaaS應用等等。

多租戶SaaS架構最佳實踐
     SaaS平臺將如何擴展？考慮遵循一個關於如何擴展你的SaaS應用的策略，這裡有一個好的策略：

亞馬遜自動擴展，可以使用ec2實例或微服務。
用亞馬遜RDS、亞馬遜Aurora或DynamoDB進行資料庫複製。
應用負載平衡器。
包括一個CloudFront CDN用於你的靜態內容。
亞馬遜S3用於所有的靜態/媒體內容。
緩存系統，包括Redis/Memcached或其在AWS雲中的等同物 - Amazon ElastiCache。
為冗餘和可用性而設置的多可用性區域。

使用CI/CD的代碼部署
       另一個需要考慮的關鍵方面是如何在租戶和多個環境（開發、測試和prod）中部署你的代碼發佈。你將需要一個持續集成和持續交付（CI/CD）流程來簡化你在所有環境和租戶之間的代碼發佈。如果你跟進我之前的最佳實踐，這並不困難。CI/CD實踐是你的DevOps團隊需要熟悉的另一個世界，但與ClickIT這樣的團隊合作。CI/CD只是DevOps實踐的五個原則之一，對我們來說，將其採用到你的SaaS應用中是相當精簡的。

DevOps自動化--自動化你的新租戶創建過程
     如何在每個訂閱中創建新租戶的？確定在你的SaaS環境中啟動新租戶的過程。你需要觸發一個腳本來啟動或附加新的多租戶環境到你現有的多租戶架構上，也就是說，要自動設置新的租戶。考慮到這可能是在你的客戶在你的入職頁面上註冊之後，或者你需要手動觸發腳本。

自動化工具：
Terraform (推薦)
亞馬遜CloudFormation（相信AWS CloudFormation認證團隊） Ansible

註意：確保你在這方面利用基礎設施即代碼的原則。

租戶計算能力
        你是否考慮過每個環境可以支持多少個SaaS租戶？試想一下，你有99個租戶，計算/資料庫負載幾乎到了極限，你是否有一個準備好的環境來支持新的租戶？那資料庫呢？你有一個特殊的客戶，希望為其SaaS應用提供一個隔離的租戶環境。你將如何支持一個與多租戶架構的其他部分分離的額外租戶環境？你會這樣做嗎？會有什麼影響？只需考慮這方面的一個場景。

租戶清理
       你如何處理那些閑置的或不再使用的租戶？也許對任何長期不活動的租戶進行清理，或者手工刪除未使用的資源和租戶......但你需要一個流程或自動化腳本。

最後

       AWS下的多租戶架構和SaaS應用......現在可以瞭解到整個多租戶SaaS架構周期從頭到尾的情況，包括伺服器配置、代碼以及每個IT層所追求的架構。整個多租戶SaaS架構的周期，從頭到尾，包括伺服器配置，代碼，以及每一個IT層所追求的架構。正如你所註意到的，這個生態系統沒有全球性的解決方案。每一個IT層都有多種變體，要麼是完全多租戶，要麼是部分租戶，要麼只是筒倉租戶。這主要取決於你的需求、預算、複雜性和你的DevOps團隊的專業知識。強烈建議採用微服務（ECS/EKS），在應用和資料庫層部分採用多租戶SaaS。還有，包括雲原生原則，最後，採用本文所述的多租戶架構最佳實踐和考慮。也就是說，通過思考如何獲得敏捷性、成本效率、IT勞動力成本，首先對你的AWS SaaS架構進行頭腦風暴。

       在這方面，使用Terraform和CloudFormation的自動化是我們最好的選擇。更妙的是，我們大多數的AWS/DevOps項目都遵循PCI、HIPAA和SOC2法規。如果你是一家金融科技、醫療保健或SaaS公司，那麼，你知道這種類型的要求應該包括在你的流程中。

如有想瞭解更多軟體設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關註我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 該文章也同時發佈在我的獨立博客中-Petter Liu Blog。