今天我主要說說架構設計流程，圍繞著這麽幾個方面來講?

(1)識別復雜度;

(2)設計備選方案;

(3)評估和選擇備選方案;

(4)詳細方案設計;

一、識別復雜度

在如下兩篇文章中，我闡述了六個復雜度來源。

文章分別為:架構設計之六個復雜度來源

架構設計之六個復雜度來源(續)

如果不了解架構設計的六個復雜度來源可以參考我的上述兩篇文章看看。

從軟件層面上來看，前面說過，架構設計的目的就是為了解決軟件系統的復雜度。所以我們在設計這個軟件的時候，首先需要做的就是分析系統的復雜性。只有正確分析出了系統的復雜性，後續的架構設計方案才不偏離方向，否則，如果對系統的復雜性判斷錯誤，即使後續的架構設計方案再完美再先進，都是南轅北轍，做的越好，錯的越多越離譜。

比如，如果一個系統的復雜度本來是業務邏輯太復雜，功能耦合嚴重，架構師卻設計了一個TPS達到50000/秒的高性能架構，即使這個架構最終的性能再優秀也沒有任何意義，因為架構沒有解決正確的復雜性問題。

針對諸如這樣的例子，我們正確的做法是:

將主要的復雜度問題列出來，然後根據業務、技術、團隊等綜合情況進行排序，優先解決當前面臨的最主要復雜度問題。

對於按照復雜度優先級排序解決的方式，存在一個普遍的擔憂:如果按照優先級來解決復雜度，可能會出現解決了優先級排在前面的復雜度後，解決後續復雜度的方案需要將已經落地的方案推倒重來。這個擔憂理論上是可能的，但現實中機會是不可能出現的，原因在於軟件系統的可塑性和易變性。對於同一個復雜度問題，軟件系統的方案可以有多個，總是可以挑出綜合來看性價比最高的方案。

即使架構師決定要推到重來，這個新的方案也必須能夠同時解決已經被解決的復雜度問題，一般來說，能夠達到這種理想狀態的方案基本都是依靠新技術的引入。例如，Hadoop能夠將高可用、高性能、大容量三個大數據處理的復雜問題同時解決。

識別復雜度對架構師來說是一項挑戰，因為原始的需要中並沒有哪個地方會明確地說明復雜度在哪裏，需要架構師在理解需求的基礎上進行分析。有經驗的架構師可能一看需求就知道復雜度大概在哪裏;如果經驗不足，那只能采用“排除法”，從不同的角度逐一進行分析。

二、設計備選方案

架構師在設計架構時，通常不能僅僅從一個角度上考慮，應該是從多個角度上看。從不同的角度可以衍生不同的備選方案。

目前業界有很多現成的解決方案，比如我們前面提到的OA方面，還有就是規則引擎，規則引擎除了Drools之外，還有OpenRules等。

雖然軟件技術經過幾十年的發展，新的技術層出不窮，經過時間考驗，已經被各種場景驗證過的成熟技術其實更多。例如，高可用的主備方案、集群方案、高性能的負載均衡、多路復用，可擴展的分層、插件化等技術，基本上只要我們有了明確的目標，基本上按圖索驥就可以找到可選的解決方案。

解決方案太多，讓人眼花繚亂，因為可選的實在是太多了，組合方案更多，往往一個問題的解決方案有很多個，如何設計最終的方案，並不是一件容易的事情，這個階段也是很多架構師容易犯錯的地方。

常見錯誤如下所示:

1.設計最優秀的解決方案

2.只做一個方案

3.備選方案過於詳細

關於“設計最優秀的解決方案”，我在前幾篇有關架構方面的文章中說過，任何架構都是由簡單到復雜，一步一步擴展，一步一步演化過來的。

包括最普通的方案變為最優秀的方案也是如此，就好比一個屌絲逆襲，屌絲逆襲成為高富帥，也是需要一個過程的。

關於“只做一個方案”，就好比今天貌似陽光明媚是一個很適合出門的日子，借此機會出去玩耍，比如去歡樂谷玩，但是很多項目要排隊，排隊是不可避免的，總不可能打道回府不玩了吧。

這就需要你心中有好幾個方案，比如路線方案、舍得方案。

路線方案是比如玩完激流勇進後可以順便玩下一些不是很刺激的小項目來段放松的插曲。

舍得方案是歡樂谷那麽多項目，休息日人肯定是非常多的，總不可能全部玩完吧(有的項目是有時間限制，比如極速飛車早上10點30到晚上6點之間這段時間才能玩，超過六點後就不能玩了)。

從出去玩這個大家都喜歡的生活方式考慮，只做一個方案是不行的，更何況軟件這種復雜多變的玩意呢。

