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