[toc] # 前言 架構的出發點是業務和技術在不斷複雜化，引起系統混亂，需要通過架構來保證有序 * 搭一個草房子很簡單，可以直接上手 * 蓋一個2層樓房，稍微複雜，但在工匠經驗指導下，問題也不大 * 蓋一座高樓，複雜性就大不一樣了，需要考慮內部結構、承重、採光、排水、防雷抗震等，需要專業人員事先做好整體的架構設計，並嚴格地按照設計施工 ## 熵增定律：系統都是從有序到無序  放在軟體系統演化也適用，系統裡不停地新增業務功能，如果事先不做良好的設計，隨著時間的推進，整個系統野蠻生長，就會逐漸碎片化，越來越無序，最終被推倒重來。 自然界中的生物可以通過和外界互動，主動進行新陳代謝，製造“負熵”，也就是降低混亂程度，來保證自身的有序性，繼續生存 例如，植物通過光合作用，把光能、二氧化碳和水合成有機物，以此滋養自己，延續生命。 對於軟體系統，我們也可以主動地調整系統各個部分的關係，保證系統整體的有序性，來更好地適用不斷增長的業務和技術變化。 ## 天下大勢：分久必合，合久必分  架構實現從無序到有序，基本手段就是“分”與“合” * 分。把系統拆分為各種子系統、模組、元件 >三室一廳而不是大開間、兩菜一湯而不是三下鍋 * 合。基於業務流程和技術手段，把各個元件有機整合在一起。 > 屋子和書房原先用一堵牆分開，但是看書需求太強烈，直接把牆拿了，合成一個 好的架構應該有如下特點 * 滿足業務的可擴充套件、可複用 * 滿足系統的高可用、高效能 * 能用較低的成本落地 # 系統的組成  ## 接入系統 * DNS * Loader Balancer * Web伺服器 ## 應用系統 * 開發框架 * 應用程式碼 * 三方庫 ## 核心元件 * Database * 微服務框架 * 快取 * 訊息系統 * 搜尋系統 * 流程引擎 * 大資料/NoSQL ## 支撐系統 * 日誌系統 * 配置管理 * 任務排程 * 監控系統 * 安全風控 * 自動部署 * 資源管理 ## 基礎平臺 * 語言進行時 * 容器/虛擬機器 * 作業系統 * 硬體和網路 # 架構分類 ## 業務架構 講清楚核心業務的處理過程，定義各個業務模組的相互關係，從概念層面幫助我們理解系統面臨哪些問題以及如何處理 >電影的故事情節和場景安排 ## 應用架構 講清楚系統內部是怎麼組織的，有哪些應用，相互間怎麼呼叫的，它從邏輯層面幫助我們理解系統內部是如何分工與協作的 >電影裡有定義有哪些角色，每個角色有哪些職責，在每個場景中，這些角色是如何互動的。 ## 技術架構 講清楚系統由哪些硬體、作業系統和中介軟體組成，如果和我們開發應用一起配合，應用各種異常情況，保持系統的穩定可能 > 角色應該由誰來演，物理場景怎麼佈置，以此保證拍攝能順利進行 總之： * 做架構設計時，一般先考慮業務架構，再應用架構，最後技術架構。 * 開發的難點主要由業務架構和應用架構來解決，機器的痛點由技術架構來解決 * 另外，架構還需要考慮資料的可用性和一致性問題，這個可以參考CAP理論 >CAP理論，系統的可用性、一致性和網路容錯性，三個最多隻能保證兩個，在分散式系統的情況下，我們只能在C和A中選一個 # 複用的分類  ## 技術複用 工具層面的複用 ### 程式碼複用 * 函式 * 類庫 * SDK ### 元件複用 * Redis * MQ * 框架 * 中介軟體 ## 業務複用 ### 業務實體複用 對各個業務領域的資料和業務規則進行封裝，將它變成上層應用系統可以直接使用的業務元件 * 訂單 * 商品 * 使用者 * 會員 ### 業務流程複用 把多個業務實體串起來，完成一個端到端的任務。 >比如說，下單流程需要訪問會員、商品、訂單、庫存等多個業務，如果我們把這些呼叫邏輯封裝為一個下單流程服務，那下單頁面就可以呼叫這個流程服務來完成下單，而不需要去深入瞭解下單的具體過程 * 下單流程 * 購物流程 ### 產品複用 * 商城 * CRM * ERP * Sass系統 * Pas