一、架構的定義
所謂一千個架構師中有一千種「最好的架構」模式。
「架構」是我們這行業種乙個很常見的詞，表明其必然也是經歷了很長的歲月打磨所形成的乙個詞。架構的這個詞出現的意義是什麼？為了解決什麼問題？只有把這2個問題想明白了，才能設計出乙個良好的專案架構。
我認為 架構類似於畫房屋設計圖，在剛開始我們蓋一層樓的小房子的時候，拍拍腦門想一下，腦子裡有個大概的樣子就開始動工了，想怎麼蓋就怎麼蓋，大部分情況下也都不會出現。但是當你要蓋乙個大樓，這時候拍拍腦門的方式雖然有可能還能管用，但是由於沒有經過深思熟慮的多方考量，建造出來的必然是問題重重。另外建造大樓和蓋個一層樓的小屋所需的團隊規模肯定是不同的，每個人心中的標準不同，如果沒有乙個統一的規範，最後的結果可想而知。所以架構就是定規則做限制，是在權衡各方得與失之後的乙個「最合理決策」，由它來指導團隊中的每個人思想層面上的一致，使得最終的產品達到像由乙個人做出來的一樣。另外還有控制複雜度、提高團隊協作力、降低成本等等作用。
在軟體開發中，架構的意義不單單是為了讓團隊達成一致，因為我們工作的本質是為了做出更好的支撐業務發展需要的軟體產品，所以架構也是基於業務的架構。我認為乙個好的架構能夠提前預見業務發展1~2年為宜。這樣可以付出較為合理的代價換來真正達到技術引領業務成長的效果。我相信大部分在中小型公司呆過的人應該都經歷過被業務推著走的時代，每天焦頭爛額的這裡卡了，這裡掛了，這裡報錯等等問題。當我們遇到這些問題的時候是時候花成本來考量當前的架構是否存在問題？
二、如何開始設計乙個架構
做架構的最重要的一點就是上面說的貼合業務，任何不基於業務做異想天開的架構都是耍流氓~
架構不是像平常寫**一樣，對就是對，錯就是錯，它並無對錯之分，是乙個取捨的過程。當我們從0開始做架構的時候，的確是比較困難。雖然萬事開頭難，但是乙個好的開始相當於成功了一半，會給我們接下去的工作打下結實的基礎。
1.架構是乙個整體--> 部分的過程，先得明確整個公司/組織對外提供的服務是什麼？這是最上層的戰略架構，這個基本是一旦確定就很難甚至無法更改了。
2.給每個部分（比如soa的某個服務）劃分解決方案。比如根據公司的組織架構或者產品等。
3.找到每個解決方案的核心功能和支撐功能。並形成乙個業務總覽圖
4.分久必合，合久必分，結合當前的實際資源情況做出最終的決策，這是整個過程中最耗時的點，它決定著架構的複雜度和開發成本。方式上包括但不限於抽出可重用的功能、功能的組合、拆分粒度更細的功能提高可重用性等等。這一切的決策都要以「恰到好處」為宜。千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！千萬不要盲目的跟從微服務之風！重要的事情說3遍。服務粒度越細，呼叫鏈路越複雜，帶來的開發成本是否適合團隊，是作為乙個架構師需要著重考量的點。
5.確立每個功能塊之間的協作方式，包括但不限於通訊方式，通訊協議，依賴關係等。
6.最後要把這些形成最終的架構總覽圖，這樣能夠幫助站在乙個更高的角度去考慮架構的演變問題。如果是針對現存專案重新做架構，那麼需要把現有專案架構梳理出來，作為我們上面思考過程中的一部分參考資訊。
三、乙個好架構的特點
首先從心態上必須要有工匠精神，因為軟體架構和造房子還是有不同的，它不是一開始就一步到位的，好的設計肯定需要經過反覆的修改，從簡單到複雜的迴圈驗證，不斷的打磨。
方向上我認為分以下幾個點：
2.高可用：要盡可能的提高軟體的可用性，我想每個操作人都不願意看到自己的工作無法正常進行。黑盒白盒測試、單元測試、自動化測試、故障注入測試、提高測試覆蓋率等方式來一步一步推進。
3.安全：組織的運作過程中產生的資料都是具有商業價值的，保證資料的安全也是刻不容緩的一部分。以免出現xx門之類醜聞。加密、https等為普遍手段
4.可擴充套件：軟體的設計秉承著低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和運用技術的迭代，並且支援在適時對架構做出重構。
5.快速迭代：擁抱變化，占領戰略先機。
6.高度自治：為了更好支撐第4點和第5點的，每個功能能夠高度自治帶來的好處是可以快速迭代，並且不管是功能迭代還是技術迭代所對整個系統的影響降到最小。
7.高復用：為了避免重複勞動，為了降低成本，我們希望能夠重用之前的**、之前的設計。這點對於架構環境的依賴是最大的。
8.可驗證：乙個好的框架需要考慮到各種特殊情況，並且是可以進行專項驗證的。
四、做架構中的誤區
做任何事的時候需要不斷的跳出原來的思維角度重新審視，這樣才能避免陷入泥潭。列出幾個我能想到的誤區：
誤區1——架構專門由架構師來做，業務開發人員無需關注：架構的再好，最終還是需要**來落地，並且組織越大這個落地的難度越大。不單單是系統架構，每個解決方案每個專案也由自己的架構，如分層、設計模式等。如果每一塊磚瓦不夠堅固，那麼整個系統還是會由崩塌的風險。所謂「千里之堤，潰於蟻穴」。
誤區2——架構師確定了架構藍圖之後任務就結束了：架構不是「空中樓閣」，最終還是要落地的，但是架構師完全不去深入到第一線怎麼知道「地」在哪？怎麼才能落的穩穩當當。
誤區3——不做出完美的架構設計不開工：世上沒有最好架構，只有最合適的架構。我們需要的不是一下子造出一輛汽車，而是從單輪車 --> 自行車 --> 電單車，最後再到汽車。想象一下2年後才能造出的產品，當初市場還存在嗎？
五、針對架構的建議
六、結語
架構之路任重而道遠。程式設計和架構設計是互通的，每個人都可以從設計好乙個程式往設計好乙個系統架構前進。如果現在還無從下手的，我推薦大家可以從領域驅動設計這個概念入手，這是由業務為導向的設計方式，可以對培養設計出落地的架構有很大的幫助。最後引用「俞軍」一句名言，我們作為架構師要有「懷疑精神：自我迭代」的心。
週末隨筆 聊一聊IOC和DI
首先，本文 的目的是如何讓系統的擴充套件性變高，以實現降低迭代成本。追求開發速度的完全不必理會。ioc inverse of control 控制反轉，但這個說法不夠直白，在實際生產中，用控制轉移來描述反而地道一點。今天不摳字眼，物件的控制權轉交給第三方，往往就是 某一介面具體實現類的選擇控制權從呼...
隨筆 聊一聊伺服器的那些事兒
今天和乙個搞前端的同學聊天，他認為的伺服器貌似和我們開發的時候的伺服器不一樣，正好藉著這個機會聊聊什麼是伺服器 大家眼中的伺服器是什麼樣子的。也就是大家心目中最常見的機房的形象，專門的環境和人員對大型伺服器進行管理。而在運維的同學眼中可能是這樣的 特點 企業購買或者租用伺服器，需要配備專門的運維人員...
兩年PHPer聊下架構
備註 系統架構 是乙個很大的範疇，我這裡只是把我所經歷的小型創業公司的一次架構公升級做個分享。直接上最終的架構圖，如下 上面的架構有什麼問題，協議層產生了重度的耦合，協議層耦合各個業務方的邏輯。雖然系統拆分的原則是盡可能的不產生依賴，但是有些還是不可避免的。三方面 其次我認為最恐怖的是負責協議層開發...