架構應用之架構的工作是什麼？

如果把用戶需求看作是問題空間，那麼架構就是解空間，架構的目標就是要設計軟件系統來解決問題。架構其實就是結構設計，從抽象的角度，根據問題域，

架構設計從兩個面來考慮：1.功能需求，看架構設計是否能夠滿足業務需求。從需求模型轉化成架構模型需要關注兩個問題：如果根據需求模型構建架構模型，如何保證模型轉化的可追蹤性。2.非功能性需求，也是我們所關注的系統的質量屬性，如高性能，高可用，可擴展，安全性，可靠性等等。

架構設計流程

1）識別系統的複雜度

我們在設計架構時，首先就是要分析系統的複雜性，只有正確分析出系統的複雜性，後續的架構方案才不會偏離方向。例如，如果一個系統的複雜度本來是業務邏輯複雜，功能耦合嚴重，你卻設計一個TPS達到5萬/每秒的高性能架構，即使這個系統的最後的性能再優秀，也沒有說明意義。

軟件的複雜度來源有高性能，高可用，可擴展，低成本，安全，規模等。但架構師具體判斷複雜性的時候，不能隨意猜測，生搬硬套，必須結合具體的場景，像高性能，高可用等質量屬性，可以通過質量場景來捕獲。實際上絕大部分場景下，複雜度只是其中的某一個，少數情況下包含其中兩個。

架構理論上看，這裡說的複雜度，很像敏感點，為了實現某一質量屬性，一個或多個構件所共有的特徵。

目前我們碰到的大部分都是在原有系統上進行架構，當你碰到一個很多複雜度都存在問題的系統，該怎麼辦。當然是一個個來解決問題，將主要的複雜度問題列出來，根據業務，技術，團隊等情況進行排序，優先解決的當前面臨的最主要的複雜度問題。對於同一個複雜度問題，軟件系統的方案可以是多個的，總是可以挑選出性價比最高的那個。

2）設計備選方案

確定了系統主要面臨的複雜度問題後，方案設計就有了明確的目標。軟件技術經過幾十年的發展，雖然新技術層出不窮，但經過時間的發展，被各種場景驗證過的成熟技術也很多。高可用的主備方案，集群方案，高性能的負載均衡，多路複用，可擴展的分層，插件化等技術，我們可以根據已有的目標，查找現有的可選的成熟的解決方案。

基於已有的技術或架構模式進行組合，然後調整，大部分情況下就能夠得到我們需要的方案，但並不意味著架構設計是一件很簡單的事情。因為可選的模式有很多，組合的方案更多，往往一個問題的解決方案有很多個；如果在組合的方案上進行一些創新，那麼解決方案會更多。因此，如何設計最終的方案，並不是一件容易的事情。

我們在設計方案是，一定要避免只設計一個方案。通常我們在方案設計的時候，開始心裡都會有幾個方案的初步設想，再簡單的判斷一下哪個最好，然後就選擇這個自認為最好的方案進行詳細設計了。這樣做就非常危險了，心裡評估太過於簡單，考慮的還是太片面，會簡單的因為某一個缺陷就否決一個方案，但這世上本就不存在完美的架構。如果自己對某一知識點的理解不夠，可能原來理解就是錯的，會導致方案本身就是錯的。所以針對這些問題，我們在做方案設計的時候，一定設計備選方案，備選方案的數量選擇3-5個，備選方案的差異性要比較明顯（主備方案和集群方案都是保障高可用的）。

3）架構評估和選擇方案

完成備選方案設計之後，如何挑選最終的方案也是一個很大的挑戰，每個方案都是可行，每個方案都不是完美的，評價標準主觀性較強。在架構評估過程中，評估人員所關注的是系統的質量屬性。主要評估方法是SAAM和ATAM，通過列出我們所關注的質量屬性點，然後從這些質量屬性上去評估我們的方案。

SAAM —— 基於場景的架構分析方法

該方法是最早形成文檔並得到廣泛使用的軟件架構分析方法，對描述系統屬性的文檔，驗證基本的架構原則和假設。該方法有利於評估架構固有的風險，指導評估人員進行架構檢查，發現潛在的問題點。

1）使用場景技術，把任何形式的質量屬性都具體化為場景，

2）架構描述應該被所有參與評估的人所理解。功能，結構和分配作為描述架構的三個主要方面。

3）評估的5個步驟：場景開發，架構描述，單場景評估，場景交互，總體評估

這裡就一個方案設計舉例說明，該方案需要關注的架構質量屬性：

內容來自李雲華《從0開始學習架構》

通過場景開發，確定質量屬性：

第一，由於背景問題是系統性能不足，因此“性能”是首要考慮的架構質量屬性。由於業務快速發展，我們希望本次方案做完後，性能上至少能支撐接下來1 年內的業務發展。

第二，由於開發人員只有5 個人，因此複雜度和項目開發時間也是需要重點關注的，我們不希望一個方案需要做半年時間才能做完。

第三， 由於是創業公司， 目前還處於未盈利狀態，因此方案的成本也需要考慮。

