鐵路售票系統(tǒng)架構評審文檔

1、鐵路售票系統(tǒng)架構評審文檔虛擬的一人多角色的評估小組，成員列表如下：表1：評估小組成員列表成員角色評估小組負責人、評估總結(jié)者、提問者、場景書記員、時間管理者評估負責人、提問者、架構設計師、提問者、進展書記員、數(shù)據(jù)收集人、提問者、領域?qū)＜摇①Y料員時間管理者、提問者、場景書記員、資料員目錄鐵路售票系統(tǒng)架構評審文檔1引言3編寫目的：3背景：3定義：3三層架構軟件設計3ATAM架構評審模式3參考資料：4第0階段：合作關系及準備工作4第1階段：評估階段5項目產(chǎn)品立項表述：5架構方法分類：5架構表述：6初步架構類圖：7質(zhì)量屬性及采用的戰(zhàn)術：7生成質(zhì)量屬性效用樹：8初步分析架構方法：9性能9可用性10安全性1

2、0戰(zhàn)術采用10第2階段：評估階段11集體討論并確定場景的優(yōu)先級：11再次分析架構方法：12三層結(jié)構選擇12LRU緩沖技術分析12MD5加密存儲分析12備份數(shù)據(jù)庫13改進架構類圖14結(jié)果表述14第3階段：后續(xù)階段14附錄15擬采用架構評審方法中的ATAM方法15引言編寫目的：本文檔的編寫目的是對鐵路售票系統(tǒng)架構設計進行簡略的評審，為后繼的詳細項目設計等工作提供參考和依據(jù)，本文檔主要描述的內(nèi)容有：l 表述l 調(diào)查和分析l 測試l 形成報告本文檔的預期讀者為：系統(tǒng)設計人員、測試人員、用戶及其它有權限查閱本文檔的相關人員。背景：l 系統(tǒng)名稱：鐵路售票系統(tǒng)l 任務提出者：黃東鵬、張付俊、孫帥l 開發(fā)者（

3、承接單位）：開發(fā)小組l 用戶：網(wǎng)上訂購鐵路車票的人定義：三層架構軟件設計所謂三層體系結(jié)構，是在客戶端與數(shù)據(jù)庫之間加入了一個中間件層，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結(jié)構，也不僅僅有B/S應用才是三層體系結(jié)構，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。三層體系的應用程序?qū)I(yè)務規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進行交換。ATAM架構評審模式1.概述Architecture Tradeoff Analysis

4、Method(構架權衡分析方法）。他是評價軟件構架的一種綜合全面的方法。這種方法不僅可以揭示出構架滿足特定質(zhì)量目標的情況，而且（因為它認識到了構架決策會影響多個質(zhì)量屬性）可以使我們更清楚地認識到質(zhì)量目標之間的聯(lián)系即如何權衡諸多質(zhì)量目標。ATAM評估方法的主要目的： 1) 提煉出軟件質(zhì)量屬性需求的精確描述； 2) 提煉出構架設計決策的精確描述； 3) 評估這些構架設計決策，并判定其是否令人滿意的實現(xiàn)了這些質(zhì)量需求。ATAM評估方法并非把每個可以量化的質(zhì)量屬性都進行詳盡的分析，而是使眾多的風險承擔者（包括經(jīng)理、開發(fā)人員、測試人員、用戶、客戶等等）都參與進來，由此而達到上述目標的。 ATAM是一種挖

5、掘潛在風險，降低或者緩和現(xiàn)有風險的軟件構架評估方法。因此，以下三點是評估中要特別注重的：風險、敏感點和權衡點。2構架涉眾 普通用戶、用戶管理員、票務管理員、開發(fā)人員、測試人員參考資料：Software ArchitectureinPractical（第三版）第0階段：合作關系及準備工作此次對項目的評估方法經(jīng)小組協(xié)商討論是采用ATAM架構評估綜合方法。待評估的項目系統(tǒng)為鐵路售票系統(tǒng)。這是一個基于B/S的體系的常見應用，基于網(wǎng)絡連接實現(xiàn)鐵路票務的相關業(yè)務。對其進行架構評估主要有如下幾個原因：1. 在架構搭建的過程中一定會碰見許多一致或者未知的問題和困難，如果在核心功能模塊或者架構本身的設計根本上出