關於“備選方案過於詳細”，如果一個兩個甚至三個還好，請問如果十幾個的話，架構師豈不是會累死，十幾個方案面面俱到，最後的結果可能是浪費了大量時間反而費力費時不討好。

一般備選方案遵循簡化話就好，當然了，也不能太簡單，還是得有點篇幅，不過這個篇幅不是寫作文那樣動不動至少800字。

三、評估和選擇備選方案

在完成備選方案設計後，如何挑選出最終的方案也是一個很大的挑戰，主要原因為如下三個方面:

(1)每個方案都是可行的，如果方案不可行就不應該作為備選方案;

(2)沒有哪個方案是完美的；

(3)評價標準主觀性比較強;

正是因為選擇備選方案存在這些困難，所以實踐中很多設計師或者架構師就采取了下面幾種指導思想：

(1)最簡派(柿子還是挑軟的捏);

(2)最牛派(一般傾向於使用非常牛逼的技術);

(3)最熟派(挑選自己以往設計方案最有經驗的);

(4)領導派(自己把握不準，列出好幾個方案，最後讓領導去決策，好的話，說明領導有遠見，自己設計也不錯，把握的很好，不好的話，這個背鍋任務就交給領導吧，反正當初是你挑的，不管我的事情，這種領導派顯得比較圓滑);

前面列出了幾種指導思想，真正應該選擇哪種方法來評估和選擇備選方案呢?李運華先生對此的觀點是:360度環評。

具體的操作方式是:列出我們需要關註的質量屬性點，然後分別從這些質量屬性的維度去評估每個方案，再綜合挑選適合當時情況的最優方案。

常見的方案質量屬性點分別是:

(1)性能;

(2)可用性;

(3)硬件成本;

(4)項目投入;

(5)復雜度;

(6)安全性;

(7)可擴展性;

舉例說明:

以智能酒店項目來說，首先對於上述七點都要求比較高，硬件成本，也很大，比如客控系統(客控系統主要是對酒店房間裏面的電腦、電視、空調、洗衣機、燈光亮度等由客戶自己在觸摸屏上調制或者關註小程序來調控)，客控系統硬件成本投入是比較大的，對於性能方面要求也很高，假設你這個系統性能不是特別好的話，通常對於用戶量少，造不成很大的影響，如果用戶量十分大，造成的將會是毀滅性打擊。智能酒店項目囊括比較廣，上述七點都要求很高。我僅僅只是挑出兩點來講。剩下的讀者可以自行結合自己的項目來比對。當然了，也可以去百度上找一些項目來研究研究，研究它的架構為什麽要這樣。以上面指導思想來看，並結合質量屬性點，你一定會發現不一樣的東西。

四、詳細方案設計

以瀑布模式為例，從側面反映出詳細方案設計的重要作用。

瀑布模式是這樣的:可行性方案分析->需求分析->概要設計->詳細設計->編碼->單元測試->測試->集成->運行維護。

其中詳細方案設計的目的在於精確化準確化，在瀑布模式中你可以理解為只要詳細設計做的好，程序員可以不過多的思考，就可以直接開始編碼了。

從架構上看，架構的詳細方案設計做不做的好，不僅僅對當下，還有對將來，如果你的架構詳細設計方案讓人家看的雲裏霧裏，那麽最後可能就像我前面說到過會造成毀滅性的打擊，這個打擊效果不是特別大的情況你可能需要重構一部分，如果很大的話，可能推到重來。這個推到重來，我在最初的pms的系統中就已經感觸很深了。借此機會，希望給大家一個警惕。

小結:

本文圍繞著識別復雜度、設計備選方案、評估和選擇備選方案、詳細方案設計等四個方面來講述架構設計流程，希望能給大家有一定的啟發並在實際開發或者設計中有一定的借鑒意義。

感謝李運華先生的專欄《從0開始學架構》，從中我還是學了不少東西。有一句我要闡述一下，舊書不厭百回讀，熟讀深思子自知。記得當初在校學編程的時候，我哥哥推薦了一本書叫《計算機文化》，書中涵蓋很多計算機理論基礎方面的知識，當時我沒有看也看不怎麽懂，後來有一天，我突然將其全部翻了一遍，感覺其實並不是那麽難懂難看，還是很有意思的，很多基礎方面的知識，你每抽點時間回頭看看，一定會有不一樣的啟發。比如你幹了五六年的Java回頭再看看《Java編程思想》，你會覺得書雖然厚點但是其實很薄。這是當初參加美團的技術沙龍，一位IT朋友對我說的。當然了，以我現在的情況下，讀讀《Java編程思想》還是有些吃力的。

此文部分內容參考李運華先生的《從0開始學架構》

架構設計流程