軟體的架構設計的重要性就不多說了，採用錯誤的架構，無論軟體的功能多麼豐富，使用者介面多麼友好，都逃脫不了失敗的命運，就像一棟用竹子搭起來的大樓骨架，外立面不管做的多漂亮，都注定在風雨中飄搖。關於如何設計架構，有很多大師都做了深入的闡述，我在這裡就不再贅述，本文是我在多年的軟體研發中對架構設計的一些思考，關注點放在架構的輸入包含哪些資訊，以及如何驗證架構的有效性上。
架構從**來的？
溫昱的架構設計裡面有一句話「需求入架構出」，我非常贊同。架構設計的目標就是為了實現需求，所以度量架構好壞的唯一標準就是是否更好地滿足需求，這裡用「更」字的原因是架構要滿足的需求有n多條，最終的架構決策是權衡的結果，所以我們無法找到最好的架構方案。
圖1：架構的輸入
在開始做架構設計的時候，我們能得到的顯性的輸入就是需求規格說明書，但這不意味軟體需求是唯一的考量依據。比如很多軟體產品採用的ssh的原因是這是業界用的比較多，相對成熟的方案，同時熟悉相關技術的開發人員比較多，學習成本比較低，這些因素和需求的關係不大，更多的考慮的是使用業界的慣例，降低架構成本以及技術風險。
軟體需求通常包括兩部分的內容，功能需求和非功能需求，其中對軟體架構影響比較大的是非功能需求部分，包括效能需求，可靠性需求，可維護性需求等等。比如參與過乙個產品，該產品的外部介面非常多，而且介面以及相關的業務非常複雜，對可維護性的要求非常高，所以架構設計的時候對配置的管理設定了**配置，第一級配置負責對介面插拔的配置，二級配置負責模組內的配置，**配置用於對二次開發介面的管理。這是可維護性需求影響架構設計的乙個案例，其他的還有很多，特別是效能需求的考慮在很多架構設計中都是放在比較重要的位置，我聽說過和經歷過的很多失敗產品都是因為效能問題而擱淺。很多做企業應用的軟體產品在上線前甚至都沒有做過一輪壓力測試和穩定性測試，最終上線後幾十個併發訪問都支撐不住，而盲目地通過硬體擴容以及負載均衡，不僅增加了額外的產品成本，還常常造成產品大比例延期。
架構風格往往隱喻架構團隊對軟體資料處理方式的理解，比如架構團隊認為軟體資料的加工是按照線性逐步做的，架構風格可以採用管道方式來做，比如unix命令輸入輸出系統，還有我們最常用的工作流都是典型的管道風格。
架構風格通過隱式的影響架構設計的形成，架構風格的**一般和組織的經驗資源積累有密切的關係，比如主架構師的偏好，組織的歷史產品採用的成熟架構方案，或者是業界比較常用的設計方案等等。業界特別是中小軟體企業中架構風格在架構方案中的重要性甚至超出了需求，據我所知，很多軟體產品的需求還沒有整理明白，領導已經拍板選擇什麼架構，採用的架構通常是已經在其它產品中成功使用的，或者企業在該架構投入了不少資源。比如公司用webservice介面封裝了大量的通用元件，那麼領導更有可能選擇soa相關的軟體架構，復用現有元件，而不是再造輪子，採用新架構重頭做全新的產品。
關鍵技術的出現對架構的選型也非常重要。比如在分布式計算領域，架構思路從原來的以四層交換機為代表的硬體負載均衡，到squid提供的軟體負載均衡，從網格計算的mpi到雲計算的hadoop，每一步前進背後的都能看到新技術的背影。大資料處理的處理上，傳統的做法是共享資料庫，對資料分塊分而治之，而在hadoop出現之後，大家突然發現用map-reduce的方式能夠更好地對大資料進行分片處理，方案不僅更容易在細粒度控制計算，而且方案更加優雅。
如何驗證架構方案的有效性？
乙個好的架構方案不在於它的ppt或者設計流圖畫的多麼的美觀大方，而在於如何滿足產品的實際需要，好的方案要經得起實踐的驗證。對於架構的評估方法，業界也有很多技術，比如要素評估法等等，不過有點遺憾的是曲高者和寡，縝密的評估策略，複雜的操作流程，阻礙了架構評估技術的應用，很多產品的架構設計評估往往停留在頭腦風暴式的評審，這種評審能高效率地發現文件中錯別字，卻未必能夠找到方案中深層次的缺陷。
圖2：架構方案的驗證
通常乙個產品的架構可選方案有多個，當然，假如你的產品架構方案只有乙個，那只能說明在架構設計方面沒有足夠的重視，在預研上投入的資源還遠遠不夠。對架構方案的評估需要經過三道關口，分別是業務可行性評估，技術可行性評估以及商務可行性評估。業務可行性評估的目標是判斷可選的架構方案是否能否滿足軟體的功能需求，技術可行性驗證是為了確定在既定的基礎設施條件下方案的實現是否有可用的技術手段和工具，商務可行性評估的核心是成本估算，同時還包括實施週期對商業目標的影響，以及潛在的使用者偏好等。
之所以把業務可行性驗證放在最開始的位置，原因有兩個，第一是功能需求是產品成立的基礎要求，如果連功能都滿足不了，那這個方案也就沒有討論的必要了。第二個是業務場景驗證的成本最小，適用於從大量的的頭腦風暴式方案中選擇出若干有價值的備選方案。
業務可行性評估的方法主要是業務場景驗證。把使用者需求中的業務場景抽出來，花上幾天的時間，模擬該業務場景在架構方案上的處理過程，看該方案是否能否滿足業務的需要。
這個階段的驗證是否有效取決於兩個方面，第一是對業務場景的理解，就是客戶需求中的場景和實際的業務場景的偏差有多大。如果使用者驗證架構的場景沒有典型性，或者收集的場景不完整，或者誤解了使用者的意圖，都會造成業務場景覆蓋驗證的效果下降。第二個是場景覆蓋的仔細程度，如果只是大略地做覆蓋很可能發現不了問題。場景覆蓋的目標除了驗證方案的可行，同時也是在評估架構中模組劃分的合理性。常常能在業務覆蓋過程中發現，這裡有一塊功能沒有覆蓋到，需要增加；那裡有乙個模組的功能過於複雜，需要再次拆分。
業務可行性評估既把不合理的方案排除掉，還需要把各個不同的方案中的優秀的部分融合到一起，取長補短，甚至有時間會在過程中產生全新的方案。所以評估不僅僅是過濾，更多地是不斷地思想碰撞產生新的思路，又不斷地否定方案中的不合理成份，持續迭代的乙個過程，同時這句話對於下面的兩個評估過程同樣有效。
技術驗證的重點在於非功能需求，以及演算法可行性的驗證。假如乙個專案要求系統支援200個使用者的併發訪問，那我們至少需要在三個關鍵點驗證方案，第乙個關鍵點是使用的web容器，如果方案擬採用websphere，我們經過驗證發現單容器的併發訪問只有50個，那可以首先排除單web容器的方案。第二個關鍵點是的最大併發連線數，那麼第三個就是方案中的業務邏輯層是否存在以及如何處理資源競爭訪問問題。這只是乙個效能需求的例子，非功能需求可能有很多，而且越是複雜的專案，架構驗證的工作量就成倍增加，但是我們仍然需要在架構評估階段投入足夠的精力和耐心，忽略其中任何一條，都有可能為後續埋下乙個定時炸彈，給專案帶來難以估量的損失。乙個成熟的軟體專案中設計的工作量往往超過編碼加上單元測試的工作量，而很多不成熟的專案中設計的工作量幾乎可以忽略不計，但往往後者的週期遠遠超過前者，主要的原因就在於不成熟的設計被迫把設計中節省工作量的五倍甚至十倍投入到功能的除錯甚至返工上，一句話「出來混，總是要連本帶利還的」。
商業評估的重點在於成本收益分析，以及相關的市場考慮。軟體專案的成本主要有三塊，一塊是銷售費用，第二塊是人力成本（包括薪酬，獎金，出差補貼等），另外一塊是採購成本。其中第二塊和最後一塊是和研發密切相關的。過多的工作量投入，以及高昂的外購都會侵蝕專案的利潤。工作量的投入調整，常用的手段是：1，調整專案的交付範圍，不過這常常會遭到客戶的反對。2，安排加班計畫，提高個人的日常工作負荷來縮短交付時間。3，調整研發團隊的結構，增加經驗豐富的工程師在團隊中所佔的比重，提公升工作效率。4，非核心業務外包。調整外購投入的方法一般有：1，縮小採購規模，尋找低成本的替代品，比如用開源的tomcat代替websphere,用hp的安騰代替oracle的一體機。2，資源利舊，復用原有的資源，比如基於原有的硬體資源組裝成集群節省採購新硬體的投入，復用其他產品的模組或者元件等。3，財務分攤，產品的架構設計，產品模組甚至產品自身，以及採購的硬體可以復用到商業專案中，所以對可復用的資源分攤到其他的專案中，減少對首個應用專案的財務成本壓力。
有時候使用者的偏好也會對架構的選型起到重要的影響，特別是在事業單位的軟體專案，可能對系統使用技術的是否先進有很濃厚的興趣。比如使用者要求必須支援b/s技術，或者要求使用ria獲得更炫目的視覺效果，這些都會影響對架構方案的選型。
從煉獄中走出，關於架構設計
有點像標題黨，其實沒這麼恐怖。但對於做構架設計，我想很多人也有這樣的感受，在過程中有時就像進入煉獄，備受煎熬。而當把所面對的問題基本梳理清楚，或者架構基本完成時，有如走出了煉獄。要讓框架成為使用者很好的幫手，對於開發者來說，進出煉獄其實也是正常的。本文主要聊一些框架設計的原則，這就當成原則的第0條。...
對話 關於架構 設計與需求
2007年10月22日 10 12 00 wwe wwe 我這幾年的大部分工作也是偏重架構設計 aim 有什麼感想呢？wwe 個人覺得架構設計就像生活中的一部分 aim en.這個怎麼講？wwe 架構設計就像規劃你的生活一樣，都想把它變好 變美 aim 但是，你也應該知道。會有很多人 很多因素讓生活...
對話 關於架構 設計與需求
wwe wwe 我這幾年的大部分工作也是偏重架構設計 aim 有什麼感想呢？wwe 個人覺得架構設計就像生活中的一部分 aim en.這個怎麼講？wwe 架構設計就像規劃你的生活一樣，都想把它變好 變美 aim 但是，你也應該知道。會有很多人 很多因素讓生活變得不美好。wwe 當然 wwe 但有乙個...