第 6 章 可伸縮的SaaS應(yīng)用架構(gòu)
6.1 伸縮性(Scalable)的概念 132
通常強調(diào)的應(yīng)用架構(gòu)具有可擴展伸縮星一般指的是可以實現(xiàn)“Scale out”,即水平擴展或者向外擴展。
6.2 應(yīng)用服務(wù)器層的水平擴展 133
實現(xiàn)用戶負載平衡通過硬件和軟件方式實現(xiàn)，同時需同步用戶Session狀態(tài)。
實現(xiàn)Session同步方式：1.Session.2 Session Sticky 3.基于Cache的集中式Session。
6.2.1 基于Session復(fù)制的水平擴展方式
通過Session復(fù)制，大部分應(yīng)用都可以實現(xiàn)應(yīng)用服務(wù)器集群。通過增加應(yīng)用服務(wù)器集群中的服務(wù)器數(shù)量，應(yīng)用就可以達到水平擴展的目的。
6.2.2 基于Session Sticky的水平擴展方式 137
這種方式將同一用戶的請求轉(zhuǎn)發(fā)到特定的JBoss服務(wù)器上，避免了集群中Session的復(fù)制。
6.2.3 基于Cache的集中式Session實現(xiàn)水平擴展 138
6.2.4 三種水平擴展方式的比較 139
6.3 數(shù)據(jù)庫層的水平擴展 139
1.數(shù)據(jù)庫的垂直切分
將不同的功能模塊所涉及的表劃分到不同的物理數(shù)據(jù)庫中，從而將對這些表的訪問壓力分擔(dān)到多個不同的物理數(shù)據(jù)庫中。
2.數(shù)據(jù)庫的讀/讀分離
同一個數(shù)據(jù)庫在多個物理服務(wù)器上具有多份Copy,彼此同步。然后將對于數(shù)據(jù)庫的寫操作都統(tǒng)一到一個主服務(wù)器上，而讀操作則分?jǐn)偟蕉嗯_從服務(wù)器上。通過讀/寫分離，實現(xiàn)數(shù)據(jù)庫訪問壓力的分擔(dān)。
3. 數(shù)據(jù)庫的水平切分
數(shù)據(jù)庫的水平切分：將原來存儲在一個數(shù)據(jù)表中的數(shù)據(jù)，按照一定的規(guī)則，切分到多個不同的物理數(shù)據(jù)庫中。每個數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)完全相同，但是數(shù)據(jù)各不相同。最終對于業(yè)務(wù)數(shù)據(jù)的訪問，會根據(jù)其數(shù)據(jù)所在的數(shù)據(jù)庫，定位到某一個數(shù)據(jù)庫中查詢。
實現(xiàn)步驟：
1）租戶和用戶數(shù)據(jù)必須是位于一個集中式的數(shù)據(jù)庫中。
2）用戶對應(yīng)到哪個租戶數(shù)據(jù)庫。有兩種方式：1.Hash算法。2將租戶對應(yīng)到哪個物理數(shù)據(jù)庫也作為關(guān)系表存儲在集中式的租戶數(shù)據(jù)庫中。用戶登錄時查詢對應(yīng)的關(guān)系表。
4 三種數(shù)據(jù)庫層的水平擴展方案對比
第 7 章 SaaS系統(tǒng)安全
7.1 應(yīng)用安全 150
7.1.1 身份認證 150
1.集中式認證
集中式認證，就是由SaaS應(yīng)用系統(tǒng)提供一個統(tǒng)一的用戶身份認證中心。
2. 非集中式認證
非集中式認證，就是各租戶使用自己的用戶身份認證系統(tǒng)進行身份校驗，并且發(fā)布安全令牌。SaaS應(yīng)用實現(xiàn)一個身份中心，負責(zé)接受安全令牌，并據(jù)此獲取用戶身份信息，允許用戶使用系統(tǒng)。
3. 混合認證方式
對于多租戶的SaaS應(yīng)用來說，可能需要面臨集中式認證方式與多種非集中式認證方式同時存在的混合認證方式。
7.1.2 權(quán)限管理 153
1.權(quán)限模型
對于權(quán)限模型，傳統(tǒng)系統(tǒng)廣泛地采用RBAC(Role-Based policies Access Control)模型體系。
2. 權(quán)限分配
權(quán)限分配主要包括三個方面：角色管理、用戶到角色的分配、角色許可的分配。
3. 權(quán)限效驗
1）首先校驗用戶是否購買了相應(yīng)的功能。
2）校驗用戶購買相應(yīng)功能的期限。
7.1.3 日志記錄 156
行為日志記錄
行為日志記錄就是要對用戶在系統(tǒng)中所訪問的每一個頁面，在各頁面中所做的每一個行為都記錄下來，記錄用戶的身份和行為的時刻。
數(shù)據(jù)日志記錄
數(shù)據(jù)日志記錄，就是要對用戶在系統(tǒng)中所操作的數(shù)據(jù)進行記錄，記錄數(shù)據(jù)的變更過程及變更的歷史。這在多人操作同一個數(shù)據(jù)的系統(tǒng)中顯得尤為重要。
日志記錄的安全
日志記錄是對用戶在系統(tǒng)中行為進行查證的依據(jù)。
7.1.4 應(yīng)用監(jiān)控 157
可用性監(jiān)控：要監(jiān)控應(yīng)用的硬件和軟件的可使用狀況。
可靠性監(jiān)控：對于應(yīng)用監(jiān)控的常見實現(xiàn)方案是采用心跳監(jiān)測。
7.2 數(shù)據(jù)安全 158
7.2.1 數(shù)據(jù)隔離 158
數(shù)據(jù)隔離，就是要對租戶之間的數(shù)據(jù)進行隔離，以確保各租戶數(shù)據(jù)的完整性和保密性。
7.2.2 數(shù)據(jù)庫連接安全 159
1.模擬存取
采用模擬存取方法，就是在數(shù)據(jù)庫中設(shè)置不同用戶對數(shù)據(jù)庫對象具有不同的操作權(quán)限，系統(tǒng)直接采用當(dāng)前用戶的身份去模擬操作數(shù)據(jù)庫對象。
2. 受信任的子系統(tǒng)存取
不管當(dāng)前用戶的身份如何，應(yīng)用總是使用一個特定的用戶身份與數(shù)據(jù)庫連接，操作相應(yīng)的數(shù)據(jù)庫對象，而數(shù)據(jù)庫系統(tǒng)總是信任這個用戶具有這些數(shù)據(jù)庫對象的相應(yīng)的操作權(quán)限。
7.2.3 敏感數(shù)據(jù)加密 160
對稱式加密就只需要一個密鑰，既可以用這個密鑰將明文加密成密文，也可以用它將密文解密成明文。
而非對稱式加密則需要兩個密鑰：一個公鑰和一個私鑰，公鑰用來將明文加密成密文，而私鑰用來將密文解密成明文。
7.2.4 數(shù)據(jù)量監(jiān)控 164
文件空間監(jiān)控就是要監(jiān)控租戶在對文件進行操作時，占用系統(tǒng)硬盤空間的數(shù)量。
數(shù)據(jù)使用量監(jiān)控就是要監(jiān)控租戶對系統(tǒng)數(shù)據(jù)庫空間的使用量。
7.3 網(wǎng)絡(luò)安全 165
7.3.1 安全傳輸 165
對于SaaS應(yīng)用中敏感數(shù)據(jù)的傳輸，建議采用安全超文本傳輸協(xié)議HTTPS進行傳輸。
第 8 章 離線應(yīng)用
8.1 系統(tǒng)分析 171
8.1.1 離線應(yīng)用的4大核心問題 172
既然是離線應(yīng)用，則需要在用戶機器上存放數(shù)據(jù)，也就需要系統(tǒng)能夠支持本地存儲機制。如果應(yīng)用是B/S結(jié)構(gòu)，由于界面是網(wǎng)頁，則需要將頁面存放到本地，以便離線時啟動系統(tǒng)。
由于是離線使用，將會出現(xiàn)服務(wù)器端數(shù)據(jù)與本地數(shù)據(jù)的差異，數(shù)據(jù)需要通過同步的方式保持一致。還由于存在多個客戶端，它們在與服務(wù)端同步數(shù)據(jù)的時候有可能產(chǎn)生沖突。
同時，從用戶體驗考慮，還需要解決如何減少網(wǎng)絡(luò)流量以及數(shù)據(jù)安全等問題。
8.1.2 離線應(yīng)用架構(gòu) 173
8.2 本地使用 176
8.2.2 離線頁面支持 178
為了讓B/S軟件能在離線狀態(tài)下使用，則必須將頁面保存在本地，并且要由本地Web服務(wù)器來支持。這里的“本地Web服務(wù)器”和如何保存頁面將是問題的關(guān)鍵。
8.3 本地存儲 178
8.3.1 本地數(shù)據(jù)庫支持 178
離線應(yīng)用還需要解決本地存儲，說到數(shù)據(jù)存儲，自然會想到數(shù)據(jù)庫。而這里的數(shù)據(jù)庫需要在用戶機器上運行，而IE自身沒有提供這樣的能力，但IE可以使用腳本調(diào)用ActiveX控件，因此可以通過ActiveX控件集成本地小型數(shù)據(jù)庫來實現(xiàn)數(shù)據(jù)庫的支持。本地小型數(shù)據(jù)庫引擎可以使用SQLite、Access這樣的文本數(shù)據(jù)庫。
8.4.1 增量數(shù)據(jù)處理 180
如果本地記錄的“服務(wù)器時間戳”與服務(wù)器端的“時間戳”一致，則說明從上次同步到現(xiàn)在服務(wù)器端數(shù)據(jù)未變化過；并且本地修改標(biāo)記為True。這兩個條件就能說明本地數(shù)據(jù)要比服務(wù)器端的數(shù)據(jù)新，需要將本地數(shù)據(jù)更新到服務(wù)器。如果本地的“修改標(biāo)記”為False;而服務(wù)器端的時間戳比客戶端保存的“服務(wù)器端時間戳”大。這兩個條件就能說明服務(wù)器端數(shù)據(jù)要比客戶端的數(shù)據(jù)新，需要將服務(wù)器端數(shù)據(jù)同步到本地。
8.4.2 多用戶沖突 183
如果本地的“服務(wù)器時間戳”與服務(wù)器端的“時間戳”不一致，則說明有其他人修改了服務(wù)器的數(shù)據(jù)，需要更新到本地。如果本地修改標(biāo)記也是True,則會出現(xiàn)多用戶沖
沖突解決策略
++覆蓋策略：就是“后提交者”覆蓋“前提交者”的內(nèi)容，以“后提交者”內(nèi)容為最終結(jié)果。
■ 丟棄策略：“后提交者”在提交前發(fā)現(xiàn)之前有人已經(jīng)提交過，則將自己的數(shù)據(jù)丟棄，在系統(tǒng)里仍然保留“前提交者”的內(nèi)容。
■ 提醒方案：當(dāng)發(fā)生沖突時，則將沖突信息提醒用戶，由用戶分析后確定采用“覆蓋”或“丟棄”。
8.5 數(shù)據(jù)傳輸 184
■ 傳輸協(xié)議：可以采用HTTP、FTP協(xié)議，也可以自己通過Socket實現(xiàn)自定義協(xié)議。
■ 壓縮：考慮到網(wǎng)絡(luò)帶寬限制，我們需要將數(shù)據(jù)進行壓縮處理，這能極大降低網(wǎng)絡(luò)開銷，一般多使用gzip解壓縮。當(dāng)然前面8.4.1節(jié)的增量數(shù)據(jù)處理也對網(wǎng)絡(luò)的開銷起到很關(guān)鍵的作用。
加密：為了保障應(yīng)用數(shù)據(jù)的安全性，必須要考慮對數(shù)據(jù)進行加密。比如采用SSL連接、數(shù)字簽名等。
■ 分包處理：前面我們提到有3種打包形式，即按所有變更數(shù)據(jù)打包；按業(yè)務(wù)對象打包；按每條記錄打包。
◇ 按所有變更數(shù)據(jù)打包：可能數(shù)據(jù)包會很大，我們應(yīng)該將其分成小包或文件進行傳輸。這時，就需要對這些小包或文件進行排序處理。這種打包形式在處理性能上并不是最優(yōu)的，一次性提交的數(shù)據(jù)量大而且傳輸?shù)拇涡蚩刂埔脖容^麻煩。
◇ 按業(yè)務(wù)對象打包：將本地的修改數(shù)據(jù)按業(yè)務(wù)對象區(qū)分后單獨打包。這樣對
于數(shù)據(jù)完整性是有所保障的，同時數(shù)據(jù)量也不會很大。
◇ 按每條記錄打包：這種方式需要在本地對記錄進行排序處理，因為表數(shù)據(jù)是有關(guān)聯(lián)的。如果本地不處理而放到服務(wù)器端處理，則服務(wù)器端需要作對應(yīng)的業(yè)務(wù)處理，客戶端在提交數(shù)據(jù)時先保存數(shù)據(jù)，然后按表的關(guān)聯(lián)順序插入數(shù)據(jù)庫。
■ 斷點續(xù)傳：由于網(wǎng)絡(luò)的不穩(wěn)定，對大數(shù)據(jù)包的上傳會造成失敗，從而無法完成數(shù)據(jù)的傳輸，因此需要實現(xiàn)斷點續(xù)傳功能。
第 9 章 分布式文件存儲
9.1 大文件的分布式存儲 195
9.1.1 GFS 195
GFS是Google的分布式文件系統(tǒng)解決方案。GFS的設(shè)計目標(biāo)是解決以PB為單位的海量存儲問題。它采用分布式存儲，多份拷貝的技術(shù)架構(gòu)，只使用普通服務(wù)器加普通硬盤的方式。
1PB=1024TB
9.1.2 HDFS 197
HDFS是基于Apache基金的Hadoop的核心分布式文件系統(tǒng)，也是在Google的GFS思想基礎(chǔ)上開發(fā)的開源系統(tǒng)，它實現(xiàn)了GFS的絕大部分功能。
9.2 小文件的分布式存儲 202
9.2.1 ADFS(Alibaba Distributed File System) 203
海量文件特點
1 系統(tǒng)中存在海量的文件，文件的數(shù)量是以億為單位的。
2 大多數(shù)文件是小文件，一般小于1MB(最大的為2GB)。
3 文件通常是一次寫、多次讀(寫了之后很少有修改，當(dāng)然系統(tǒng)支持對文件進行修改操作)。
當(dāng)ADFS文件系統(tǒng)應(yīng)用程序希望讀取某個文件數(shù)據(jù)時，它不是直接訪問ADFS主分配Master,而是訪問查詢Master。由查詢Master返回該文件及Meta信息和塊相關(guān)信息，降低分配Master的壓力。由于分配Master只在文件更改(創(chuàng)建、刪除、更新、副本增加、減少)時才處理業(yè)務(wù)，而系統(tǒng)中的操作絕大多數(shù)是讀操作而非寫操作，因此通過分配和查詢的分離，大大提高了分配Master的處理能力。
10.1 基于列的結(jié)構(gòu)化分布式數(shù)據(jù)庫 211
10.1.1 HBase 數(shù)據(jù)庫數(shù)據(jù)結(jié)構(gòu) 211
而HBase的設(shè)計思想與傳統(tǒng)關(guān)系數(shù)據(jù)庫不同，它以列的方式來存儲數(shù)據(jù)，而不是行。
10.2 基于代理的分布式數(shù)據(jù)庫 217
基于代理的分布式數(shù)據(jù)庫的設(shè)計思想是在數(shù)據(jù)庫和應(yīng)用程序之間搭建一個中間層，對數(shù)據(jù)庫訪問進行代理。
基于代理的分布式數(shù)據(jù)庫主要解決以下問題：
(1)數(shù)據(jù)庫連接數(shù)問題
由于目前的數(shù)據(jù)庫提供網(wǎng)絡(luò)服務(wù)時，都是基于每個連接一個進程或線程的方式，而且每個連接基本上要消耗2MB左右的內(nèi)存。因此，當(dāng)有很多數(shù)據(jù)庫客戶端訪問數(shù)據(jù)庫時，將會產(chǎn)生大量的連接，可能導(dǎo)致數(shù)據(jù)庫主機的資源耗盡而停止提供服務(wù)。不過，實際上真正需要并行處理任務(wù)的連接，沒有建立的連接多。因此，通過在中間代理層進行連接控制，使用共享連接池等技術(shù)可以解決連接過多導(dǎo)致數(shù)據(jù)庫主機資源耗盡問題。
(2)讀寫分離
對于某些應(yīng)用場景，寫操作比較少，而讀操作很頻繁。因此，采用復(fù)制的方式，數(shù)據(jù)寫到Master數(shù)據(jù)庫，讀操作分離到多個Slave數(shù)據(jù)庫進行讀操作的方式，可以提高數(shù)據(jù)庫的性能。但直接采用讀寫分離，可能涉及應(yīng)用程序的修改，應(yīng)用程序訪問數(shù)據(jù)庫的時候需要區(qū)分是讀操作還是寫操作，增加了應(yīng)用程序的復(fù)雜度。通過在中間代理層增加讀寫分離技術(shù)，這樣對應(yīng)用程序而言就是透明的，不用關(guān)心具體后臺的讀寫分離操作，
對已有程序也不需要做遷移升級。代理層接收到應(yīng)用程序的SQL語句調(diào)用時分析是讀操作還是寫操作，當(dāng)是寫操作，則分配到Master數(shù)據(jù)庫上執(zhí)行任務(wù)；若是讀操作，則根據(jù)配置，當(dāng)有多臺Slave讀數(shù)據(jù)庫時，則可以使用平均公平等算法，把讀操作分配到某臺Slave讀數(shù)據(jù)庫上去執(zhí)行任務(wù)，然后返回結(jié)果給應(yīng)用程序。
(3)數(shù)據(jù)分庫
對于一些場景，如某張表的數(shù)據(jù)量非常大，可能為幾億條記錄，并且讀寫操作很頻繁，達到每秒幾千次寫操作。這時，使用單一的數(shù)據(jù)庫主機方式就很難達到性能要求。因此，通過按照行關(guān)鍵字對表進行拆分或許是一種選擇。通過在代理層定義需要進行數(shù)據(jù)拆分的表和拆分規(guī)則，來屏蔽拆分方式對應(yīng)用程序系統(tǒng)的改造，使之對應(yīng)用開發(fā)人員透明。同時，對于匯總類的數(shù)據(jù)操作，可采用并行計算，即同時發(fā)送請求給所有后端被拆分的子數(shù)據(jù)庫系統(tǒng)去執(zhí)行任務(wù)，并把結(jié)果進行匯總后再返回給應(yīng)用程序。一個應(yīng)用程序的SQL寫操作請求到達代理層時，代理層分析此SQL語句中的表是否定義了拆分規(guī)則。若有則取出拆分規(guī)則，得到相應(yīng)的后端子數(shù)據(jù)庫。把SQL語句發(fā)送到后端子數(shù)據(jù)庫執(zhí)行，并從后端子數(shù)據(jù)庫得到結(jié)果返回給調(diào)用者。若此SQL語句是讀操作，且沒有指定規(guī)則中的行關(guān)鍵字字段，那么代理層將把此SQL語句發(fā)送給所有的后端子數(shù)據(jù)庫(符合該表拆分規(guī)則的后端子數(shù)據(jù)庫)進行并發(fā)執(zhí)行，然后代理層把所有后端子數(shù)據(jù)庫返回的結(jié)果進行匯總，然后再返回給調(diào)用者。
第 11章 分布式cache
略
第 12章 分布式計算
略
第 13章 Open API
略
第 14章 開放的SaaS平臺
14.1 PaaS 299
平臺即服務(wù)(Platform as a Service,PaaS)是SaaS技術(shù)發(fā)展的趨勢，PaaS能給客戶帶來更高性能、更個性化的基礎(chǔ)硬件和軟件服務(wù)。
因此，PaaS是要將數(shù)據(jù)、API和硬件都作為基礎(chǔ)元件，真實的開放，吸引其他角色進入平臺。
14.1.1 插件模式 301
這種PaaS模式，可以進一步把支撐應(yīng)用的下面幾層功能，從中間件一直到數(shù)據(jù)庫，還有虛擬化的OS環(huán)境，都通過網(wǎng)絡(luò)出租出去。通過網(wǎng)絡(luò)來進行遠程開發(fā)、配置、部署，最后直接在提供Hosting服務(wù)的廠商的計算中心內(nèi)運行。
14.1.2 七巧板模式 303
是一種以固定的數(shù)據(jù)類型和服務(wù)模塊為主的開放平臺。
14.1.3 云計算模式 304
云是指互聯(lián)網(wǎng)。和虛擬主機不同的是，云計算通過并行使用海量服務(wù)器，提供更強大的計算能力、存儲和帶寬，主要表現(xiàn)是分布式數(shù)據(jù)庫、分布式存儲、分布式計算等。 310
14.1.4服務(wù)器托管模式
將不同ISP的服務(wù)，通過統(tǒng)一的標(biāo)準(zhǔn)和規(guī)范提供給ISV。
14.2 互聯(lián)提升價值 311
14.2.1 拓展軟件的能力：聚合互聯(lián)網(wǎng)資源 313
ISV為什么要進來?
因為它能在這里獲取利益，不管是利益輸入者提供的利益還是ISV通過最終用戶獲取的利益。
ISV如何參與進來?
一種最高效的方式是通過Open API。ISV可以通過Open API獲取的數(shù)據(jù)，從而與其他應(yīng)用互聯(lián)。
第十五章 結(jié)束語
15.1 SaaS 發(fā)展趨勢 325
1 SaaS平臺化 325
所謂SaaS運營平臺指的是可以支撐多種SaaS應(yīng)用的，集接入、運行、推廣、銷售、計量、支付和維護為一身的綜合環(huán)境。
2 SaaS 產(chǎn)業(yè)鏈 326
SaaS產(chǎn)業(yè)鏈的基本形態(tài)就是，SaaS軟件商將SaaS應(yīng)用放到SaaS運營商的平臺上，而廣大用戶到SaaS運營平臺上尋找自己所需的應(yīng)用服務(wù)，SaaS運營平臺成為SaaS應(yīng)用的超級市場。
3 SaaS移動化 327
4 服務(wù)即軟件 328
15.2 軟件行業(yè)的未來 330
- 通過互聯(lián)網(wǎng)使用軟件的用戶越來越多 330
- 軟件和服務(wù)的界限會越來越模糊 330
- 軟件和服務(wù)會越來越個性化 331
- 軟件產(chǎn)業(yè)大融合 331
==完==
