談到架構我們首先想到的是架構師，這是很多軟件工程師的職業目標。但到底什麼是架構，大部分人不能夠準確的回答。我們經常會聽到微信架構，淘寶架構，還有如層次架構，微服務架構，面向服務的架構，B/S架構，C/S架構，這些我們經常聽到，也只知道對方說的是什麼，但讓你具體描述時，又很難描述清楚。
我們看一下維基百科的定義：軟件架構是指系統的一個或者多個結構。這裡的結構包括軟件構件，構件的外部可見屬性以及構件之間的相互關係。
區分一些概念：
系統：一群關聯的個體組成，根據規則運作，能完成個體不能單獨完成的工作的群體。
模塊和組件：不同角度拆分系統，從邏輯角度拆分得到的就是“模塊”，從物理角度拆分得到的就是“組件”。登錄模塊、個人成績模塊；nginx組件，mysql組件。模塊更多的表達職責，組件強調可重用，與語言無關，用於組裝應用程序。
構件：獨立部署的單元，沒有外部可見的狀態，做為第三方組裝的單元。
框架：是組件的規範，提供基礎功能的產品。如MVC框架，J2EE框架都是常見的開發規範。
架構設計主要是關注軟件構件的結構、屬性和交互作用。這裡的構件可以是子系統、簡單的程序模塊或者是面向對象的類，也可以擴充到數據庫和能夠完成客戶與服務器網絡配置的“中間件”。
架構就是通過系統性思考，權衡利弊和資源約束下，得到的明確的系統骨架：主要包括子系統，模塊，組件以及他們之間的關係，約束規範，指導原則。
從架構分類上看，架構可以是：業務架構，應用架構，技術架構，代碼架構，部署架構。可以說這就是使用4+1視圖對架構進行描述。
業務架構（統一場景視圖）：對系統的業務進行拆分，對領域模型的設計，把現實的業務轉化成抽象對象。
應用架構（邏輯視圖）：也叫邏輯架構圖，定義系統有哪些應用，以及應用之間如何分工合作。這裡的應用就是構件，各個邏輯模塊或子系統作為獨立部署的單元，為系統劃分了明確的邊界。
應用架構圖關鍵點：1.劃分：明確應用邊界，邏輯分層，子系統和模塊的定義。2.協作：應用對外的接口協議，應用之間的調用關係。
系統架構就是應用的“分”與“合”。
應用的“分”偏向於業務，反映業務架構，應用的“合”偏向於技術，影響技術架構。“分”降低了業務複雜度，系統更有序，“合”增加了技術複雜度，系統更無序。應用架構的本質是通過系統拆分，平衡業務和技術複雜性，保證系統形散神不散。
應用的“分”可以分為“水平分”和“垂直分”：“水平分（橫向）”，按照功能處理順序劃分應用，比如把系統分為web前端/中間服務/後臺任務，這是面向業務深度的劃分；“垂直分（縱向）”，按照不同的業務類型劃分應用，比如進銷存系統可以劃分為三個獨立的應用，這是面向業務廣度的劃分。
應用的“合”反映應用之間如何協作，共同完成複雜的業務功能，主要體現在應用之間的通訊機制和數據格式，通訊機制可以是同步調用/異步消息/共享DB訪問等，數據格式可以是文本/XML/JSON/二進制等。
技術架構（過程視圖）：確定組成應用系統的實際運行組件（lvs，nginx，tomcat，php-fpm等），這些運行組件之間的關係，以及部署到硬件的策略。主要考慮系統的非功能性特徵，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等做系統級的把握。
系統架構的設計要求架構師具備軟件和硬件的功能和性能的過硬知識，這也是架構設計工作中最為困難的工作。
代碼架構（實現視圖）：也叫開發架構，代碼架構主要為開發人員提供切實可行的指導，如果代碼架構設計不足，就會造成影響全局的架構設計。比如公司內不同的開發團隊使用不同的技術棧或者組件，結果公司整體架構設計就會失控。
主要定義：
1.開發技術選項： 開發語言，開發框架，開發工具
2.模塊劃分：源碼工程；Project目錄結構；分包(分庫)
3.開發規範：開發/編碼規範文檔；
部署架構（物理視圖）：實際的物理架構圖，架構部署了幾個節點，節點之間的關係，服務器的高可用，網路接口和協議等，決定了應用如何運行，運行的性能，可維護性，可擴展性，是所有架構的基礎。這個圖主要是運維工程師主要關注的對象。
物理架構主要考慮硬件選擇和拓撲結構，軟件到硬件的映射，軟硬件的相互影響。
網絡方面：網絡拓撲；網絡設備；安全機制
性能方面：可靠性、可伸縮性 ，需要什麼樣設備性能
部署方面：集中式還是分佈式；組件部署
架構設計與軟件生命週期
1.需求分析階段
在這個階段對架構的關注幾乎為零，在進行需求分析的時候一般不會也不需要去關注軟件架構，用句通俗的話說就是，需求還沒定架構什麼。但是從軟件複用的角度看，已有系統的架構模型對新系統的需求工程可以起到很好的借鑑作用，所以如果在這個階段就關注軟件架構，研究架構設計，有助於將軟件架構的概念貫穿整個軟件生命週期，從而保證軟件開發過程的概念完整性，有利於各階段參與者的交流，也易於維護各階段的可追蹤性。
2.設計階段
設計階段是架構設計關注最多的階段，這一階段包括：軟件架構模型的描述，軟件架構模型的設計與分析方法，以及對軟件架構設計經驗的總結與複用等。
（1）軟件架構模型由哪些元素組成，這些元素之間按照何種原則組織。
（2）軟件架構模型的多視圖表示。從不同的視角描述系統的架構，得到多個視圖，將這些視圖組織起來以描述整體的架構模型。典型的使用4+1視圖模型來描述架構。
3.實現階段
架構師的職責之一是要交付架構方案，但不是說交付完工作就完成了，為了有效實現從架構設計向實現的轉換，架構師還必須保證在架構方案執行過程中，整個開發團隊的實施效果與決策保持一致。即使在過程發現了實施與決策的衝突，就又需要重新協調溝通討論以取得新的一致。如何保證架構設計中的決策在架構執行過程中保持一致，這成為了架構工作的真正難點所在。
軟件架構提供了待生成系統的藍圖，根據藍圖實現系統需要較好的開發組織結構和過程管理技術。
（1）研究基於軟件架構的開發過程支持，如項目組織結構，配置管理等。
（2）研究從軟件架構向實現過度的途徑，如模型映射、構件組裝、複用中間件平臺等。
（3）研究基於軟件架構的測試技術。
4.部署階段
軟件架構對部署的研究更多的集中在組織和展示部署階段的軟件架構、評估分析部署方案等方面。
（1）提供高層的架構視圖描述部署階段的軟硬件模型。
（2）分析部署方案的質量屬性，根據軟件架構選擇合理的部署方案。
5.維護演化階段
在這個階段的軟件架構的涉及方面是比較少的。
動態軟件架構，如何在設計階段捕獲架構的動態性，並指導軟件系統在運行時刻實施這些變化，從而達到系統的在線演化和自適應。現實中軟件往往具有動態性，架構會在運行時發生改變。軟件架構如何支持這種變化，運行時的變化主要有兩種：1.軟件內部執行導致的，如客戶請求到達時創建新的構件來響應用戶，根據不同的配置採用不同的連接子來傳送數據。2.軟件外部請求對軟件進行重配置，如系統升級或修改不能停機，在運行過程中完成對架構的修改。
軟件架構重建，從已實現的系統中獲取架構的過程。
架構設計的重要性
首先架構設計可以降低軟件開發的風險，在設計變更相對容易的階段，考慮架構可能的方案。其次架構設計是降低成本，改進質量，按時和按需交付產品的關鍵因素。
一個簡單的"hello world"程序，你不會去想著做什麼架構設計，直接就代碼實現了。不過如果讓你實現一個雙十一秒殺系統時，你還可以直接上來就寫代碼嗎？這時候你就需要進行系統分析，架構設計等一系列工作。隨著軟件系統規模的增加，系統的組織結構的複雜，會導致了一系列的問題：內部耦合嚴重，開發效率低；牽一髮動全身，後續修改和擴展困難；系統邏輯複雜，容易出問題，排查修復困難。
架構設計的主要目的就是為了解決複雜度帶來的問題。理解每個架構背後所需要解決的複雜點，對比自己的業務複雜點，可以參考複雜點相似的方案。
閱讀更多 有一天我會成功 的文章
