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

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

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

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

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

6、盡早的發現對于晚發現，甚至完成工程后才發現的綜合本錢要低得多；2. 由于該架構面向多個用戶多平臺，因此要有足夠的健壯性，穩定性，可拓展性以及可修改性；3.由于該系統借助了網絡的傳播性，可以隨時隨地的對系統進行管理和維護，但是網絡的泛濫使得網絡環境總是充滿著有意無意的攻擊，為了防止系統所部屬的效勞器淪為肉雞的下場，或者內部數據被惡意破壞造成重大損失，所以系統應保證相對的平安性，使得入侵者所花費的入侵本錢>入侵系統的獲利本錢或客戶損失。第1階段：評估階段工程產品立項表述：隨著現代交通的開展，在基于經濟以及便利的考慮根底上，鐵路出行成為廣闊人民首選的性價比最高的交通方式。但隨著經濟的開展，人工

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

8、行通信的軟件架構。分為：事件隊列、分發器、事件通道、事件處理器。三、 微核架構又稱為“插件架構，指的是軟件的內核相對較小，只要功能和業務邏輯都通過插件實現。內核通常只包含系統運行的最小功能。插件那么是相互獨立的，插件之間的通信，應該減少到最低，防止出現相互依賴的問題。四、 微效勞架構是效勞導向的架構的升級。每一個效勞都是一個獨立的部署單元。這些單元都是分布式的，互相解耦，通過遠程通信協議聯系。五、 云架構云架構主要解決擴展性和并發問題，是最容易擴展的架構。它的高擴展，主要原因是沒使用中央數據庫，而是把數據都復制到內存中，變成可復制的內存數據單元。然后，業務處理能力封裝成一個個單元。比方訪問量增

9、加，就新建單元處理；訪問量減少，就關閉但處理單元。由于沒有中央數據庫，所以擴展性的最大瓶頸消失了。由于每個處理單元的數據都在內存里，最好要進行數據持久化。這個模式主要分成兩局部：處理單元和虛擬中間件。架構表述：軟件架構是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件體系結構是構建計算機軟件實踐的根底。考慮到票務系統的特點，將使用三層結構進行系統的架構。初步架構類圖：質量屬性及采用的戰術：目標實現方式所采用戰術性能用戶訪問系統能在規定時間內做出響應，如不能應反應相應的提示。緩沖技術云效勞器分流隊列等待平安性用戶信息不被泄露、支付平安信息加密易用性操作難度

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

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

12、碼。H,L當用戶登錄時，連續輸入兩次錯誤密碼后，再次登錄需要根據系統給出圖片驗證碼輸入正確的驗證碼才能完成登錄，圖片驗證內容隨機生成，并且隨機生成條紋遮擋字符，防止機器驗證。H,L當用戶注冊時系統根據用戶的密碼顯示相應的密碼強度以提示用戶增強密碼強度。密碼強度根據密碼內容字符類型以及長度確定。為了確保根本的平安性以及防止用戶遺忘密碼，用戶密碼長度范圍限制為6-16位。H,L易用性用戶通過輸入簡單的查詢信息就能夠得到對應的相關數據并讓用戶輕易完成購置H,M兼容性多系統支持在相同平臺的不同系統上也能夠正常運行H,H可維護性管理員功能維護管理系統自動報錯管理員能夠在鐵路信息、用戶信息需要更新時進行及

13、時更新，并同步數據給用戶H,M當出現了不可防止的錯誤時，可以及時進行維護修復H,M可以定位出系統報錯內容、報錯位置M,L可擴展性添加新功能在出現新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇M,L可擴充性功能業務的子模塊隨著開展和意見的收集，能夠根據情況添加新的業務功能，如外賣預定M,M可靠性不易出錯在程序的使用過程中出錯概率要盡量小，出錯了要能夠及時修復H,H表中的場景給出了決策者所分配的優先級。在每一對有序的字母中，第一個代表能力的重要性，第二個代表設計師對實現該質量屬性的難度的估計。我們需要注意到，一些場景已經很完備了，具備了刺激、環境和響應三個局部；一些場景沒有刺激，還有一些場

