?對于SaaS應用的可伸縮，最理想的情況：隨著用戶數的增大，系統架構不用做調整，而僅需要增加/增強相應的硬件設備（應用服務器、數據庫服務器）即可。而通常強調的應用架構具有 可伸縮性，一般指的是可以實現”Scale out”，即水平擴展或者向外擴展。而”Scale up”通常為垂直擴展或者向上擴展，也就是增強硬件設備，這種方式幾乎是任何應用架構普遍適用的，但是通常都會面臨高成本的問題。

??????1、應用服務器層的水平擴展。實現應用服務器層的負載均衡，是實現應用服務器水平擴展的最主要手段，具體實現負載均衡的策略有以下兩種：
????? a.基于硬件負載均衡設備實現負載均衡，如F5設備。
????? b.基于軟件的方式實現負載均衡，例如通過配置Apache Http Server。

????? Apache可以實現負載均衡，根據服務器的壓力情況，將每個用戶請求分布到不同的應用服務器上。但大部分應用的用戶請教是有狀態的（一般使用Session記錄用戶狀態）。這種情況下，如何能夠在多臺應用服務器之間保持用戶狀態，將是實現應用服務器層水平擴展的關鍵。
??????a.Session復制。Session復制的技術實現非常復雜，在大規模集群中實用性并不強，服務器之間大量的Session復制會嚴重影響這些服務器的性能。而隨著服務器數量的增加，這種性能影響會顯得更加突出，甚至不可接受。在大部分互聯網應用中，Session復制技術應該是很少采用的。
??????b.Session Sticky。為了避免Session復制所帶來的性能影響，更簡單、也是更高效的一種做法是Session Sticky。這種方式將同一用戶的請求轉發到特定的JBoss服務器上，避免了集群中Session的復制。Session Sticky的實現非常簡單，但是這種方式不能滿足fail-over的需求。即當一臺應用服務器down的時候，這臺服務器上正在訪問的所有用戶的Session都失效了，所有用戶不得不再次重新登錄。而且這種方式還容易導致負載不夠均衡。
??????c.基于Cache的集中式Session。這種方案通常使用集中式的Cache來代替本地Session。集中式的Session服務器采用的是MemCached，其本身也具備水平擴展能力。當Session數量大到一臺Cache服務器都不能承受的程度時，我們也僅需要增加相應的Cache服務器即可。

????? 三種水平擴展方式的比較：

實現方式	優勢	劣勢
Session復制	服務器負載可以得到較好的均衡，也可以確保fail-over的支持	Session復制會對服務器網絡環境帶來巨大的壓力，尤其在應用服務器數量較大的時候，基本不適用于大型互聯網，而且需要相應的應用服務器支持
Session Sticky	實現比較簡單，在Load Balance層做相應的配置即可，不會帶來Session復制引起的網絡環境壓力	不能實現完全的負載均衡，部分情況下負載會極端失衡，無法實現fail-over
基于Cache的集中式Session	應用服務器層無狀態，可以實現完全的負載均衡，不會帶來Session復制引起的網絡環境壓力	實現相對復雜一些，Cache本身可靠性不能絕對保證，可能會造成部分Session的丟失

??????2、數據庫層的水平擴展。相對于應用服務器層的水平擴展，數據庫層的水平擴展更難實現。實現數據庫的水平擴展也有多種方式：
??????a.數據庫的垂直切分：將不同的功能模塊所涉及的表劃分到不同的物理數據庫中，從而將對這些表的訪問壓力分擔到多個不同的物理數據庫中。
??????b.數據庫的讀/寫分離：同一個數據庫在多個物理服務器上具有多份Copy，彼此同步。然后將對于數據庫的寫操作都統一到一個主服務器上，而讀操作則分攤到多臺從服務器上。通過讀/寫分離，實現數據庫訪問壓力的分擔。
??????c.數據庫的水平切分：將原來存儲在一個數據表中的數據，按照一定的規則，切分到多個不同的物理數據庫中。每個數據庫的數據結構完全相同，但是數據各不相同。最終對于業務數據的訪問，會根據其數據所在的數據庫，定位到某一個數據庫中查詢。

??????2.1、數據庫的垂直切分。盡管數據庫的垂直切分是最容易想到的，但對于大部分應用而言，除非模塊間的關聯很少，否則要實現垂直切分也不容易：
????? a.原本可能存在的表連接，需要想辦法去除。
????? b.原本同一個數據庫的事務操作，可能會變成跨庫事務。可見數據庫的垂直切分是一個可以適當采用，但很難廣泛采用的數據庫層擴展技術。

??????2.2、數據庫的讀/寫分離技術。對于讀多寫少的互聯網應用，會廣泛采用讀/寫分離技術。盡管Slave Database Server數量是可以線性擴展的，但是基于以下兩個原因，Slave Database Server也不是越多越好。
????? a.如果應用讀/寫比例不是很懸殊，單純增加Slave Database Server對于應用性能提升并且沒有特別的作用，通常情況下，Slave Server的數量與讀/寫比例對應。
????? b.Slave Database Server過多可能造成Master-Slave之間的同步性能降低。

??????2.3、數據庫的水平切分。無論數據庫的垂直切分還是讀/寫分離，對于實現數據庫層的水平擴展，適用范圍都比較狹窄。數據庫的水平切分，通常有兩種處理方式：
????? a.一種是采用Hash算法。采用Hash算法實現更為簡單，性能也高，但是擴展性略差。因為Hash算法一開始就確定，如果后面變更的話，會涉及數據的遷移。
????? b.另一種是將對應到哪個物理數據庫也作為關系表存儲在集中式的租戶數據庫中。這種方式更為常見。在用戶登錄時，通過查詢相應的關系表，即可以確定其對應租房的業務數據存儲在具體的哪個物理數據庫中。

????? 三種數據庫層的水平擴展方案對比：

實現方式	優點	不足
垂直切分	實現簡單	擴展能力有限，強關聯的應用不容易垂直切分
讀/寫分離	可有效分擔讀的壓力，主要在數據庫層擴展，應用修改較小	對于讀的比例不高的應用，擴展能力有限。依賴于數據庫本身的同步能力
水平切分	SaaS應用中普遍適用，擴展性強，基本無限擴展	實現比較復雜，應用一般需要做較大改造。需要預先做好負載規劃，后期數據遷移比較困難

總結

以上是生活随笔為你收集整理的SaaS架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。