一、什麼是架構和架構本質
在軟件行業，對於什麼是架構，都有不少的爭論，每一個人都有本身的理解。此君說的架構和彼君理解的架構未必是一回事。php
咱們主要針對互聯網服server系統（相似網站）來定義架構：架構是系統的骨架，支撐和連接各個部分，包括組件、鏈接件、約束規範，以及指導這些內容設計與演化的原理。前端
組件：相似應用服務，獨立模塊、數據庫、nginx等等、nginx
鏈接件：分佈式調用、進程間調用、調用使用http協議仍是tcp協議、組件之間的交互關係、web
約束規範： 定規則作限制：例如設計原則、編碼規範等等。sql
是系統性地思考，權衡利弊以後在現有資源約束下的「最合理決策」，並由它來指導團隊中的每一個人思想層面上的一致。數據庫
即架構=組件+交互。編程
這相似建築設計規劃，城市整體規劃等，其實就是架構，只是應用的場景不一樣。蓋一座小房子，能夠拍腦殼幹起來，可是當你要蓋一座大樓，若是沒有一個建築設計規劃，能夠想象一下最後是什麼樣？設計模式
架構的本質就是對系統進行有序化地重構以至符合當前業務的發展，並能夠快速擴展。緩存
那什麼樣的系統要考慮作架構設計?tomcat
- 需求相對複雜.
- 非功能性需求在整個系統佔據重要位置.
- 系統生命週期長,有擴展性需求.
4.系統基於組件或者集成的須要
5.業務流程再造的須要.
二、架構分類
架構可細分爲業務架構、應用架構、技術架構、代碼架構、部署架構,
業務架構是戰略，應用架構是戰術，技術架構是裝備。其中應用架構承上啓下，一方面承接業務架構的落地，另外一方面影響技術選型。
熟悉業務，造成業務架構，根據業務架構，作出相應的應用架構，最後技術架構落地實施。
如何針對當前需求，選擇合適的應用架構，如何面向將來，保證架構平滑過渡，這個是軟件開發者，特別是架構師，都須要深刻思考的問題。
1、業務架構（俯視架構）：
包括業務規劃，業務模塊、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象對象。
沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題爲最終目標，脫離實際業務的技術情懷架構每每會給系統帶入大坑，任何不基於業務作異想天開的架構都是耍流氓。
全部問題的前提要搞清楚咱們今天面臨的業務量有多大，增加走勢是什麼樣，並且解決高併發的過程，必定是一個按部就班逐步的過程。合理的架構可以提早預見業務發展1~2年爲宜。這樣能夠付出較爲合理的代價換來真正達到技術引領業務成長的效果。
看看京東業務架構（網上分享圖）：
2、應用架構（剖面架構，也叫邏輯架構圖）：
硬件到應用的抽象，包括抽象層和編程接口。應用架構和業務架構是相輔相成的關係。業務架構的每一部分都有應用架構。
相似：
應用架構：應用做爲獨立可部署的單元，爲系統劃分了明確的邊界，深入影響系統功能組織、代碼開發、部署和運維等各方面. 應用架構定義系統有哪些應用、以及應用之間如何分工和合做。這裏所謂應用就是各個邏輯模塊或者子系統。
應用架構圖關鍵有2點：
一、職責劃分: 明確應用（各個邏輯模塊或者子系統）邊界
1）邏輯分層
2）子系統、模塊定義。
3）關鍵類。
二、職責之間的協做：
1）接口協議：應用對外輸出的接口。
2）協做關係：應用之間的調用關係。
應用分層有兩種方式：
一種是水平分（橫向），按照功能處理順序劃分應用，好比把系統分爲web前端/中間服務/後臺任務，這是面向業務深度的劃分。
另外一種是垂直分（縱向），按照不一樣的業務類型劃分應用，好比進銷存系統能夠劃分爲三個獨立的應用，這是面向業務廣度的劃分。
應用的合反映應用之間如何協做，共同完成複雜的業務case，主要體如今應用之間的通信機制和數據格式，通信機制能夠是同步調用/異步消息/共享DB訪問等，數據格式能夠是文本/XML/JSON/二進制等。
應用的分偏向於業務，反映業務架構，應用的合偏向於技術，影響技術架構。下降了業務複雜度，系統更有序，增長了技術複雜度，系統更無序。
應用架構的本質是經過系統拆分，平衡業務和技術複雜性，保證系統形散神不散。
系統採用什麼樣的應用架構，受業務複雜性影響，包括企業發展階段和業務特色；同時受技術複雜性影響，包括IT技術發展階段和內部技術人員水平。業務複雜性（包括業務量大）必然帶來技術複雜性，應用架構目標是解決業務複雜性的同時，避免技術太複雜，確保業務架構落地。
3、代碼架構（也叫開發架構）：
子系統代碼架構主要爲開發人員提供切實可行的指導，若是代碼架構設計不足，就會形成影響全局的架構設計。好比公司內不一樣的開發團隊使用不一樣的技術棧或者組件，結果公司總體架構設計就會失控。
代碼架構主要定義：
1、代碼單元:
一、配置設計
二、框架、類庫。
2、代碼單元組織：
一、編碼規範。
二、項目模塊劃分
三、頂層文件結構設計，好比mvc設計。
四、依賴關係
4、技術架構，也能夠叫系統架構
技術架構：肯定組成應用系統的實際運行組件（lvs，nginx，tomcat，php-fpm等），這些運行組件之間的關係，以及部署到硬件的策略。
技術架構主要考慮系統的非功能性特徵，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等作系統級的把握。
系統架構的設計要求架構師具有軟件和硬件的功能和性能的過硬知識，這也是架構設計工做中最爲困難的工做。
5、部署拓撲架構圖（實際物理架構圖）：
拓撲架構，包括架構部署了幾個節點，節點之間的關係，服務器的高可用，網路接口和協議等，決定了應用如何運行，運行的性能，可維護性，可擴展性，是全部架構的基礎。這個圖主要是運維工程師主要關注的對象。
三、應用架構
架構演進路程：
->初始階段：LAMP,部署在一臺服務器
->應用服務器和數據服務器分離
->使用緩存改善性能
->使用集羣改善併發
->數據庫的讀寫分離
->使用反向代理和cdn加速
->使用分佈式文件和分佈式數據庫
->業務拆分
->分佈式服務
業務架構是生產力，應用架構是生產關係，技術架構是生產工具。業務架構決定應用架構，應用架構須要適配業務架構，並隨着業務架構不斷進化，同時應用架構依託技術架構最終落地。
企業一開始業務比較簡單，好比進銷存，此時面向內部用戶，提供簡單的信息管理系統（MIS），支持數據增刪改查便可，單體應用能夠知足要求。
隨着業務深刻，進銷存每塊業務都變複雜，同時新增客戶關係管理，以更好支持營銷，業務的深度和廣度都增長，這時須要對系統按照業務拆分，變成一個分佈式系統。
更進一步，企業轉向互聯網+戰略，拓展在線交易，線上系統和內部系統業務相似，不必重作一套，此時把內部系統的邏輯作服務化改造，同時供線上線下系統使用，變成一個簡單的SOA架構。
緊接着業務模式愈來愈複雜，訂單、商品、庫存、價格每塊玩法都很深刻，好比價格區分會員等級，訪問渠道（無線仍是PC），銷售方式（團購仍是普通）等，還有大量的價格促銷，這些規則很複雜，容易相互衝突，須要把分散到各個業務的價格邏輯進行統一管理，以基礎價格服務的方式透明地提供給上層應用，變成一個微內核的SOA架構。
同時無論是企業內部用戶，仍是外部顧客所須要的功能，都由不少細分的應用提供支持，須要提供portal，集成相關應用，爲不一樣用戶提供統一視圖，頂層變成一個AOA的架構（application orientated architecture）。
四、衡量架構的合理性
架構爲業務服務，沒有最優的架構，只有最合適的架構， 架構始終以高效，穩定，安全爲目標來衡量其合理性。
1、穩定性指標：
- 高可用：要儘量的提升軟件的可用性，我想每一個操做人都不肯意看到本身的工做沒法正常進行。黑盒白盒測試、單元測試、自動化測試、故障注入測試、提升測試覆蓋率等方式來一步一步推動。
2、高效指標：
- 文檔化：無論是總體仍是部分的整個生命週期內都必須作好文檔化，變更的來源包括但不限於BUG，需求。
- 可擴展：軟件的設計秉承着低耦合的理念去作，注意在合理的地方抽象。方便功能更改、新增和運用技術的迭代，而且支持在適當的時候對架構作出重構。
- 高複用：爲了不重複勞動，爲了下降成本，咱們但願可以重用以前的代碼、以前的設計。這點對於架構環境的依賴是最大的。
3、安全指標
- 安全：組織的運做過程當中產生的數據都是具備商業價值的，保證數據的安全也是刻不容緩的一部分。以避免出現XX門之類醜聞。加密、https等爲廣泛手段
五、常見架構誤區
誤區1——架構專門由架構師來作，業務開發人員無需關注：架構的再好，最終仍是須要代碼來落地，而且組織越大這個落地的難度越大。不僅僅是系統架構，每一個解決方案每一個項目也有本身的架構，如分層、設計模式等。若是每一塊磚瓦不夠堅固，那麼整個系統仍是會有崩塌的風險。所謂「千里之堤，潰於蟻穴」。
誤區2——架構師肯定了架構藍圖以後任務就結束了：架構不是「空中樓閣」，最終仍是要落地的，可是架構師徹底不去深刻到第一線怎麼知道「地」在哪？怎麼才能落的穩妥當當。
誤區3——不作出完美的架構設計不開工：世上沒有最好架構，只有最合適的架構。咱們須要的不是一會兒造出一輛汽車，而是從單輪車 --> 自行車 --> 摩托車，最後再到汽車。想象一下2年後才能造出的產品，當初市場還存在嗎？
六、架構知識體系
架構演進
- 初始階段：LAMP,部署在一臺服務器
- 應用服務器和數據服務器分離
- 使用緩存改善性能
- 使用集羣改善併發
- 數據庫的讀寫分離
- 使用反向代理和cdn加速
- 使用分佈式文件和分佈式數據庫
- 業務拆分
- 分佈式服務
架構模式
- 分層：橫向分層：應用層，服務層，數據層
- 分割：縱向分割：拆分功能和服務
- 分佈式
- 分佈式應用和服務
- 分佈式靜態資源
- 分佈式數據和存儲
- 分佈式計算
- 集羣：提升併發和可用性
- 緩存：優化系統性能
- cdn
- 方向代理訪問資源
- 本地緩存
- 分佈式緩存
- 異步：下降系統的耦合性
- 提供系統的可用性
- 加快響應速度
- 冗餘：冷備和熱備，保證系統的可用性
- 自動化：發佈，測試，部署，監控，報警，失效轉移，故障恢復
- 安全：
架構核心要素
- 高性能：網站的靈魂
- 性能測試
- 前端優化
- 應用優化
- 數據庫優化
- 可用性：保證服務器不宕機，通常經過冗餘部署備份服務器來完成
- 負載均衡
- 數據備份
- 自動發佈
- 灰度發佈
- 監控報警
- 伸縮性：建集羣，是否快速應對大規模增加的流量，容易添加新的機器
- 集羣
- 負載均衡
- 緩存負載均衡
- 可擴展性：主要關注功能需求，應對業務的擴展，快速響應業務的變化。是否作法開閉原則，系統耦合依賴
- 分佈式消息
- 服務化
- 安全性：網站的各類攻擊，各類漏洞是否堵住，架構是否能夠作到限流做用，防止ddos攻擊。
- xss攻擊
- sql注入
- csr攻擊
- web防火牆漏洞
- 安全漏洞
- ssl
七、架構書籍推薦
- 《大型網站技術架構：核心原理與案例分析》
這是比較早，比較系統介紹大型網站技術架構的書，通俗易懂又充滿智慧，即使你以前徹底沒接觸過網站開發，通讀前幾章，也能快速獲取到常見的網站技術架構及其應用場景。很是贊。
- 《億級流量網站架構核心技術》
相比《大型網站技術架構》的高屋建瓴，開濤的這本《億級流量網站架構核心技術》則落實到細節，網站架構中常見的各類技術，好比緩存、隊列、線程池、代理……，通通都講到了，並且配有核心代碼。甚至連 Nginx 的配置都有！
若是你想在實現大流量網站時找參考技術和代碼，這本書最合適啦。
- 《架構即將來》
這是一本「神書」啦，超越具體技術層面，着重剖析架構問題的根源，幫助咱們弄清楚應該以何種方式管理、領導、組織和配置團隊。
- 《分佈式服務架構：原理、設計與實戰》
這本書全面介紹了分佈式服務架構的原理與設計，並結合做者在實施微服務架構過程當中的實踐經驗，總結了保障線上服務健康、可靠的最佳方案，是一本架構級、實戰型的重量級著做。
- 《聊聊架構》
這算是架構方面的一本神書了，從架構的原始談起，從業務的拆分談起，談到架構的目的，架構師的角色，架構師如何將架構落地……強烈推薦。
不過，對於沒有架構實踐經驗的小夥伴來說，可能會以爲這本書比較虛，概念多，實戰少。但若是你有過一兩個項目的架構經驗，就會深深認同書中追本溯源探討的架構理念。
- 《軟件架構師的12項修煉》
大多數時候所謂的「技術之玻璃天花板」其實只是缺少軟技能而已。這些技能能夠學到，缺少的知識能夠經過決定改變的努力來彌補。