6、現(xiàn)缺陷，盡早的發(fā)現(xiàn)對于晚發(fā)現(xiàn)，甚至完成項目后才發(fā)現(xiàn)的綜合成本要低得多；2. 由于該架構面向多個用戶多平臺，因此要有足夠的健壯性，穩(wěn)定性，可拓展性以及可修改性；3.由于該系統(tǒng)借助了網(wǎng)絡的傳播性，可以隨時隨地的對系統(tǒng)進行管理和維護，但是網(wǎng)絡的泛濫使得網(wǎng)絡環(huán)境總是充斥著有意無意的攻擊，為了避免系統(tǒng)所部屬的服務器淪為肉雞的下場，或者內(nèi)部數(shù)據(jù)被惡意破壞造成重大損失，所以系統(tǒng)應保證相對的安全性，使得入侵者所花費的入侵成本>入侵系統(tǒng)的獲利成本或客戶損失。第1階段：評估階段項目產(chǎn)品立項表述：隨著現(xiàn)代交通的發(fā)展，在基于經(jīng)濟以及便利的考慮基礎上，鐵路出行成為廣大人民首選的性價比最高的交通方式。但隨著經(jīng)濟的發(fā)

7、展，人工售票逐漸不能滿足龐大人口數(shù)量的基本購票需求。隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡購票的普及解決了這個主要矛盾。根據(jù)上述目標，質(zhì)量屬性可以劃分為兩類：1高優(yōu)先級質(zhì)量屬性：1) 性能2) 安全性3) 易用性4) 兼容性2重要但優(yōu)先級較低的屬性：1) 可擴展性2) 可維護性3) 可靠性4) 可擴充架構方法分類：進行了架構表述后，評估小組列出他們曾聽到的架構方法，以及那些在對文檔進行評估前的評審中所了解到的方法：一、 分層架構這種架構將軟件分成若干個水平曾，每一層都有清晰的角色和分工，不需要知道其他層的細節(jié)，層與層之間通過接口通信。二、 事件驅(qū)動架構事件是狀態(tài)發(fā)生變化時，軟件發(fā)出的通知。事件驅(qū)動架構就是通過

8、事件進行通信的軟件架構。分為：事件隊列、分發(fā)器、事件通道、事件處理器。三、 微核架構又稱為“插件架構”，指的是軟件的內(nèi)核相對較小，只要功能和業(yè)務邏輯都通過插件實現(xiàn)。內(nèi)核通常只包含系統(tǒng)運行的最小功能。插件則是相互獨立的，插件之間的通信，應該減少到最低，避免出現(xiàn)相互依賴的問題。四、 微服務架構是服務導向的架構的升級。每一個服務都是一個獨立的部署單元。這些單元都是分布式的，互相解耦，通過遠程通信協(xié)議聯(lián)系。五、 云架構云架構主要解決擴展性和并發(fā)問題，是最容易擴展的架構。它的高擴展，主要原因是沒使用中央數(shù)據(jù)庫，而是把數(shù)據(jù)都復制到內(nèi)存中，變成可復制的內(nèi)存數(shù)據(jù)單元。然后，業(yè)務處理能力封裝成一個個單元。比如訪

9、問量增加，就新建單元處理；訪問量減少，就關閉但處理單元。由于沒有中央數(shù)據(jù)庫，所以擴展性的最大瓶頸消失了。由于每個處理單元的數(shù)據(jù)都在內(nèi)存里，最好要進行數(shù)據(jù)持久化。這個模式主要分成兩部分：處理單元和虛擬中間件。架構表述：軟件架構是一系列相關的抽象模式，用于指導大型軟件系統(tǒng)各個方面的設計。軟件架構是一個系統(tǒng)的草圖。軟件體系結(jié)構是構建計算機軟件實踐的基礎?？紤]到票務系統(tǒng)的特點，將使用三層結(jié)構進行系統(tǒng)的架構。初步架構類圖：質(zhì)量屬性及采用的戰(zhàn)術：目標實現(xiàn)方式所采用戰(zhàn)術性能用戶訪問系統(tǒng)能在規(guī)定時間內(nèi)做出響應，如不能應反饋相應的提示。緩沖技術云服務器分流隊列等待安全性用戶信息不被泄露、支付安全信息加密易用性操

10、作難度讓系統(tǒng)能適應大部分群眾界面簡潔兼容性能在多平臺運行易移植編碼可維護性系統(tǒng)能在出現(xiàn)問題時得到及時修復，管理員能進行信息更新分層架構設計可擴展性在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇預留接口可擴充性在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇預留接口可靠性在程序的使用過程中出錯概率要盡量小，出錯了要能夠及時修復規(guī)范編碼生成質(zhì)量屬性效用樹：下表給出了在對鐵路售票系統(tǒng)評估期間生成的質(zhì)量屬性效用樹，有幾個質(zhì)量屬性求精沒有與之相關的場景。這種情況經(jīng)常出現(xiàn)，這并不是問題，對于某個質(zhì)量屬性，人們有時能夠想出一個合理的求精，但當讓他們在自己的系統(tǒng)的上下文中對該質(zhì)量屬性

