【正文】 如下圖： c 圖表 系統(tǒng)通知等租戶不相關(guān)信息 交互 圖 整合第三方系統(tǒng) — 企業(yè)級(jí)服務(wù)總線（ ESB） ESB 這里作為企業(yè)服務(wù)的總線，來(lái)為整個(gè) SaaS RES 提供各種企業(yè)服務(wù)。對(duì)于這種“通知”類型的消息，我們可以簡(jiǎn)單的直接在業(yè)務(wù)系統(tǒng)上獲取并處理。類似這種類型消息的交互，均可部署各自對(duì)應(yīng)的“ 引擎”來(lái)處理。在這里，我們同樣可以在企業(yè)服務(wù)總線上部署一個(gè)“產(chǎn)品模塊 引擎”來(lái)為我們做這些事情。如下圖： 內(nèi) 部 運(yùn) 營(yíng) 支 撐 系 統(tǒng)E S B業(yè) 務(wù) 系 統(tǒng)R E S B O S SR E S集 中認(rèn) 證中 心賬 號(hào) 引 擎租戶賬號(hào)維護(hù)用戶賬號(hào)維護(hù)同 步數(shù) 據(jù)到 集中 認(rèn)證 中心圖表 租戶、用戶的賬戶信息交互圖 產(chǎn)品模塊 分配等租戶相關(guān)信息的交互 正如在“可配置性 — 產(chǎn)品模塊可配置”中論述的一樣，如果 BOSS 系統(tǒng)中調(diào)整了租戶 的產(chǎn)品模塊 配置，這些信息是需要同步到業(yè)務(wù)系統(tǒng)中租戶的數(shù)據(jù)庫(kù)中間去的。該引擎的主要職責(zé)就是負(fù)責(zé)把來(lái)自各個(gè)系統(tǒng)的賬戶信息， 經(jīng)過(guò)校驗(yàn)之后， 同步更新到“集中認(rèn)證中心”上去。由于我們是采用集中式認(rèn)證，無(wú)論是在 BOSS 系統(tǒng)中創(chuàng)建 租戶 的賬戶，還是在業(yè)務(wù)系統(tǒng)中創(chuàng)建的賬戶，都需要 把賬戶信息傳 送到“集中認(rèn)證中心”去，以便所有租戶和用戶的正常登陸。關(guān)于這點(diǎn)，在下一節(jié)中論述。 如上所述，租戶下權(quán)限的“再分配”是放在業(yè)務(wù)系統(tǒng)中的，那么就意味著，當(dāng)“租戶管理員”根據(jù)合同或者協(xié)議，調(diào)整了租戶可使用的產(chǎn)品模塊的時(shí)候，這個(gè)改變需要被 RES 系統(tǒng)感知，從而使這個(gè)改變生效。為了簡(jiǎn)單起見，在這里我們把這個(gè)“再分配”的過(guò)程放在業(yè)務(wù)系統(tǒng)中去。 第二個(gè)就是租戶在經(jīng)過(guò)“租戶管理員”分配模塊后，在實(shí)際使用系統(tǒng)的過(guò)程中， 對(duì)其自身的用戶進(jìn)行產(chǎn)品模塊功能權(quán)限“再分配”的過(guò)程。 可配置性 — 產(chǎn)品模塊可配置 針對(duì)產(chǎn)品模塊的可配置性，在這里主要有兩個(gè)方面： 第一個(gè)就是 SaaS 服務(wù)提供商的“租戶管理員”對(duì)租戶進(jìn)行產(chǎn)品模塊配置（這個(gè)操作實(shí)際上就是商務(wù)人員或者運(yùn)營(yíng)人員根據(jù)合同，來(lái)對(duì)租戶在系統(tǒng)中的可使用范圍進(jìn)行分配）。因此，在修改密碼的時(shí)候，我們要用新的密碼加密“數(shù)據(jù)密文”。這所有的一切都是對(duì)最終用戶透明的。由于“數(shù)據(jù)密文”是租戶下每個(gè)用戶都會(huì)用到的，所以當(dāng)“ 租戶第一人 ”再添加“用戶”的時(shí)候，這個(gè)“數(shù)據(jù)密文”需要傳遞給其他用戶并保存起來(lái)（同樣經(jīng)過(guò)用戶密碼的對(duì)稱加密）。由于用戶的密碼一般都是不可逆加密的，比如 MD5 算法，因此認(rèn)為是可以信賴的，真正的用戶密碼是存儲(chǔ)在用戶記憶中的。 針對(duì)“數(shù)據(jù)密文”的加密，我們采用用戶登陸密碼來(lái)加密。也就是說(shuō)，有了某個(gè)租戶的“數(shù)據(jù)密文”，就可以對(duì)該租戶的敏感數(shù)據(jù)進(jìn)行操作了。 既然是“對(duì)稱加密”，那么每個(gè)租戶都應(yīng)該有一個(gè)對(duì)應(yīng)的“數(shù)據(jù)密文”?！翱赡婕用堋庇址譃椤皩?duì)稱加密”和“非對(duì)稱加密”，雖然兩者都可逆，但是他們?cè)诩用芎徒饷苓^(guò)程中的計(jì)算強(qiáng)度是不一樣的。 （ 就目前的需求來(lái)看，并沒有敏感數(shù)據(jù)加密的要求，因此，我們目前僅僅只是對(duì)用戶的密碼進(jìn)行 MD5 加密。因此，租戶敏感數(shù)據(jù)的加密是非常重要的！這些敏感數(shù)據(jù)是只允許租戶內(nèi)部的用戶存 取的，不能被其他租戶和商業(yè)競(jìng)爭(zhēng)對(duì)手獲取，甚至連對(duì) SaaS 服務(wù)提供商都需要保密！因此，我們需要制定合適的安全策略來(lái)滿足這個(gè)要求。 租戶敏感數(shù)據(jù)加密 一般租戶很難接受主機(jī)尤其是數(shù)據(jù)托管在第三方。因此，在這種情況下，就不需要“受限”動(dòng)態(tài)路由了。面對(duì)這么多 MySQL 實(shí)例，如果動(dòng)態(tài)路由不受限制的話，那么在理論上就會(huì)出現(xiàn)一個(gè)應(yīng)用服 務(wù)器上維持著 N 個(gè)數(shù)據(jù)源的連接池，這是相當(dāng)消耗系統(tǒng)資源的！所謂“受限”，也就是指一個(gè)應(yīng)用一般只維護(hù) 2~4 個(gè) MySQL 實(shí)例的數(shù)據(jù)源（當(dāng)然也可 能 3~5，這個(gè)數(shù)字需要從測(cè)試中得出，并在實(shí)際中是可以調(diào)整的）。 之所以說(shuō)是“受限”動(dòng)態(tài)路由，是因?yàn)樵趯?lái)隨著租戶數(shù)量的不斷擴(kuò)大，我們可能需要多個(gè)MySQL 實(shí)例來(lái)提供服務(wù)。而我們的應(yīng)用程序都是相同的，這就 要求 我們的程序必須能感知到這一點(diǎn)，然后把租戶 SQL 正確的發(fā)送給正確的 MySQL 實(shí)例上。而對(duì)于 MySQL 來(lái)說(shuō)，一個(gè) MySQL 實(shí)例中大約只能存放 1000 個(gè) schema，如果 再多的話，可能會(huì)對(duì)數(shù)據(jù)庫(kù)的啟動(dòng)和性能產(chǎn)生影響。下面列舉影響 Web 性能的主要因素： 影響 web 性能的因素 1. 頁(yè)面過(guò)大：頁(yè)面在 500k 以上 2. 圖片和 iframe 過(guò)多：會(huì)導(dǎo)致增加請(qǐng)求數(shù) 3. Cookie 內(nèi)容過(guò)大：會(huì)導(dǎo)致發(fā)起請(qǐng)求變慢 三十四條黃金守則 著名的雅虎為我們提供了網(wǎng)站性能上的三十四條守則，這些守則可以約束我們的設(shè)計(jì)，總結(jié)列舉如下： 內(nèi)容類 ? 減少 請(qǐng)求 ? 減少 DNS 查找 ? 避免跳 轉(zhuǎn) ? 緩存 ajax ? 延遲加載 ? 提前加載 ? 減少 DOM 元素?cái)?shù)量 ? 用域名劃分頁(yè)面內(nèi)容 ? 減少 frame ? 避免 404 錯(cuò)誤 服務(wù)器與 Cookie 類 ? 使用 CDN ? 為文件頭制定 Expires 或 CacheControl ? GZip 壓縮網(wǎng)頁(yè) ? 配置實(shí)體標(biāo)簽 ? 盡早刷新輸出緩沖 ? 使用 Get 完成 ajax 請(qǐng)求 ? 減小 Cookie 體積 ? 對(duì)于頁(yè)面內(nèi)容使用無(wú) Cookie 域名 JavaScript、 CSS、圖片類 ? 把腳本至于頁(yè)面底部 ? 使用外部 JavaScript 和 CSS ? 消減 JavaScript 和 CSS ? 提出重復(fù)腳本 ? 減少 DOM 訪問(wèn) ? 開發(fā)智能事件處 理程序 ? 把樣式置于頂部 ? 避免使用 CSS 表達(dá)式（ Expression） ? 使用外部 JavaScript 和 CSS ? 用 link代替 import ? 避免使用濾鏡 ? 優(yōu)化圖像 ? 優(yōu)化 CSS Sprites ? 不要在 HTML 中縮放圖像 ? 要小且可緩存 移動(dòng)應(yīng)用類 ? 保持單個(gè)內(nèi)容小于 25KB ? 打包組件成復(fù)合文本 業(yè)務(wù)處理上 在業(yè)務(wù)處理上， 對(duì)需要展現(xiàn)的信息進(jìn)行分析， 盡量展現(xiàn)比較少的數(shù)據(jù)，比如在一般的分頁(yè)查詢之中，每頁(yè)展現(xiàn) 10 條數(shù)據(jù)。這就可能會(huì)出現(xiàn)多個(gè)用戶在共享的帶寬下同時(shí)訪問(wèn)我們的 SaaS 應(yīng)用的情形，要使得這些用戶獲 得良好的響應(yīng)速度和體驗(yàn)，就要求我們的 SaaS 應(yīng)用不應(yīng)該占用過(guò)多的帶寬資源。 租戶帶寬上的限制 SaaS 模式下，應(yīng)用都是基于互聯(lián)網(wǎng)的，因此最終用戶也是通過(guò)互聯(lián)網(wǎng)來(lái)使用 SaaS 應(yīng)用的。 用戶賬號(hào)規(guī)則 按照目前的規(guī)劃，用戶賬號(hào)的命名規(guī)則由租戶自己決定。 就目前而言， 單點(diǎn)登陸的賬號(hào)和密碼等信息是存放在數(shù)據(jù)庫(kù)中的（ MySQL）。 Web 環(huán)境下的單點(diǎn)登陸，業(yè)內(nèi)已經(jīng)有了很多解決方案，比如著名的 CAS 和 OpenID 等等。 舉個(gè)例子來(lái)說(shuō)，登陸流程是 這樣的 ： 1. 用戶 usera 想進(jìn)入系統(tǒng)，由于未登錄，會(huì)被應(yīng)用引導(dǎo)至登陸頁(yè)面進(jìn)行登陸，比如 2. 用戶 usera 提交用戶名和密碼 3. 系統(tǒng)驗(yàn)證賬戶的有效性，如果賬戶有效，那么系統(tǒng)會(huì)查找出 usera 是屬于租戶 A 的，接下來(lái)構(gòu)建租戶 A 的有效路徑返回給 usera，類似 （注：在存在租戶個(gè)性化頁(yè)面定制和按租戶分區(qū)訪問(wèn)情況下， url 需要包含租戶標(biāo)識(shí)，如 見“ 藍(lán)色透明部分 ”和《 SaaS 模式系統(tǒng)參考架構(gòu)設(shè)計(jì) .doc》中的“ 租戶界面可定制（個(gè)性化） ” ） 4. 用戶 usera 進(jìn)入正確的訪問(wèn)地址了，如 同樣的，如果 userb 屬于租戶 B，想要登陸系統(tǒng)，同上面的步驟相同。這就是“集中式認(rèn)證”的概念。只有在他通過(guò)認(rèn)證之后，我們才可以知道當(dāng)前登陸用戶的信息。 因此，我們目前選用第二種方式，即一個(gè)租戶一個(gè) schema 的方式作為目前支持多租戶的數(shù)據(jù)結(jié)構(gòu)。（即一個(gè) schema 被多個(gè)租戶共享） 對(duì)于以上三種方式的比較，可以從下表看出： 方式 隔離性 安全性 成本 獨(dú)立數(shù)據(jù)庫(kù) 高 高 高 一 個(gè)租戶一個(gè) schema 中 中 中 多個(gè)租戶共享 schema 低 低 低 圖表 三種支持多租戶數(shù)據(jù)結(jié)構(gòu)方式比較圖 第一種方式，似乎和傳統(tǒng)的軟件沒什么區(qū)別，只適合高端用戶和隔離性要求很強(qiáng)的用戶，比如醫(yī)院、銀行等等，對(duì)于普通的租戶情況不適用，因?yàn)槌杀咎摺? 通過(guò)這樣的設(shè)計(jì)，利用權(quán)限組件框架提供的擴(kuò)展點(diǎn)，既能很好的實(shí)現(xiàn)系統(tǒng)對(duì)于數(shù)據(jù)權(quán)限控制的要求，也讓 數(shù)據(jù)權(quán)限控制的邏輯和功能權(quán)限控制邏輯一樣，從業(yè)務(wù)系統(tǒng)的業(yè)務(wù)邏輯中抽離，使系統(tǒng)的結(jié)構(gòu)更加合理和靈活。其原理如下圖： 圖表 權(quán)限組件 圖 用戶的請(qǐng)求還是先要進(jìn)行 RBAC 的功能權(quán)限判斷（見上述說(shuō)明），當(dāng)通過(guò)了功能權(quán)限判斷后，用戶請(qǐng)求會(huì)進(jìn)一步被傳遞給訪問(wèn)前權(quán)限處理器，這里的“訪問(wèn)前權(quán)限處理器”就是權(quán)限組件的框架提供的一個(gè)擴(kuò)展點(diǎn)， SaaS RES 需要實(shí)現(xiàn)此處理器，它的作用是進(jìn)行數(shù)據(jù)權(quán)限處理，判斷當(dāng)前用戶對(duì)目標(biāo)數(shù)據(jù)是否有操作權(quán)，如果沒有，則直接拒絕訪問(wèn)，如果有，則可以對(duì)用戶的請(qǐng)求進(jìn)行加工，最常見的做法是，為請(qǐng)求添加上數(shù)據(jù)篩選過(guò)濾條件，如：用戶發(fā)起了 一個(gè)獲取客戶列表的功能請(qǐng)求，該用戶是銷售團(tuán)隊(duì) A 的普通銷售員，訪問(wèn)前權(quán)限處理器發(fā)現(xiàn)普通銷售員這個(gè)角色的數(shù)據(jù)權(quán)限級(jí)別是“本人負(fù)責(zé)的數(shù)據(jù)”，則對(duì)該請(qǐng)求進(jìn)行加工，為其添加上“數(shù)據(jù)擁有者標(biāo)識(shí)”作為篩選條件，然后再把請(qǐng)求發(fā)送給業(yè)務(wù)系統(tǒng)的對(duì)應(yīng)功能服務(wù)。權(quán)限組件 雖然沒有提供數(shù)據(jù)權(quán)限控制的實(shí)現(xiàn)，但它卻提供了一個(gè)良好的框架，讓業(yè)務(wù)系統(tǒng)可以在框架的基礎(chǔ)上進(jìn)行擴(kuò)展，實(shí)現(xiàn)數(shù)據(jù)權(quán)限控制。 決策： 根據(jù)上面的分析，我們可以有兩種方式實(shí)現(xiàn)數(shù)據(jù)權(quán)限控制： ? 直接在業(yè)務(wù)代碼中編寫數(shù)據(jù)權(quán)限控制的邏輯，把它視作業(yè)務(wù)邏輯的一部分； ? 通過(guò)權(quán)限組件 提供的框架進(jìn)行擴(kuò)展。這些可以看作是系統(tǒng)業(yè)務(wù)的一部分，但對(duì)于 SaaS RES 來(lái)說(shuō)，這種數(shù)據(jù)級(jí)別的權(quán)限控制是相對(duì)穩(wěn)定和單一的，如上所述，它只有三個(gè)級(jí)別的數(shù)據(jù)權(quán)限。 使用權(quán)限組件這種攔截機(jī)制的好處是：把基于角色的訪問(wèn)控制邏輯徹底的從業(yè)務(wù)邏輯中分離，業(yè)務(wù)開發(fā)人員只需要關(guān)注業(yè)務(wù)，無(wú)需編寫任何權(quán)限判斷的邏輯，這大大減輕了業(yè)務(wù)開發(fā)人員的工作量，也提高了系統(tǒng)的靈活性。目前系統(tǒng)定義了三個(gè)級(jí)別的數(shù)據(jù)權(quán)限： ? 全部：對(duì)應(yīng)功能權(quán)限能操作所有相關(guān)數(shù)據(jù)； ? 本人管轄的員工負(fù)責(zé)的數(shù)據(jù)：對(duì)應(yīng)功能權(quán)限只能操作當(dāng)前用戶擁有的數(shù)據(jù)，以及當(dāng)前用戶所在部門（包括下級(jí)部門）的所有員工所擁有的數(shù)據(jù)； ? 本人負(fù)責(zé)的數(shù)據(jù)：對(duì)應(yīng)功能權(quán)限只能操作當(dāng)前用戶擁有的數(shù)據(jù)。 創(chuàng)建訂單只不過(guò)是整個(gè)系統(tǒng)的其中一個(gè)典型的功能點(diǎn)，對(duì)于其他類似的功能，如財(cái)務(wù)收退款這些敏感操作，我們都需要采用相同的策略對(duì)數(shù)據(jù)進(jìn)行鎖定處理。樂(lè)觀鎖不能保證先開啟的事務(wù)對(duì)數(shù)據(jù)占有主動(dòng)權(quán)，實(shí)際上是先提交的事務(wù)才會(huì)被成功提交，但樂(lè) 觀鎖基本不會(huì)浪費(fèi)數(shù)據(jù)庫(kù)的性能開銷，而且不依賴于數(shù)據(jù)庫(kù)的鎖機(jī)制實(shí)現(xiàn)。樂(lè)觀鎖采取比悲觀鎖相對(duì)寬松的策略，它的原理是，為數(shù)據(jù)增加一個(gè)用于記錄“版本”的字段，當(dāng)事務(wù)讀取數(shù)據(jù)時(shí)，會(huì)把數(shù)據(jù)的版本號(hào)也一并讀取，當(dāng)事務(wù)修改了數(shù)據(jù)后， Hibernate 會(huì)自動(dòng)把該數(shù)據(jù)的版本號(hào)加 1，然后在提交事務(wù)前，把該版本號(hào)與數(shù)據(jù)庫(kù)中的對(duì)應(yīng)數(shù)據(jù)的版本號(hào)進(jìn)行對(duì)比，如果該版本 號(hào)高于數(shù)據(jù)庫(kù)記錄的版本號(hào)，證明在事務(wù)過(guò)程中沒有其他事務(wù)修改并提交過(guò)對(duì)應(yīng)數(shù)據(jù)，事務(wù)被提交；如果該版本號(hào)不高于數(shù)據(jù)庫(kù)記錄的版本號(hào)，則說(shuō)明事務(wù)過(guò)程中已經(jīng)有其他事務(wù)修改了該數(shù)據(jù)并提交，事務(wù)提交被拒絕。 Hibernate 提供了兩種數(shù)據(jù)鎖定機(jī)制：悲觀鎖和樂(lè)觀鎖。根據(jù)創(chuàng)建訂單的業(yè)務(wù)規(guī)則，訂單只能預(yù)訂狀態(tài)為“可售”的房間，當(dāng)下訂成功后，房間狀態(tài)被改變?yōu)椤耙咽邸保ＷC不出現(xiàn)上述爭(zhēng)訂的情況，事實(shí)上就是要保證在整個(gè)訂單創(chuàng)建過(guò)程房間狀態(tài)數(shù)據(jù)變化的排它 性。 另外，對(duì)于一些變化頻率很低或者不會(huì)發(fā)生變化的數(shù)據(jù)，如很多頁(yè)面的下拉菜單數(shù)據(jù)等，為了減輕數(shù)據(jù)庫(kù)服務(wù)的 IO 壓力，還需要采取緩存策略。 注：上圖只是為了表達(dá)清晰，省略了領(lǐng)域?qū)?，?shí)際上，“查詢通道”只是一個(gè)概念，在實(shí)際設(shè)計(jì)中，會(huì)把查詢方法都封裝在領(lǐng)域?qū)ο髠}(cāng)庫(kù)接口中，實(shí)現(xiàn)放在領(lǐng)域?qū)ο髠}(cāng)庫(kù)實(shí)現(xiàn)中，所以，應(yīng)用服務(wù)層還是通過(guò)調(diào)用領(lǐng)域?qū)拥念I(lǐng)域?qū)ο髠}(cāng)庫(kù)查詢接口完成查詢業(yè)務(wù)的。 這一系列的問(wèn)題說(shuō)明，對(duì)象查詢業(yè)務(wù)、報(bào)表業(yè)務(wù)并不適合使用“充血模型”進(jìn)行設(shè)計(jì)。 對(duì)象 的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù) 分析： 對(duì)象的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù)同樣也是系統(tǒng)的典型操作，與對(duì)象的增、刪、改不同，對(duì)象的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù)的共同特征是： 1）這些操作不會(huì)改變業(yè)務(wù)實(shí)體的狀態(tài)和數(shù)據(jù)； 2）這些操作返回的數(shù)據(jù)量可能比較大； 3）這些操作查詢的結(jié)果很多時(shí)候是跨領(lǐng)域?qū)ο蟮臄?shù)據(jù)視圖； 4）這些操作通常比較頻繁； 5）這些操作不需要調(diào)用領(lǐng)域?qū)ο蟮木哂袠I(yè)務(wù)意義的方法。我們?cè)俜治鲎詈笠粋€(gè)業(yè)務(wù)約束，由于客戶是否需要審核是由系統(tǒng)設(shè)置決定的，因此該判斷邏輯同樣不屬于客戶實(shí)體的職責(zé)范圍，應(yīng)該由客戶管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置服務(wù)完成，綜上所述，得出如下時(shí)序圖： 注：該用例表達(dá)的是邏輯刪除的場(chǎng)景，物理刪除的場(chǎng)景與此基本一致，唯一的不同是需要在業(yè)務(wù)處理的最后通過(guò)實(shí)體對(duì)應(yīng)的倉(cāng)庫(kù)從持久層