SaaS架構設計

 對於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.另一種是將對應到哪個物理資料庫也作為關係表格儲存體在集中式的租戶資料庫中。這種方式更為常見。在使用者登入時，通過查詢相應的關係表，即可以確定其對應租房的業務資料存放區在具體的哪個物理資料庫中。

      三種資料庫層的水平擴充方案對比：

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