11、的用例進行說明時，卻發(fā)現(xiàn)該求精實際上并不適用。表 2：對鐵路售票系統(tǒng)進行ATAM評估的效用樹表格質(zhì)量屬性屬性求精場景性能最大負載響應時間吞吐量當開票時，用戶量劇增，能夠同時負載至少500的用戶同時訪問（H,H）用戶輸入數(shù)據(jù)后在網(wǎng)絡暢通的情況下應能在s內(nèi)給出相關信息（H,M）日最高訂票量500萬張（按目前網(wǎng)絡訂票系統(tǒng)工作18小時算，每秒處理訂單量為78張）（H,H）安全性數(shù)據(jù)存儲注冊驗證登錄驗證密碼強度當用戶注冊時，系統(tǒng)將用戶的信息加密后存入數(shù)據(jù)庫；當用戶登錄時，系統(tǒng)將數(shù)據(jù)加密后再與數(shù)據(jù)庫的內(nèi)容進行比較，防止傳輸過程被竊取泄露。（H,L）當用戶注冊時,為確認為真人操作，存在手機信息驗證碼驗證，并

12、且60s內(nèi)不允許重復獲取驗證碼。（H,L）當用戶登錄時，連續(xù)輸入兩次錯誤密碼后，再次登錄需要根據(jù)系統(tǒng)給出圖片驗證碼輸入正確的驗證碼才能完成登錄，圖片驗證內(nèi)容隨機生成，并且隨機生成條紋遮擋字符，防止機器驗證。（H,L）當用戶注冊時系統(tǒng)根據(jù)用戶的密碼顯示相應的密碼強度以提示用戶增強密碼強度。密碼強度根據(jù)密碼內(nèi)容字符類型以及長度確定。為了確?；镜陌踩砸约胺乐褂脩暨z忘密碼，用戶密碼長度范圍限制為6-16位。（H,L）易用性用戶通過輸入簡單的查詢信息就能夠得到對應的相關數(shù)據(jù)并讓用戶輕易完成購買（H,M）兼容性多系統(tǒng)支持在相同平臺的不同系統(tǒng)上也能夠正常運行（H,H）可維護性管理員功能維護管理系統(tǒng)自動報

13、錯管理員能夠在鐵路信息、用戶信息需要更新時進行及時更新，并同步數(shù)據(jù)給用戶（H,M）當出現(xiàn)了不可避免的錯誤時，可以及時進行維護修復（H,M）可以定位出系統(tǒng)報錯內(nèi)容、報錯位置（M,L）可擴展性添加新功能在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇（M,L）可擴充性功能業(yè)務的子模塊隨著發(fā)展和意見的收集，能夠根據(jù)情況添加新的業(yè)務功能，如外賣預定（M,M）可靠性不易出錯在程序的使用過程中出錯概率要盡量小，出錯了要能夠及時修復（H,H）表中的場景給出了決策者所分配的優(yōu)先級。在每一對有序的字母中，第一個代表能力的重要性，第二個代表設計師對實現(xiàn)該質(zhì)量屬性的難度的估計。我們需要注意到，一些場景已

14、經(jīng)很完備了，具備了刺激、環(huán)境和響應三個部分；一些場景沒有刺激，還有一些場景沒有響應。在這個階段，只要涉眾能夠理解場景的含義，不明確的場景說明是允許的。如果所選擇的場景用于進行分析，那么該場景中的刺激和響應必須得到足夠的明確。初步分析架構方法：評估小組首先分析最重要而且最難實現(xiàn)的場景，每次分析一個最高優(yōu)先級的場景，同時我們的設計師詳細地解釋了構架如何支持每個場景。小組成員探查設計師用來實現(xiàn)場景的架構方法，把相關架構決策編成文檔，一共確定了個8敏感點，4個風險點，3個無風險決策。性能場景系統(tǒng)訪問量達到高峰屬性性能環(huán)境系統(tǒng)處于高峰訪問時期刺激用戶請求訪問響應良好響應請求架構決策敏感點權衡點有風險決策

