【正文】 .............................. 60 與 BOSS 運營系統(tǒng)有關(guān)系統(tǒng)消息的交互流程 ............................................................... 60 6 架構(gòu)驗證 .............................................................................................................. 60 性能 ................................................................................................................................... 60 安全性 ............................................................................................................................... 60 可擴(kuò)展性 ........................................................................................................................... 60 可運維性 ........................................................................................................................... 61 7 風(fēng)險評估 .............................................................................................................. 62 數(shù)據(jù)庫無法支撐大量租戶風(fēng)險（ IO 瓶頸） ............................................................ 62 高峰期的訪問風(fēng)險 ...................................................................................................... 62 1 項目背景 SaaS 源于一種簡單的思想：軟件即服務(wù)！隨著一大批 的公司， 如國外的 Salesforce 在這個領(lǐng)域取得的輝煌成績， SaaS 已經(jīng)徹底改變了人們對軟件的觀念，使用軟件的人從產(chǎn)品消費者轉(zhuǎn)換成服務(wù)消費者，而開發(fā)軟件的人從產(chǎn)品提供者轉(zhuǎn)變?yōu)榉?wù)提供者。 為了順應(yīng)當(dāng)今 IT 企業(yè)級應(yīng)用的發(fā)展趨勢和滿足公司戰(zhàn)略發(fā)展的需要，本 架構(gòu)文檔 旨在描述 在 SaaS 這種 商業(yè)模式下，如何搭建 適合目前公司現(xiàn)狀的 企業(yè)信息化 系統(tǒng) 。 從用戶方面來看：用戶可以只花少量的資金就可以使用一款軟件了，并可以很直觀的評估軟件是否滿足要求或者是否適合公司的管理模式，大大降低了軟件產(chǎn)品的資金投入以及風(fēng)險。大大降低了成本。 從軟件商來看： SaaS 模式大大節(jié)省了銷售的成本，軟件商可以把重點資源放在市場推廣方面，銷售反而是順理成章的事情。這種模式勢必導(dǎo)致成本劇增，而 SaaS 卻能保證軟件對客戶的服務(wù)響應(yīng)快捷和高效。 SaaS RES 就是 SaaS 商業(yè)模式 下 的房地產(chǎn)營銷管理系統(tǒng)。 2 關(guān)鍵需求 關(guān)鍵功能需求 ? 與 SaaS BOSS 運營支撐系統(tǒng)進(jìn)行交互 ： SaaS BOSS 系統(tǒng)主要對整個 RES 業(yè)務(wù)系統(tǒng)的正常運營起到 管理和 支撐作用。 ? 業(yè)務(wù)實體的的增、刪、改及一些復(fù)雜的業(yè)務(wù)處理功能：對于 SAAS RES 系統(tǒng)來說，業(yè)務(wù)實體的增、刪、改是最常見的操作，它們屬于業(yè)務(wù)實體的維護(hù)操作，在系統(tǒng)的產(chǎn)品管理、客戶管理、銷售管理、服務(wù)管理和財務(wù)管理模塊都普遍存在，這些操作都包括一些數(shù)據(jù)校驗，業(yè)務(wù)約束等處理邏輯，除了業(yè)務(wù)實體的增、刪、改等數(shù)據(jù)維護(hù)操作外，一些復(fù)雜的業(yè)務(wù)處 理功能也具有相當(dāng)?shù)牡湫托裕@些復(fù)雜的業(yè)務(wù) 處理通常涉及多個業(yè)務(wù)實體的狀態(tài)變化以及它們之間的業(yè)務(wù)約束，而且這些業(yè)務(wù)邏輯很大機(jī)會隨著業(yè)務(wù)的發(fā)展而變化，因此，如何通過合理的設(shè)計來保證以一個清晰的結(jié)構(gòu)來表達(dá)這種業(yè)務(wù)模型，并能夠讓模型有足夠的靈活性來應(yīng)付將來可能發(fā)生的業(yè)務(wù)變化顯得非常的關(guān)鍵，在架構(gòu)分析中，將會以“客戶下訂單（即創(chuàng)建訂單）”作為用例進(jìn)行分析。 ? 創(chuàng)建訂單 —— 典型的高并發(fā)資源爭用業(yè)務(wù)：這種業(yè)務(wù)對 數(shù)據(jù)在處理過程中的排他性有非常嚴(yán)格的要求，即業(yè)務(wù)數(shù)據(jù)在某個事務(wù)處理過程中，絕對不能受到其他事務(wù)處理的干擾，“創(chuàng)建訂單”用例就是這一關(guān)鍵功能需求的典型用例，在架構(gòu)分析中將會對如何保證這種事務(wù)排他性進(jìn)行詳細(xì)分析。 ? 需要整合第三方系統(tǒng)提供附加值，包括用“在線客服”為租戶在線的、及時的支持服務(wù)；用“ SMS”為租戶提供短信服務(wù)；用“ EMail” 為租戶提供發(fā)送業(yè)務(wù)郵件和郵件提醒服務(wù)。每個租戶最大的用戶數(shù) 100，所有租戶平均用戶數(shù)50。 ? 并發(fā)數(shù)： 5% * 平均在線人數(shù) = 625 次 每秒 ? 性能：系統(tǒng)及時提供相應(yīng)服務(wù)的能力。大部分操作的響應(yīng)時間控制在 3 秒以內(nèi)。如用戶驗證安全性，用戶數(shù)據(jù)安全性等。系統(tǒng)在升級過程中，降低或避免老客戶的適應(yīng)難度。如當(dāng)業(yè)務(wù)量增大時 （比如用戶操作頻繁或者增加了租戶） ，可以通過增加服務(wù)器來提高性能，無需對系統(tǒng)進(jìn)行編程級修改，也不會對最終用戶的使用產(chǎn)生影響。 ? 隔離性：減少租戶與租戶之間的相互影響，租戶之間的數(shù)據(jù)必須良好隔離。 ? 可移植性：根據(jù)租戶數(shù)量或服務(wù)水平，可容易的從 一個運行環(huán)境轉(zhuǎn)移到另一個不同 的運行環(huán)境。系統(tǒng)的安裝、部署、擴(kuò)展、升級、新租戶的加入必須容易，減少出差錯。對故障的處理必須簡單快速。 關(guān)鍵 商業(yè)需求 ? 系統(tǒng) 版本的規(guī)劃最大租戶數(shù)是 500 ? 系統(tǒng)必須在 2022 年 11 初月交付 ? 該產(chǎn)品能方便 IDC 運營管理 ? 系統(tǒng)支持多 租戶，按租戶合同，進(jìn)行靈活的模塊配置，不同租戶可以購買不同的業(yè)務(wù)模塊 關(guān)鍵 約束 ? 使用 Apache 作 Web Http Server ? 使用 OSGi 作應(yīng)用所在環(huán)境（容器選用 jetty 或者 tomcat，待測） ? 使用 作為數(shù)據(jù)庫 名詞解釋 “租戶”：指購買 SaaS 應(yīng)用的客戶，比如 某個開發(fā)商購買了 RES，那么這個開發(fā)商就是“租戶”。 指 SaaS 服務(wù)提供商內(nèi)部，負(fù)責(zé)管理“租戶”的管理員，該管理員的職責(zé)一般是根據(jù)合同來添加租戶，添加租戶的“ 租戶第一人 ”， 修改租 戶信息，修改租戶各種配置信息等。 “ 租戶第一人 ”： 由租戶自己使用。 “用戶”和“賬戶”在本文的描述中都是只用戶用來登陸系統(tǒng)的用戶名。 5 架構(gòu)設(shè)計 SaaS 模式的架構(gòu)設(shè)計和普通系統(tǒng)的架構(gòu)設(shè)計有所不同， SaaS 除了要滿足用戶各種個性化要求以外，應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器要滿足成千上萬的請求，因此，對系統(tǒng)可用性、伸縮性、擴(kuò)展性以及性能提出了更高的要求。 架構(gòu)分析 下面主要綜合之前的功能性和非功能性的要求，來對系統(tǒng)的整個架構(gòu)進(jìn)行分析。 決策： 系統(tǒng)使用最常見的層式架構(gòu)進(jìn)行設(shè)計，按邏輯被劃分為：展示層、應(yīng)用服務(wù)層、領(lǐng)域?qū)雍蛿?shù)據(jù)訪問層，下圖展示了系統(tǒng)各邏輯層之間的關(guān)系： 展 示 層 （ W e b 層 ） 應(yīng) 用 服 務(wù) 層 領(lǐng) 域 層數(shù) 據(jù) 訪 問 層（ O R M ）D O R e p o s i t o r yD OD OD OD OD OD OS e r v i c eS e r v i c eS e r v i c eA c t i o nA c t i o nA c t i o nD O R p s t I m p lD O R p s t I m p lD O R p s t I m p l圖表 增、刪、改操作設(shè)計決策圖（充血模型） ? 展示層：負(fù)責(zé)為用戶提供用戶界面，接收用戶的輸入?yún)?shù)，提交給應(yīng)用服務(wù)層執(zhí)行相應(yīng)業(yè)務(wù)操作，并接收應(yīng)用服務(wù)層的返回結(jié)果展示給用戶，其直接依賴于應(yīng)用服務(wù)層。 ? 領(lǐng)域?qū)樱?包含業(yè)務(wù)領(lǐng)域內(nèi)的一系列相關(guān)領(lǐng)域?qū)ο蠹捌鋫}庫接口，領(lǐng)域?qū)ο蠓庋b其領(lǐng)域內(nèi)的業(yè)務(wù)邏輯，領(lǐng)域?qū)ο笸ㄟ^其倉庫獲取和持久化。該層只提供持久化實現(xiàn)，持久化操作的接口由領(lǐng)域?qū)佣x，因此，該層依賴于領(lǐng)域?qū)犹峁┫嚓P(guān)領(lǐng)域?qū)ο蟮臄?shù)據(jù)結(jié)構(gòu)和持久化操作接口。 領(lǐng)域驅(qū)動設(shè)計，或者說面向?qū)ο笤O(shè)計的最重要規(guī)則是：把不同的職責(zé)合理的劃分到不同的對象中，根據(jù)這一規(guī)則，我們對上述的業(yè)務(wù)約束進(jìn)行分析： 客戶屬性是否必填，屬于客戶實體自身的業(yè)務(wù)完整性約束，因此，這部分職責(zé)應(yīng)該交給客戶實體本身負(fù)責(zé)； 客戶的姓名和聯(lián)系電話是客戶身份的唯一標(biāo)識，這意味著系統(tǒng)不能存在兩個具有相同姓名和聯(lián)系電話的客戶，這 就需要在創(chuàng)建客戶的時候進(jìn)行檢查，而這部分工作，對于客戶實體來說，它并不了解其他客戶實體的信息，因此，應(yīng)該交由其上層，客戶管理應(yīng)用服務(wù)負(fù)責(zé)。 根據(jù)上述的業(yè)務(wù)約束進(jìn)行分析，系統(tǒng)是否開啟客戶信息修改審核功能，很明顯不屬于個人客戶實體的職責(zé)，因此它應(yīng)該由應(yīng)用服務(wù)層負(fù)責(zé)，同時，由于客戶管理應(yīng)用服務(wù)的職責(zé)是對客戶信息進(jìn)行管理，而客戶信息修改審核功能的設(shè)置是由系統(tǒng)參數(shù)設(shè)置模塊負(fù)責(zé)，所以，這項職責(zé)應(yīng)該由系統(tǒng) 參數(shù)設(shè)置應(yīng)用服務(wù)提供，而判斷是否修改了客 戶核心信息，很明顯屬于個人客戶的職責(zé)。經(jīng)過上述分析，得出下述的時序圖： 修改領(lǐng)域?qū)ο髸r序圖 用例 3：把個人客戶信息放入回收站 —— 業(yè)務(wù)實體的刪除操作 把個人客戶信息放入回收站有如下的業(yè)務(wù)約束： ? 參加過認(rèn)籌登記的客戶不能放入回收站； ? 交過錢（存在 財務(wù)付款記錄）的客戶不能放入回收站； ? 下過訂單的客戶不能放入回收站 ? 正在提交審核（被修改或合并后未審核通過）的客戶不能放入回收站。進(jìn)一步分析，上述判斷邏輯都只是一種查詢服務(wù)，并不會對任何業(yè)務(wù)實體產(chǎn)生狀態(tài)影響，因此，可以通過在客戶領(lǐng)域?qū)ο髠}庫中提供一個特殊的查詢服務(wù)來獲取。 用例 4：客戶下訂單（即創(chuàng)建訂單） —— 典型的復(fù)雜業(yè)務(wù)處理功能 客戶下訂單有如下的業(yè)務(wù)約束（注：由于該用例業(yè)務(wù)功能非常復(fù)雜，而且在結(jié)構(gòu)設(shè)計階段，銷售模塊的需求分析還沒完全完成，因此該用例的業(yè)務(wù)約束將忽略一些不是很重要的細(xì)節(jié)，該用例的最終模型和時序圖以銷售管理模塊的詳細(xì)設(shè)計為準(zhǔn)）： ? 下訂單 時可以根據(jù)系統(tǒng)參數(shù)的設(shè)置同時修改客戶信息； ? 只有狀態(tài)為“可售”的且有定價的房間可以進(jìn)行下訂單； ? 當(dāng)系統(tǒng)參數(shù)設(shè)置組合房間可以拆開銷售時，組合房間和基礎(chǔ)房間都可以下訂單，否則，被組合的基礎(chǔ)房間不可售； ? 根據(jù)系統(tǒng)參數(shù)設(shè)置判斷是否可以使用歷史價格； ? 如果有客戶有進(jìn)行認(rèn)籌登記，需要對認(rèn)籌登記進(jìn)行解籌，并把認(rèn)籌金額轉(zhuǎn)換為定金； ? 需要根據(jù)各種優(yōu)惠及款項信息計算訂單的總折扣率和折后總房價； 分析業(yè)務(wù)約束，第一個業(yè)務(wù)約束很明顯不屬于訂單實體及其他相關(guān)實體的職責(zé)，由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷，當(dāng)可對客戶信 息進(jìn)行修改時，還需要委托客戶管理應(yīng)用服務(wù)提供修改服務(wù)；房間是否可售需要根據(jù)房間狀態(tài)決定，這職責(zé)明顯是由房間實體負(fù)責(zé)；已組合的基礎(chǔ)房間是否可售，由系統(tǒng)參數(shù)設(shè)置決定，所以應(yīng)該由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷，至于房間是否已經(jīng)被組合，這是房間實體本身的職責(zé)；可否使用房間歷史價格，由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷；對于解籌操作，訂單實體包含認(rèn)籌登記記錄，因此應(yīng)該由訂單負(fù)責(zé)；訂單的總折扣率和折后總房價是由訂單的各種優(yōu)惠及款項信息決定的，因此屬于訂單的職責(zé)，但進(jìn)一步分析，總折扣率和折 后總房價可能由不同的計算方式，因此，應(yīng)該設(shè)計一個訂單總折扣率和折后總房價計算器實體，并由訂單委托其進(jìn)行計算，綜上所述，得出如下時序圖： 客戶下訂單時序圖 這個時序圖的設(shè)計并不是最終的客戶下訂單用例的時序圖，它主要表達(dá)了一個復(fù)雜的業(yè)務(wù)，需要通過合理的抽象以及對業(yè)務(wù)變化的預(yù)見性，建立好合理的模型，并把職責(zé)合理的劃分到不同的服務(wù)或領(lǐng)域?qū)ο笾?，從而得到更好的靈活性或擴(kuò)展性，這也是領(lǐng)域驅(qū)動設(shè)計的核心思想。 基于這些特征，如果使用“充血模型”設(shè)計方法，就會出現(xiàn)一系列問題，下面以基礎(chǔ)房間的查詢作為例子來說明問題： 基礎(chǔ)房間查詢只需要返回一個符合查詢條件的基礎(chǔ)房間視圖列表 ，它包括的數(shù)據(jù)除了基礎(chǔ)房間的基本信息外，還包括基礎(chǔ)房間的樓棟名、分期名、樓盤名、朝向、景觀、開發(fā)商名等關(guān)聯(lián)信息，如果直接獲取領(lǐng)域?qū)ο笤俎D(zhuǎn)換成數(shù)據(jù)傳輸對象，由于領(lǐng)域?qū)ο髠}庫實現(xiàn)使用了 ORM 框架，返回的都是對象，那么，每個房間領(lǐng)域?qū)ο蟊仨氁祷仄湎嚓P(guān)聯(lián)的所有對象： c l a s s 公共部分基礎(chǔ)房間樓棟分期樓盤開發(fā)商景觀 朝向 圖表 基礎(chǔ)房間關(guān)聯(lián)對象類圖 而事實上，對于該查詢業(yè)務(wù)來說，它只需要這些關(guān)聯(lián)對象中的某一個或幾個屬性（如：分期對象的分期名稱），可以看到，使用加 載領(lǐng)域?qū)ο蟮姆绞接邢旅娴膯栴}： ? 加載了大量不必要的數(shù)據(jù)，嚴(yán)重浪費