14、景沒有響應。在這個階段，只要涉眾能夠理解場景的含義，不明確的場景說明是允許的。如果所選擇的場景用于進行分析，那么該場景中的刺激和響應必須得到足夠的明確。初步分析架構方法：評估小組首先分析最重要而且最難實現的場景，每次分析一個最高優先級的場景，同時我們的設計師詳細地解釋了構架如何支持每個場景。小組成員探查設計師用來實現場景的架構方法，把相關架構決策編成文檔，一共確定了個8敏感點，4個風險點，3個無風險決策。性能場景系統訪問量到達頂峰屬性性能環境系統處于頂峰訪問時期刺激用戶請求訪問響應良好響應請求架構決策敏感點權衡點有風險決策無風險決策超出限制訪問量的請求放在等待S1R1緩存S2R2N1云效勞器分

15、流S3數據庫連接池S4N2推理1、 由于在系統部署的時候用的是單應用效勞器，而一臺應用效勞器可同時支持的并發用戶數量是很少的，在幾千甚至上萬的用戶訪問系統時，由于限制最大訪問量，不能保證每個用戶都能隨時登錄，降低用戶的滿意度。2、 單效勞器提供的緩存數有限3、 防止了非法用戶的惡意攻擊，但有可能降低系統的可用性4、 減輕數據庫的負擔，提高系統的性能可用性場景系統備份與恢復屬性可用性環境系統發生錯誤刺激用戶進行恢復響應盡快恢復并未用戶提供有意義的反應信息架構決策敏感點權衡點有風險決策無風險決策系統備份S5R3故障恢復S6R4數據庫備份S7推理1、 系統備份是進行故障恢復的前提，但頻繁的備份會影響

16、正常的業務處理，存在一定的風險2、 如果因為系統掉電或其他操作，利用備份數據可以很快恢復。但由于使用的是但效勞器機制，一旦這臺效勞器出現故障或者崩潰，硬件發生故障，系統的回復時間會很長，存在風險。平安性場景用戶信息傳輸屬性平安性環境信息泄露響應信息加密架構決策敏感點權衡點有風險決策無風險決策信息加密S8N3推理1、 信息可能在傳輸過程中被截獲2、 信息加密傳輸，并且以加密格式在數據庫中校對可以防止惡意獲取信息3、 信息加密不影響性能，還能提高信息的平安傳輸和數據庫平安戰術采用采用戰術敏感點S有風險決策R訪問量激增使用LRU緩沖提高了系統的工作效率單效勞器提供的緩存數目有限，并發用戶多的情況下，

17、系統處理緩慢超出限制訪問量的請求放在等待隊列中提高了系統的穩定性和可用性，減少了崩潰的可能會降低最大并發數目，使得用戶等待時間過場，可能造成用戶不滿云效勞器分流分流訪問量，提高效率鎖機制解決多管理用戶同時訪問修改同一數據可能產生管理用戶長期占用資源，降低資源使用率備份數據庫防止數據庫物理性破壞數據庫連接池數據庫連接池允許應用程序重復使用一個現有的數據庫連接，而不再是重新建立一個，提高應用系統的性能系統備份與恢復增強系統的容錯能力操作系統和數據庫軟件發生崩潰時，回復時間較長MD5加密防止用戶信息泄露第2階段：評估階段集體討論并確定場景的優先級：下表給出了在本步驟中提出的某些局部感興趣場景進行重點

18、分析。按重點次序羅列，由于篇幅有限，有些細微場景沒有列出，只列出了認為重要場景。表1：集體討論確定的場景場景號場景1為了防止軟件搶票，應在對一個相同的用戶的屢次請求進行分析。如：驗證碼兩次輸入錯誤之間的之間間隔。當判定不是軟件搶票時，應當隨著驗證錯誤次數的增加降低驗證難度2用戶賬戶與付款的綁定、多種支付方式、以及平安性的要求。在保證平安性的前提下應該能夠讓用戶通過最簡潔的流程選擇自己適宜的支付流程。3信息密傳輸4突然激增的流量導致效勞器處理緩慢，甚至崩潰異常，要求對有害信息進行過濾，使用LRU緩沖計數減少效勞器負擔，增加效勞器工作效率。5用戶訪問的相關車次查詢、買票、下訂單、付款、改簽、退款的

