架構隨聊

　一、架構的定義

　　所謂一千個架構師中有一千種“最好的架構”模式。

　　“架構”是我們這行業種一個很常見的詞，表明其必然也是經歷了很長的歲月打磨所形成的一個詞。架構的這個詞出現的意義是什麼？為了解決什麼問題？只有把這2個問題想明白了，才能設計出一個良好的專案架構。

　　我認為 架構類似於畫房屋設計圖，在剛開始我們蓋一層樓的小房子的時候，拍拍腦門想一下，腦子裡有個大概的樣子就開始動工了，想怎麼蓋就怎麼蓋，大部分情況下也都不會出現。但是當你要蓋一個大樓，這時候拍拍腦門的方式雖然有可能還能管用，但是由於沒有經過深思熟慮的多方考量，建造出來的必然是問題重重。另外建造大樓和蓋個一層樓的小屋所需的團隊規模肯定是不同的，每個人心中的標準不同，如果沒有一個統一的規範，最後的結果可想而知。所以架構就是定規則做限制，是在權衡各方得與失之後的一個“最合理決策”，由它來指導團隊中的每個人思想層面上的一致，使得最終的產品達到像由一個人做出來的一樣。另外還有控制複雜度、提高團隊協作力、降低成本等等作用。

　　在軟體開發中，架構的意義不單單是為了讓團隊達成一致，因為我們工作的本質是為了做出更好的支撐業務發展需要的軟體產品，所以架構也是基於業務的架構。我認為一個好的架構能夠提前預見業務發展1~2年為宜。這樣可以付出較為合理的代價換來真正達到技術引領業務成長的效果。我相信大部分在中小型公司呆過的人應該都經歷過被業務推著走的時代，每天焦頭爛額的這裡卡了，這裡掛了，這裡報錯等等問題。當我們遇到這些問題的時候是時候花成本來考量當前的架構是否存在問題？

　二、如何開始設計一個架構

　　做架構的最重要的一點就是上面說的貼合業務，任何不基於業務做異想天開的架構都是耍流氓~

　　架構不是像平常寫程式碼一樣，對就是對，錯就是錯，它並無對錯之分，是一個取捨的過程。當我們從0開始做架構的時候，的確是比較困難。雖然萬事開頭難，但是一個好的開始相當於成功了一半，會給我們接下去的工作打下結實的基礎。　

　　下面來闡述一下筆者個人是如何從頭開始做一個架構的，供大家參考學習：

　　1.架構是一個整體--> 部分的過程，先得明確整個公司/組織對外提供的服務是什麼？這是最上層的戰略架構，這個基本是一旦確定就很難甚至無法更改了。

　　2.給每個部分（比如SOA的某個服務）劃分解決方案。比如根據公司的組織架構或者產品等。

　　3.找到每個解決方案的核心功能和支撐功能。並形成一個業務總覽圖

　　4.分久必合，合久必分，結合當前的實際資源情況做出最終的決策，這是整個過程中最耗時的點，它決定著架構的複雜度和開發成本。方式上包括但不限於抽出可重用的功能、功能的組合、拆分粒度更細的功能提高可重用性等等。這一切的決策都要以“恰到好處”為宜。千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！重要的事情說3遍。服務粒度越細，呼叫鏈路越複雜，帶來的開發成本是否適合團隊，是作為一個架構師需要著重考量的點。

　　5.確立每個功能塊之間的協作方式，包括但不限於通訊方式，通訊協議，依賴關係等。

　　6.最後要把這些形成最終的架構總覽圖，這樣能夠幫助站在一個更高的角度去考慮架構的演變問題。如果是針對現存專案重新做架構，那麼需要把現有專案架構梳理出來，作為我們上面思考過程中的一部分參考資訊。

　三、一個好架構的特點

　　首先從心態上必須要有工匠精神，因為軟體架構和造房子還是有不同的，它不是一開始就一步到位的，好的設計肯定需要經過反覆的修改，從簡單到複雜的迴圈驗證，不斷的打磨。

　　方向上我認為分以下幾個點：

　　1.文件化：不管是整體還是部分的整個生命週期內都必須做好文件化，變動的來源包括但不限於BUG，需求。

　　2.高可用：要儘可能的提高軟體的可用性，我想每個操作人都不願意看到自己的工作無法正常進行。黑盒白盒測試、單元測試、自動化測試、故障注入測試、提高測試覆蓋率等方式來一步一步推進。

　　3.安全：組織的運作過程中產生的資料都是具有商業價值的，保證資料的安全也是刻不容緩的一部分。以免出現XX門之類醜聞。加密、https等為普遍手段

　　4.可擴充套件：軟體的設計秉承著低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和運用技術的迭代，並且支援在適時對架構做出重構。

　　5.快速迭代：擁抱變化，佔領戰略先機。

　　6.高度自治：為了更好支撐第4點和第5點的，每個功能能夠高度自治帶來的好處是可以快速迭代，並且不管是功能迭代還是技術迭代所對整個系統的影響降到最小。

　　7.高複用：為了避免重複勞動，為了降低成本，我們希望能夠重用之前的程式碼、之前的設計。這點對於架構環境的依賴是最大的。

　　8.可驗證：一個好的框架需要考慮到各種特殊情況，並且是可以進行專項驗證的。

　四、做架構中的誤區

　　做任何事的時候需要不斷的跳出原來的思維角度重新審視，這樣才能避免陷入泥潭。列出幾個我能想到的誤區：

　　誤區1——架構專門由架構師來做，業務開發人員無需關注：架構的再好，最終還是需要程式碼來落地，並且組織越大這個落地的難度越大。不單單是系統架構，每個解決方案每個專案也由自己的架構，如分層、設計模式等。如果每一塊磚瓦不夠堅固，那麼整個系統還是會由崩塌的風險。所謂“千里之堤，潰於蟻穴”。

　　誤區2——架構師確定了架構藍圖之後任務就結束了：架構不是“空中樓閣”，最終還是要落地的，但是架構師完全不去深入到第一線怎麼知道“地”在哪？怎麼才能落的穩穩當當。

　　誤區3——不做出完美的架構設計不開工：世上沒有最好架構，只有最合適的架構。我們需要的不是一下子造出一輛汽車，而是從單輪車 --> 自行車 --> 摩托車，最後再到汽車。想象一下2年後才能造出的產品，當初市場還存在嗎？

　五、結語

　　架構之路任重而道遠。程式設計和架構設計是互通的，每個人都可以從設計好一個程式往設計好一個系統架構前進。如果現在還無從下手的，我推薦大家可以從領域驅動設計這個概念入手，這是由業務為導向的設計方式，可以對培養設計出落地的架構有很大的幫助。最後引用“俞軍”一句名言，我們作為架構師要有“懷疑精神：自我迭代”的心。