【正文】 要設計方案做完善和細化。說明書編制的目的是說明一個軟件系統(tǒng)各個層次中的每個程序（每個模塊或子程序）和數(shù)據(jù)庫系統(tǒng)的設計考慮，為程序員編碼提供依據(jù)。本文檔在概要設計的基礎上，進一步完整詳盡的描述了系統(tǒng)實現(xiàn)的技術細節(jié)，及根據(jù)業(yè)務需求制定的系統(tǒng)所需要實現(xiàn)的業(yè)務功能，功能模塊的詳細定義。 背景 參考資料 術語定義縮寫英中2. SaaS設計 多租戶模式 數(shù)據(jù)隔離l 將每個承租者的數(shù)據(jù)隔離到不同的數(shù)據(jù)庫。l 共享數(shù)據(jù)庫，MultiSchema，將每個承租者的數(shù)據(jù)隔離到獨立的表和模式。l 共享數(shù)據(jù)庫，ShareSchema，在所有承租者之間共享一組相同的表和模式。 實現(xiàn)多租戶的三種模式216。 無共享，完全獨立：每個租戶獨立使用一套應用程序和一個數(shù)據(jù)庫，應用與數(shù)據(jù)庫均不包含租戶信息，通過訪問入口路由到指定租戶的路徑上。n 優(yōu)點：u 無需修改原有應用程序跟數(shù)據(jù)庫。u 租戶間不會相互影響，可對個別租戶做自定義。n 缺點：u 部署跟運維相對繁瑣。u 物理設施資源開銷最大。u 無法對多租戶數(shù)據(jù)進行查詢歸并，存在數(shù)據(jù)孤島216。 共享應用，多數(shù)據(jù)源：使用同一套應用程序，數(shù)據(jù)庫訪問時根據(jù)租戶信息路由到指定數(shù)據(jù)庫或Schema上。n 優(yōu)點：兼顧了開發(fā)和性能。n 缺點：u 無法對多租戶數(shù)據(jù)進行查詢歸并，存在數(shù)據(jù)孤島216。 共享應用，單一數(shù)據(jù)源：使用同一套應用程序，使用同一個數(shù)據(jù)庫，數(shù)據(jù)模型中定義了租戶信息，通過過濾條件過濾租戶數(shù)據(jù)。n 優(yōu)點：性能最優(yōu)，部署簡便n 缺點：u 對系統(tǒng)架構和開發(fā)工程師要求較高，否則可能存在數(shù)據(jù)安全性問題u 運維復雜，當數(shù)據(jù)發(fā)生異常需要恢復時，無法簡單依賴數(shù)據(jù)庫的恢復機制，并將影響到多個租戶的數(shù)據(jù) 數(shù)據(jù)過濾在共享同一數(shù)據(jù)源的模式下，需要對每個數(shù)據(jù)查詢增加租戶信息的過濾條件；在單app環(huán)境下，一個用戶只對應一個租戶，通過登錄用戶信息即可獲得租戶信息，比較簡單。但是在平臺模式下，一個用戶可以租用多個app，用戶與租戶是一對多的情況。解決方案：用戶在登錄一個app時，app通過appKey去平臺獲取該用戶的信息，并在本地session中保存用戶登錄信息，平臺可以根據(jù)appKey與用戶ID獲得唯一的tenant，即app本地session中只需保存用戶對象與tenant對象一對一的關系。只有用戶在登錄平臺系統(tǒng)時才有一對多tenant的情況。 總結實際使用中可能綜合運用3種模式，即如果客戶較為重要，愿意為安全性、性能等額外付費，可部署為獨立模式。常規(guī)情況下則使用共享數(shù)據(jù)庫模式，但根據(jù)性能或部署需要，可能根據(jù)用戶數(shù)切分為多個domain，每個domain中的用戶共享一個數(shù)據(jù)庫，這樣如果某個domain失效，不會影響其他用戶的使用。但基本原則是所有數(shù)據(jù)表均按SaaS模式設計，以便實現(xiàn)不同模式下的切換。 定制化、個性化定制化指的是同一SaaS服務可以為不同用戶在相同基礎功能的基礎上提供一定程度的功能定制或強化，在不改動或盡量小改動服務的基礎上實現(xiàn)不同用戶的差異化功能性需求。如：數(shù)據(jù)模型的定制化，業(yè)務流程的定制化。個性化指的是為客戶提供的，滿足用戶企業(yè)或個人個性需要的非功能性需求，如國際化、主題、收藏夾、菜單結構調整、Logo或程序名調整、Dashboard等。 門戶、流程、智庫、社區(qū)注：所有方面，不僅是為了解決企業(yè)內部問題，更可以推向上下游，如企業(yè)門戶網(wǎng)站就是對外的，通過BPM可集成上下游的業(yè)務系統(tǒng)，實現(xiàn)供應鏈的業(yè)務流轉并最終實現(xiàn)E2E。智庫可以形成企業(yè)最佳實踐和解決方案，可以在行業(yè)中共享和推廣。社區(qū)更可以通過人與人之間的關系，加強企業(yè)間溝通。注2:4個類別，都是強調信息的匯聚、共享、傳播，通過SaaS模式可以實現(xiàn)這些方面的最大化，這是傳統(tǒng)單一企業(yè)內部信息化無法實現(xiàn)的。通過門戶來集成分散的功能，信息，提高用戶對關鍵信息的關注度，提高用戶對信息的獲取和處理效率。通過流程來組裝分散的業(yè)務，實現(xiàn)上下游業(yè)務的E2E一體化，提高業(yè)務協(xié)作能力，提高業(yè)務間信息共享，并最終提高企業(yè)整體業(yè)務的處理效率。（注：流程可能在某些環(huán)節(jié)的處理效率會比以前降低，但其目的是優(yōu)化整體效率）通過智庫來積累知識，沉淀企業(yè)智慧。知識的有效積累可推動企業(yè)業(yè)務流程重組和優(yōu)化，加強企業(yè)文化建設，提高員工凝聚力。社區(qū)是強調企業(yè)人與人之間的溝通，有別于上面三項都是以企業(yè)運營為目的的。 這個待定 MetadataDB元數(shù)據(jù)數(shù)據(jù)庫，定義了多租戶相關信息，用于租戶信息管理，作為基礎的公共服務獨立于業(yè)務系統(tǒng)數(shù)據(jù)庫。 系統(tǒng)用戶角色 租戶擁有者租用app的用戶，作為app的擁有者，其擁有app的所有功能模塊使用權限；同時作為擁有者，可以對app進行續(xù)費、升級、停用等操作。此外作為app的第一個默認用戶，也是默認的租戶管理員（租戶開通時默認創(chuàng)建），具有租戶“系統(tǒng)管理”模塊的功能權限，可以在租用范圍內創(chuàng)建角色，邀請其他用戶加入，分配權限。 租戶管理員租戶擁有者出于管理角度考慮（如租戶擁有者是老板，但是管理員是IT管理員），可以將租戶中的任意用戶提升為系統(tǒng)管理員，由其作為租戶管理員協(xié)助或負責租戶內相應的管理工作，如用戶管理，角色管理，功能權限分配，邀請用戶加入等。租戶管理員在權限上與租戶擁有者一致，但租戶擁有者作為最高級別，可隨時將租戶管理員降級成普通用戶；而反之則不行。 租戶成員租戶開通后，默認只有擁有者一個成員，此時擁有者可通過邀請方式請求其他用戶加入到該租戶中共同使用租用的app。如：老板租用了CRM系統(tǒng)，邀請公司內部員工加入到該系統(tǒng)中，員工即可使用CRM系統(tǒng)的功能，并在租戶范圍內共享數(shù)據(jù)。用戶在加入一個租戶后，需要租戶管理員為其開通相應功能模塊的使用權限（通過設置角色），否則只能共享【個人事務】中公開部分的數(shù)據(jù)。 客戶用戶角色 系統(tǒng)管理員（內部）管理系統(tǒng)用戶、角色與權限，保證系統(tǒng)正常運行。 高管（內部）審查客戶貢獻數(shù)據(jù)、客戶構成數(shù)據(jù)、客戶服務構成數(shù)據(jù)和客戶流失數(shù)據(jù)。 客戶經(jīng)理（內部）維護負責的客戶信息。接受客戶服務請求，在系統(tǒng)中創(chuàng)建客戶服務。處理分派給自己的客戶服務。對處理的服務進行反饋。創(chuàng)建銷售機會。對特定銷售機會制定客戶開發(fā)計劃。執(zhí)行客戶開發(fā)計劃。對負責的流失客戶采取“暫緩流失”或“確定流失”的措施 銷售主管（內部）對客戶服務進行分配。創(chuàng)建銷售機會。對銷售機會進行指派。對特定銷售機會制定客戶開發(fā)計劃。分析客戶貢獻、客戶構成、客戶服務構成和客戶流失數(shù)據(jù)，定期提交客戶管理報告。 銷售人員（內部）接受銷售任務，負責與客戶接觸，實施銷售任務，跟蹤客戶消費。 合作伙伴（外部）部分數(shù)據(jù)交互，并提供合作伙伴關心的數(shù)據(jù)，可由合作伙伴自行訪問（SelfService）。 供應商（外部）部分數(shù)據(jù)交互，并提供供應商關心的數(shù)據(jù)，可由供應商自行訪問（SelfService）。 客戶（外部）提供客戶關心的數(shù)據(jù)，可由客戶自行訪問查詢（SelfService） 身份驗證與授權身份驗證和授權是現(xiàn)實應用程序的安全性概念中主要的兩個：l 身份驗證允許一個應用程序在連接時驗證一個人（或一個應用程序、智能卡等）是否與它聲明的一樣。l 授權定義一個用戶在一個系統(tǒng)上的權利與權限。用戶身份驗證通過之后，授權會決定該用戶在系統(tǒng)上有權做什么。因此，授權應該發(fā)生在身份驗證之后。身份驗證和授權在 SaaS 應用程序中很復雜。在一個安全性 SaaS 解決方案中，底層的身份驗證和授權基礎設施有兩種設計方法：集中式或聯(lián)邦式。 授權模式黑盒模式：即簡化的權限模型，不開放授權功能給用戶，角色和權限由系統(tǒng)內置，用戶在加入App時自動綁定角色，對于一個App來說通常有：創(chuàng)建人，管理員和普通成員3個角色。白盒模式：即允許用戶授權，App創(chuàng)建人可在自行創(chuàng)建用戶組和角色，并對每個功能模塊進行細分授權。該模式可實現(xiàn)更精細的權限控制，類似傳統(tǒng)的企業(yè)應用。 可擴展性 基礎設施可擴展性l 計算資源快速供給l 應用快速部署l 資源按需分配l 自動化管理 應用架構可擴展性l 應用服務器水平擴展l 數(shù)據(jù)庫水平擴展n MySQL Sharding（）l 異步消息隊列l(wèi) 緩存機制l 負載均衡l 流程可定制l 功能可配置 數(shù)據(jù)權限對于前臺數(shù)據(jù)查詢，通過定義數(shù)據(jù)級權限實現(xiàn)動態(tài)表格內容輸出，不同角色的用戶將看到不同列的表格及經(jīng)過過濾的數(shù)據(jù)內容。216。 按角色定義哪些數(shù)據(jù)項可以呈現(xiàn)，并能調整列呈現(xiàn)的順序；216。 按角色定義過濾條件，實現(xiàn)基礎數(shù)據(jù)的過濾； 參數(shù)字典參數(shù)字典分“參數(shù)類型表”和“參數(shù)字典表”。參數(shù)類型表定義不同類型的業(yè)務參數(shù)，如用戶類型、公告類型等。每個類型又可分為：1 – 不可修改，2 – 可增加，3 – 可修改，4 – 可刪除4種。如公告類型，可被定義為“可增加”類型的，即公告類型可以增加，但不能被修改或刪除。參數(shù)類型表另外用狀態(tài)字段定義：1 – 正常，2 – 屏蔽，9 – 系統(tǒng)。對于某些業(yè)務需要，不需要用到的參數(shù)，可設置成屏蔽，即在業(yè)務系統(tǒng)中將無法使用該參數(shù)；對于狀態(tài)為系統(tǒng)的，則不能進行此項操作。參數(shù)字典表為明細表，對參數(shù)類型定義業(yè)務參數(shù)，如公告類型可分為：1 – 公告，2 – 新聞，3 – 通知，4 – 緊急通知等，由于公告類型為可增加類型，故可在此基礎上進行增加，但一旦使用過的公告，則不能進行修改或刪除了。對某個業(yè)務參數(shù)細項，又有3種狀態(tài)：1 – 正常，2 – 屏蔽，9 – 系統(tǒng)。由于業(yè)務需要可暫時屏蔽某些業(yè)務參數(shù)；但對于狀態(tài)為系統(tǒng)的則不能進行此項操作 日志記錄日志按照類型分：操作日志、業(yè)務日志、系統(tǒng)日志。不同類型的日志有其相應的處理邏輯及具體實現(xiàn)，以下分別說明。操作日志：記錄操作員登錄后執(zhí)行的相關操作。（目前只對更新數(shù)據(jù)庫的操作記日志，查詢不記錄）業(yè)務日志：記錄業(yè)務處理信息，如轉賬時金額的變動數(shù)額等。系統(tǒng)日志：記錄系統(tǒng)日常運行時的行為日志，目前采用通用的日志框架，以手工編碼的形式記錄操作日志同具體的業(yè)務應該是相互分離的，不在同一個事務中，及無論業(yè)務操作是否成功，都將記錄用戶操作。而業(yè)務日志記錄業(yè)務的詳細信息，應作為業(yè)務的一部分，與業(yè)務存在同一個事務中。因此操作日志一般在控制層編寫，而業(yè)務日志一般在業(yè)務層編寫。注：可通過注解+攔截器模式提供非入侵的操作日志記錄；而業(yè)務日志一般只能編碼實現(xiàn)。操作日志模型屬性名稱類型備注busiType業(yè)務類型int0 未指定1 保存2 更新3 刪除4 查看5 查詢6 審核...moduleCode模塊編號String對所有功能模塊，都有唯一對應的編號，如“系統(tǒng)配置”對應“SYS001”opId操作員IDLongopName操作員名稱String冗余數(shù)據(jù)，這樣就不需要關聯(lián)操作員表了opIp執(zhí)行操作的IPStringopDatetime操作時間Date數(shù)據(jù)庫默認content操作內容String具體操作內容描述status操作狀態(tài)int0 失敗1 成功 業(yè)務日志業(yè)務日志需要記錄詳細的業(yè)務數(shù)據(jù)變化，無法使用Annotation在方法級進行攔截，需要硬編碼實現(xiàn)?？紤]到一定的通用性，我們采用基于事件(Event)的日志模式，即在日志模塊中通過訂閱操作事件（OpEvent）獲得業(yè)務模塊發(fā)布的業(yè)務事件，再通過模板消息將業(yè)務參數(shù)格式化成操作詳情。需要記錄業(yè)務操作日志的，在業(yè)務執(zhí)行完后通過EventBus發(fā)布繼承于BaseOpEvent的事件對象，操作日志模塊統(tǒng)一訂閱該事件并統(tǒng)一轉換存儲。發(fā)布事件代碼示例：說明：業(yè)務操作的名稱將通過國際化轉換成對應用戶語言，國際化KEY命名規(guī)則：[模塊編號].func.[功能編號]；日志詳情基于動態(tài)參數(shù)格式化，因此需要將必要的屬性作為事件的動態(tài)參數(shù)傳入，國際化KEY命名規(guī)則：[模塊編號].func.[功能編號].log。由于某些日志詳情需要生成HTML的超鏈，依賴contextPath，因此約定contextPath將作為默認0位傳參傳入，業(yè)務參數(shù)在參數(shù)數(shù)組中的位置從1開始，如下面事件中mentId的位置為{1}。 個性化 界面?zhèn)€性化用戶可在一定程度上對界面做定制化，如使用個性化主題，個性化布局，可自行調整菜單結構等。 系統(tǒng)菜單可配置性菜單對不同的租戶來說，可能有不完全一樣的名字。例如客戶管理，在醫(yī)院使用時，就得改成病人管理，客戶服務人員就得改成醫(yī)生，客戶服務記錄就是就診記錄等。另外菜單的層次結構和分布，不同的租戶可能也會有不同的要求。在設計上需要考慮以下幾個問題：216。 一個租戶一套菜單；216。 一個菜單可以關聯(lián)一個子功能；216。 組織成樹型結構，構成上下級菜單結構；216。 同級菜單之間還存在顯示順序的問題 頁面元素可配置性各功能界面上的內容也是供用戶和系統(tǒng)交互的界面元素。不同的租戶可能有各種不同的需求。由于租戶可以自定義擴展數(shù)據(jù)，這些數(shù)據(jù)是需要在頁面上展示的，因此無論對頁面元素的個數(shù)、位置、順序，還是元素的含義，租戶都會有一些個性化的需求。同時對于在設計時設定的界面元素，一般情況下是不允許刪除的，但有時候還是允許租戶將一些無關緊要的字段隱藏。 數(shù)據(jù)個性化在實際應用中，不同租戶之間需求的差異導致系統(tǒng)需要針對不同租戶保存許多擴展性數(shù)據(jù)。在傳統(tǒng)應用中，可以通過定制實例，增加客戶的擴展數(shù)據(jù)，來滿足其個性化要求。在多租戶SaaS應用中，所有租戶都使用同一個數(shù)據(jù)架構，常見的解決辦法就是實現(xiàn)擴展數(shù)據(jù)的可配置。名稱值對的方式將擴展數(shù)據(jù)的保存和原數(shù)據(jù)表分