15、無風險決策超出限制訪問量的請求放在等待S1R1緩存S2R2N1云服務器分流S3數(shù)據(jù)庫連接池S4N2推理1、 由于在系統(tǒng)部署的時候用的是單應用服務器，而一臺應用服務器可同時支持的并發(fā)用戶數(shù)量是很少的，在幾千甚至上萬的用戶訪問系統(tǒng)時，由于限制最大訪問量，不能保證每個用戶都能隨時登錄，降低用戶的滿意度。2、 單服務器提供的緩存數(shù)有限3、 避免了非法用戶的惡意攻擊，但有可能降低系統(tǒng)的可用性4、 減輕數(shù)據(jù)庫的負擔，提高系統(tǒng)的性能可用性場景系統(tǒng)備份與恢復屬性可用性環(huán)境系統(tǒng)發(fā)生錯誤刺激用戶進行恢復響應盡快恢復并未用戶提供有意義的反饋信息架構決策敏感點權衡點有風險決策無風險決策系統(tǒng)備份S5R3故障恢復S6R4

16、數(shù)據(jù)庫備份S7推理1、 系統(tǒng)備份是進行故障恢復的前提，但頻繁的備份會影響正常的業(yè)務處理，存在一定的風險2、 如果因為系統(tǒng)掉電或其他操作，利用備份數(shù)據(jù)可以很快恢復。但由于使用的是但服務器機制，一旦這臺服務器出現(xiàn)故障或者崩潰，硬件發(fā)生故障，系統(tǒng)的回復時間會很長，存在風險。安全性場景用戶信息傳輸屬性安全性環(huán)境信息泄露響應信息加密架構決策敏感點權衡點有風險決策無風險決策信息加密S8N3推理1、 信息可能在傳輸過程中被截獲2、 信息加密傳輸，并且以加密格式在數(shù)據(jù)庫中校對可以防止惡意獲取信息3、 信息加密不影響性能，還能提高信息的安全傳輸和數(shù)據(jù)庫安全戰(zhàn)術采用采用戰(zhàn)術敏感點（S）有風險決策（R）訪問量激增使

17、用LRU緩沖提高了系統(tǒng)的工作效率單服務器提供的緩存數(shù)目有限，并發(fā)用戶多的情況下，系統(tǒng)處理緩慢超出限制訪問量的請求放在等待隊列中提高了系統(tǒng)的穩(wěn)定性和可用性，減少了崩潰的可能會降低最大并發(fā)數(shù)目，使得用戶等待時間過場，可能造成用戶不滿云服務器分流分流訪問量，提高效率鎖機制解決多管理用戶同時訪問修改同一數(shù)據(jù)可能產(chǎn)生管理用戶長期占用資源，降低資源使用率備份數(shù)據(jù)庫防止數(shù)據(jù)庫物理性破壞數(shù)據(jù)庫連接池數(shù)據(jù)庫連接池允許應用程序重復使用一個現(xiàn)有的數(shù)據(jù)庫連接，而不再是重新建立一個，提高應用系統(tǒng)的性能系統(tǒng)備份與恢復增強系統(tǒng)的容錯能力操作系統(tǒng)和數(shù)據(jù)庫軟件發(fā)生崩潰時，回復時間較長MD5加密防止用戶信息泄露第2階段：評估階段

18、集體討論并確定場景的優(yōu)先級：下表給出了在本步驟中提出的某些部分感興趣場景進行重點分析。按重點次序羅列，由于篇幅有限，有些細微場景沒有列出，只列出了認為重要場景。表1：集體討論確定的場景場景號場景1為了防止軟件搶票，應在對一個相同的用戶的多次請求進行分析。如：驗證碼兩次輸入錯誤之間的之間間隔。當判定不是軟件搶票時，應當隨著驗證錯誤次數(shù)的增加降低驗證難度2用戶賬戶與付款的綁定、多種支付方式、以及安全性的要求。在保證安全性的前提下應該能夠讓用戶通過最簡潔的流程選擇自己合適的支付流程。3信息密傳輸4突然激增的流量導致服務器處理緩慢，甚至崩潰異常，要求對有害信息進行過濾，使用LRU緩沖計數(shù)減少服務器負擔

19、，增加服務器工作效率。5用戶訪問的相關車次查詢、買票、下訂單、付款、改簽、退款的流程應直觀、簡潔。6支持新車次添加、舊車次刪除、用戶信息修改操作等。7如果存在多個管理員時怎么并發(fā)管理系統(tǒng)，如果多個管理員對同一數(shù)據(jù)進行修改時應如何保護數(shù)據(jù)不被多次修改。這里考慮到參考鎖機制。再次分析架構方法：三層結(jié)構選擇由于票務數(shù)據(jù)以及用戶數(shù)據(jù)量龐大，而三層結(jié)構的特點將數(shù)據(jù)層、邏輯層以及表現(xiàn)層分隔開，在開發(fā)上降低了復雜度。并且考慮到系統(tǒng)的開發(fā)效率，三層結(jié)構使項目結(jié)構更清楚，分工更明確。考慮到用戶數(shù)量多，并且票務信息隨時都有可能發(fā)生變化，使用三層結(jié)構有利于后期的維護、更新和升級。并且數(shù)據(jù)的差異性大，將三層架構中的控

