程序員更多的關注的是局部，而架構師則是全局，這個蛻變的過程，是一個長期積累的過程，是一個需要量變的過程，最后才能從量變轉化為質變，成為一名合格的架構師。
一、什么是架構
- 架構是系統與子系統、模塊與組件、框架與架構以及它們之間的協作關系、約束規范、指導原則。
- 架構的本質是對系統進行有序化地重構，使其符合當前業務的發展，并可以快速擴展。
- 什么樣的系統要考慮做架構設計
- 需求相對復雜.
- 非功能性需求在整個系統占據重要位置.
- 系統生命周期長,有擴展性需求.
- 系統基于組件或者集成的需要.
- 業務流程再造的需要.
二、架構分類
- 架構可分為業務架構、應用架構、技術架構, 代碼架構, 部署架構。
- 業務架構是戰略，應用架構是戰術，技術架構是裝備。其中應用架構承上啟下，一方面承接業務架構的落地，另一方面影響技術選型。
- 業務架構
- 包括業務規劃，業務模塊、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象對象。
- 沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題為最終目標，脫離實際業務的技術情懷架構往往會給系統帶入大坑，任何不基于業務做異想天開的架構都是耍流氓。
- 所有問題的前提要搞清楚我們今天面臨的業務量有多大，增長走勢是什么樣，而且解決高并發的過程，一定是一個循序漸進逐步的過程。 合理的架構能夠提前預見業務發展1~2年為宜。這樣可以付出較為合理的代價換來真正達到技術引領業務成長的效果。
2.應用架構
- 劃分
1）、 職責劃分: 明確應用（各個邏輯模塊或者子系統）邊界
a. 邏輯分層
b. 子系統、模塊定義。
c. 關鍵類。
2）、 職責之間的協作：
a. 接口協議：應用對外輸出的接口。
b. 協作關系：應用之間的調用關系。
- 應用分層有兩種方式:
1）、水平分（橫向），按照功能處理順序劃分應用，比如把系統分為web前端/中間服務/后臺任務，這是面向業務深度的劃分。
2）、垂直分（縱向），按照不同的業務類型劃分應用，比如進銷存系統可以劃分為三個獨立的應用，這是面向業務廣度的劃分。
總結：業務架構、應用架構、技術架構三者之間，應用架構是個承上啟下的連接作用，應用架構依賴業務架構，同時又影響技術架構。
應用架構的本質是通過系統拆分，平衡業務和技術復雜性，保證系統形散神不散。
3.代碼架構（也叫開發架構）
公司統一代碼架構，如果不同開發團隊使用不同的技術棧或者組件，結果公司整體架構設計就會失控
- 代碼架構主要定義：
1）、 代碼單元
a. 配置設計
b. 框架、類庫
2）、 代碼單元組織：
a. 編碼規范，編碼的慣例
b. 項目模塊劃分
c .頂層文件結構設計，比如mvc設計
d.依賴關系
4.技術架構
技術架構：確定組成應用系統的實際運行組件（lvs，Nginx，Tomcat，php-fpm等），這些運行組件之間的關系，以及部署到硬件的策略。
技術架構主要考慮系統的非功能性特征，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等做系統級的把握。
5.部署拓撲架構
三、架構設計的3個原則
1、簡單
1）組件越多，就越有可能其中某個組件出現故障
2）某個組件改動，會影響關聯的所有組件
3）定位一個復雜系統中的問題總是比簡單系統更加困難
總結：簡單優于復雜，無論是結構的復雜性，還是邏輯的復雜性，都會存在各種問題，所以架構設計時如果簡單的方案和復雜的方案都可以滿足需求，最好選擇簡單的方案
2、合適
合適優于業界領先，根據自身實際情況，采用適合自己的業務，應用，技術架構，不能生搬硬套。這也是哲學上所說的，客觀決定主觀。
3、演化
演化優于一步到位
- 首先，設計出來的架構要滿足當時的業務需要。
- 其次，架構要不斷地在實際應用過程中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使得架構逐漸完善。
- 第三，當業務發生變化時，架構要擴展、重構，甚至重寫；代碼也許會重寫，但有價值的經驗、教訓、邏輯、設計等（類似生物體內的基因）卻可以在新架構中延續。
四、架構的演進
業務架構決定應用架構，應用架構需要適配業務架構，并隨著業務架構不斷進化，同時應用架構依托技術架構最終落地。
架構演進路程：單體應用->分布式應用服務化-> 微服務->service mesh
1、單體應用
- 非功能性需求的做法：
1）、性能需求：使用緩存改善性能
2）、并發需求：使用集群改善并發
3）、讀寫分離：數據庫地讀寫分離
4）、使用反向代理和cdn加速
5）、使用分布式文件和分布式數據庫
- 缺點
1）、復雜度高
2）、耦合性高
3）、可靠性差
4）、擴展性差
2、分布式應用
該架構相對于單體架構來說，這種架構提供了負載均衡的能力，大大提高了系統負載能力，解決了網站高并發的需求。另外還有以下特點：
1）降低了耦合度：把模塊拆分，使用接口通信,降低模塊之間的耦合度。
2）責任清晰：把項目拆分成若干個子項目，不同的團隊負責不同的子項目。
3）擴展方便：增加功能時只需要再增加一個子項目，調用其他系統的接口就可以。
4）部署方便：可以靈活的進行分布式部署。
5）提高代碼的復用性：比如Service層，如果不采用分布式rest服務方式架構就會在手機Wap商城，微信商城，PC，Android，IOS每個端都要寫一個Service層邏輯，開發量大，難以維護一起升級，這時候就可以采用分布式rest服務方式，公用一個service層。
缺點：系統之間的交互要使用遠程通信，接口開發增大工作量，但是利大于弊。
3、微服務應用
微服務的特點：
1）、易于開發和維護： 一個微服務只會關注一個特定的業務功能，所以它業務清晰、代碼量較少。 開發和維護單個微服務相對簡單。而整個應用是由若干個微服務構建而成的，所以整個應用也會被維持在一個可控狀態。
2）、單個微服務啟動較快： 單個微服務代碼量較少， 所以啟動會比較快
3）、局部修改容易部署： 單體應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題。 一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
4）功能純粹、耦合性低：服務拆分，每個服務功能單一，耦合性低
缺點：運維要求較高、分布式固有的復雜性、接口調整成本高
4、service mesh
微服務的下一個階段，即service mesh
Service Mesh 的核心其實就2個模塊：SideCar 與 Control Plane
用來解決微服務架構中 服務間可靠調用、服務治理 等問題
大家有興趣可以專門研究一下，在此不做過多講述
五、衡量架構的合理性
架構為業務服務，沒有最優的架構，只有最合適的架構， 架構始終以高效，穩定，安全為目標來衡量其合理性。
1、穩定性
1）要盡可能的提高軟件的可用性：黑盒白盒測試、單元測試、自動化測試、故障注入測試、提高測試覆蓋率等方式來一步一步推進
2、高效性
1)、 文檔化：不管是整體還是部分的整個生命周期內都必須做好文檔化，變動的來源包括但不限于BUG，需求。
2）、 可擴展：軟件的設計秉承著低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和運用技術的迭代，并且支持在適時對架構做出重構。
3）、高復用：為了避免重復勞動，為了降低成本，我們希望能夠重用之前的代碼、之前的設計。這點對于架構環境的依賴是最大的。
3、安全性
保證數據的安全
- xss攻擊
- sql注入
- csr攻擊
- web防火墻漏洞
- 安全漏洞
- ssl
六、常用手段
- 應用服務器和數據服務器分離
- 使用緩存改善性能
- 使用集群提高并發和可用性
- 數據庫地讀寫分離
- 使用反向代理和cdn加速
- 使用分布式文件和分布式數據庫
- 異步降低系統的耦合性，提供系統的可用性、加快響應速度
- 冗余：冷備和熱備，保證系統的可用性