第四，業務發展很快，各種新的功能不斷提出，產品經理希望我們的業務法代速度更快一些，因此係統需要能夠快速擴展新的功能。

第五，用戶量增長很快，系統如果故障影響比較大，因此係統的可用性也需要關注。

最終的質量屬性包括性能、複雜度、成本、可擴展、可用性。我們逐一對比兩個方案，擴展應用服務器的方案和系統功能拆分方案，如下表所示。

應用擴展方案和系統拆分方案對比

通過表格可以清楚的看到各個場景下各個方案的優劣點，但如何進行選擇的，不能簡單的根據哪個方案優勢大就選哪個。應該根據“按優先級選擇”，將質量屬性按照優先級排序，首先挑選滿足第一優先級的，如果方案都滿足，那就再看第二優先級……以此類推。

ATAM——體系結構權衡分析法

這是在SAAM的基礎上發展起來的，在系統開發前，對多個質量屬性之間進行評價和折中。考慮多個相互影響的質量屬性情況下，從原則上提供一種理解軟件架構的能力的方法。

主要劃分為4個活動領域：場景和需求收集，體系結構視圖和場景實現，屬性模型構造和分析，折中。

步驟：1.描述ATAM方法，2.描述業務動機，3.描述架構，4.確定架構方法，5.生成質量屬性效用樹，6.分析架構方法，7.討論場景和場景分級，8.分析架構方法，9.描述評估結果

4）詳細方案設計

詳細設計就是將方案設計的關鍵技術細節確定下來。

假如我們確定使用Elasticsearch 來做全文搜索，那麼就需要確定E lasticsearch 的索引是按照業務劃分，還是一個大索引就可以了：副本數量是2 個、3 個還是4 個，集群節點數量是3 個還是6 個等。

假如我們確定使用MySQL 分庫分表，那麼就需要確定哪些表要分庫分表，按照什麼維度來分庫分表，分庫分表後聯合查詢怎麼處理等。

假如我們確定引入Nginx 來做負載均衡，那麼Ngi nx 的主備怎麼做， Nginx 的負載均衡策略用哪個（權重分配？輪詢？ ip hash? ）等。

架構師不但要進行備選方案設計和選型，還需要對備選方案的關鍵細節有較深入的理解。避免在詳細設計的時候因為某個細節推翻整個方案的情況。通過分步驟、分階段、分系統等方式，儘量降低方案複雜度。

架構設計原則

1）合適原則

優秀的架構都是在企業當前人力、條件、業務等各種約束下設計出來的，能夠合理地將資源整合在一起井發揮出最大功效。

業界領先的方案雖然厲害，很牛*，但如果一個只有幾個人的團隊，想做一個微信或淘寶那樣的“億級用戶平臺”，可以想象最後的結果。沒有那麼多人力，沒有那麼大的業務量，沒有那麼長時間的技術積累，設計的架構再優秀再領先，也是無法實現的。

沒有必要為一個公司內部的OA系統設計一個百萬併發性能的架構，這些都屬於過度設計，架構設計只要合適就可以。

2）簡單原則

軟件領域的複雜性體現在以下兩個方面。

a.結構的複雜性

結構複雜的系統幾乎毫無例外地具備兩個特點： 組成複雜系統的組件數量更多，同時這些組件之間的關係也更加複雜。

結構上的複雜性存在的問題是： 1.組件越多，就越有可能其中某個組件出現故障，從而導致系統故障。2.某個組件改動，會影響關聯的所有組件，這些被影響的組件同樣會繼續遞歸影響更多的組件。3.定位一個複雜系統中的問題總是比簡單系統更加困難。

b.邏輯複雜性

邏輯複雜的組件一個典型特徵就是單個組件承擔了太多的功能。

看到結構複雜性後，我們的第一反應可能就是“降低組件數量”，畢竟組件數量越少，系統結構越簡單。最簡單的結構當然就是整個系統只有一個組件，即系統本身，所有的功能和邏輯都在這一個組件中實現。

邏輯複雜性帶來的維護和擴展的問題，線上出現問題後，很難定位。

無論結構的複雜性，還是邏輯的複雜性，都會存在各種問題，所以架構設計時如果簡單的方案和複雜的方案都可以滿足需求，一定要選擇簡單的方案。

3）演化原則

軟件架構需要根據業務發展不斷變化這個本質特點。

首先，設計出來的架構要滿足當時的業務需要。

其次，架構要不斷地在實際應用過程中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使得架構逐漸完善。

最後，當業務發生變化時，架構要擴展、重構、甚至重寫；代碼也許會重寫，但有價值的經驗、教訓 、邏輯、設計等卻可以在新架構中延續。

架構師在進行架構設計時時刻提醒自己不要貪大求全，或者盲目照搬大公司的做法，而是應該認真分析當前業務的特點，明確業務面臨的主要問題，設計合理的架構，快速落地以滿足業務需要，然後在運行過程中不斷完善架構，不斷隨著業務演化架構。

閱讀更多 有一天我會成功 的文章

關鍵字: 數據結構 技術 創業