20、制層進行了細分，實現(xiàn)低耦合、并行開發(fā)。為解決訪問流量大的問題，服務器考慮使用LRU緩沖計數(shù)以提高服務器工作效率和改善用戶體驗。并且出于對大量用戶信息安全的角度考慮，數(shù)據(jù)的傳輸和校驗采用MD5加密方式。在集中的討論中，我們重點討論了上述問題的解決方案，考慮到時間和空間的限制，我們就第一二個詳細展開說明，以及分析和權衡。LRU緩沖技術分析比如說一些系統(tǒng)登錄的操作，不可能每次你訪問系統(tǒng)都去調(diào)用數(shù)據(jù)庫的東西，如果能劃出一些空間來，比如說500M，用來緩存這些東西，這樣用戶訪問的時候先在緩存里找，找不到，再去訪問數(shù)據(jù)庫，同時把被訪問的內(nèi)容放到緩存里面（我們可以假設這些東西還會經(jīng)常被訪問）。然而，我們分配

21、用來做緩存（Cache）的空間肯定是有限的，總不可能從數(shù)據(jù)庫讀的東西全部放到緩存里，所以，當緩存里的內(nèi)容達到上限值的時候，我們就要把最少使用的東西寫回數(shù)據(jù)庫，再將新的訪問內(nèi)容從數(shù)據(jù)庫暫存到緩存里面。以此保證服務端的效率和使用度。MD5加密存儲分析MD5將任意長度的“字節(jié)串”變換成一個128bit的大整數(shù)，并且它是一個不可逆的字符串變換算法，換句話說就是，即使你看到源程序和算法描述，也無法將一個MD5的值變換回原始的字符串，從數(shù)學原理上說，是因為原始的字符串有無窮多個，這有點象不存在反函數(shù)的數(shù)學函數(shù)。將客戶端的內(nèi)容數(shù)據(jù)進行加密后傳輸?shù)綌?shù)據(jù)庫進行校驗，這樣可以防止在傳輸過程中數(shù)據(jù)被盜取的安全性問題

22、。備份數(shù)據(jù)庫 由于存儲的數(shù)據(jù)信息內(nèi)容數(shù)量龐大，一旦服務器出現(xiàn)問題，數(shù)據(jù)丟失將會導致巨大的損失。所以在之前的部署上添加了備份數(shù)據(jù)庫，防止數(shù)據(jù)丟失。改進架構類圖結(jié)果表述(1) 由于開發(fā)人員對架構缺乏一定的熟練度，我們決定邊學邊做，碰見一些解決不了的問題采用在文檔中總結(jié)報告，記錄下來，優(yōu)先完成功能模塊的實現(xiàn)環(huán)節(jié)；(2) 平臺開發(fā)入門檻較低，產(chǎn)品容易被模仿，需要及時更新設計以擺脫競爭對手，所以應該預留系統(tǒng)API接口，為不管是以后管理方設計更改界面還是可以由用戶自定義開發(fā)界面都能起到良好的促進作用。第3階段：后續(xù)階段ATAM評估的一個具體結(jié)果就是生成了最終報告，該報告包括一個有風險決策、誤風險決策、敏感

23、點和權衡點的列表。還包括一個涉及如下內(nèi)容的目錄：所使用的架構方法、效用樹、經(jīng)過集體討論確定的場景以及所選擇的每個場景的分析記錄。最后，最終報告還包括由該評估小組所確定的風險主題的集合，并指出了每個風險主題所危及的商業(yè)動機。附錄擬采用架構評審方法中的ATAM方法對ATAM模型方法的簡略描述：軟件構架的評估方法：SAAM和ATAM。這里只詳細說明ATAM方法。ATAM一種進行構架評估的綜合方法，ATAM是評估軟件構架的一個健壯的方法。在該方法中，項目決策者和涉眾要清晰地闡述一個準確的質(zhì)量屬性需求列表（以場景的方式），并說明與實現(xiàn)每個高優(yōu)先場景相關的構架決策。然后，把這些決策確定為有風險決策或無風險決策，以找到構架中任何存在問題的地方。ATAM不是需求評估。ATAM不是代碼評估。ATAM不包括實際的系統(tǒng)測試。ATAM不是一個準確的手段，但它識別了構架中可能存在風