19、流程應直觀、簡潔。6支持新車次添加、舊車次刪除、用戶信息修改操作等。7如果存在多個管理員時怎么并發管理系統，如果多個管理員對同一數據進行修改時應如何保護數據不被屢次修改。這里考慮到參考鎖機制。再次分析架構方法：三層結構選擇由于票務數據以及用戶數據量龐大，而三層結構的特點將數據層、邏輯層以及表現層分隔開，在開發上降低了復雜度。并且考慮到系統的開發效率，三層結構使工程結構更清楚，分工更明確?？紤]到用戶數量多，并且票務信息隨時都有可能發生變化，使用三層結構有利于后期的維護、更新和升級。并且數據的差異性大，將三層架構中的控制層進行了細分，實現低耦合、并行開發。為解決訪問流量大的問題，效勞器考慮使用LR

20、U緩沖計數以提高效勞器工作效率和改善用戶體驗。并且出于對大量用戶信息平安的角度考慮，數據的傳輸和校驗采用MD5加密方式。在集中的討論中，我們重點討論了上述問題的解決方案，考慮到時間和空間的限制，我們就第一二個詳細展開說明，以及分析和權衡。LRU緩沖技術分析比方說一些系統登錄的操作，不可能每次你訪問系統都去調用數據庫的東西，如果能劃出一些空間來，比方說500M，用來緩存這些東西，這樣用戶訪問的時候先在緩存里找，找不到，再去訪問數據庫，同時把被訪問的內容放到緩存里面我們可以假設這些東西還會經常被訪問。然而，我們分配用來做緩存Cache的空間肯定是有限的，總不可能從數據庫讀的東西全部放到緩存里，所以

21、，當緩存里的內容到達上限值的時候，我們就要把最少使用的東西寫回數據庫，再將新的訪問內容從數據庫暫存到緩存里面。以此保證效勞端的效率和使用度。MD5加密存儲分析MD5將任意長度的“字節串變換成一個128bit的大整數，并且它是一個不可逆的字符串變換算法，換句話說就是，即使你看到源程序和算法描述，也無法將一個MD5的值變換回原始的字符串，從數學原理上說，是因為原始的字符串有無窮多個，這有點象不存在反函數的數學函數。將客戶端的內容數據進行加密后傳輸到數據庫進行校驗，這樣可以防止在傳輸過程中數據被盜取的平安性問題。備份數據庫 由于存儲的數據信息內容數量龐大，一旦效勞器出現問題，數據喪失將會導致巨大的損

22、失。所以在之前的部署上添加了備份數據庫，防止數據喪失。改良架構類圖結果表述(1) 由于開發人員對架構缺乏一定的熟練度，我們決定邊學邊做，碰見一些解決不了的問題采用在文檔中總結報告，記錄下來，優先完成功能模塊的實現環節；(2) 平臺開發入門檻較低，產品容易被模仿，需要及時更新設計以擺脫競爭對手，所以應該預留系統API接口，為不管是以后管理方設計更改界面還是可以由用戶自定義開發界面都能起到良好的促進作用。第3階段：后續階段ATAM評估的一個具體結果就是生成了最終報告，該報告包括一個有風險決策、誤風險決策、敏感點和權衡點的列表。還包括一個涉及如下內容的目錄：所使用的架構方法、效用樹、經過集體討論確定

23、的場景以及所選擇的每個場景的分析記錄。最后，最終報告還包括由該評估小組所確定的風險主題的集合，并指出了每個風險主題所危及的商業動機。附錄擬采用架構評審方法中的ATAM方法對ATAM模型方法的簡略描述：軟件構架的評估方法：SAAM和ATAM。這里只詳細說明ATAM方法。ATAM一種進行構架評估的綜合方法，ATAM是評估軟件構架的一個健壯的方法。在該方法中，工程決策者和涉眾要清晰地闡述一個準確的質量屬性需求列表以場景的方式，并說明與實現每個高優先場景相關的構架決策。然后，把這些決策確定為有風險決策或無風險決策，以找到構架中任何存在問題的地方。ATAM不是需求評估。ATAM不是代碼評估。ATAM不包括實際的系統測試。ATAM不是一個準確的手段，但它識