[TOC] ## 一、架構設計原則綜述 常見架構設計方案質量屬性點有：性能、可用性、硬件成本、項目投入、復雜度、安全性、可擴展性等。在評估這些質量屬性時，需要遵循架構設計原則： 1. 合適原則， 2. 簡單原則，避免貪大求全。 3. 基本上某個質量屬性能夠滿足一定時期業務發展就可以了。 屬性 | 集群方案 | 拆分方案 | 備注 ---|---|---|--- 性能 | 中，繼續擴展下去，MySQL會成為瓶頸|高，系統拆分為子系統，子系統又可以做成集群方案 | 拆分方案優 復雜度 | 低，只需要引入Nginx做負載均衡 |高，需要對系統和數據庫進行拆分 | 集群方案優 成本 |中，需要增加web服務器 |中，需要增加web服務器和MySQL服務器，單MySQL服務器物流上可以共用，邏輯上分開即可| 集群方案稍微優一點 可擴展 | 低，所有的功能繼續在同一個系統實現，系統會越來越復雜，擴展越來越難 | 高，系統按照追責拆分為多個字系統，每個子系統可單獨擴展 | 拆分方案優 可用性| 中，web服務器是集群模式，單MySQL是單點的，MySQL故障回你導致整個業務不可用 | 高，子系統是獨立的，某個子系統故障不會導致整個業務不可用 | 拆分方案優 > Eg:架構師選擇了Elasticsearch作為全文搜索解決方案，前提必須是架構師自己對Elasticsearch的設計原理有深入的理解，比如索引、副本、集群等技術點；而不能道聽途說Elasticsearch很牛，所以你選擇它，更不能成為把“細節我們不討論”這句話掛在嘴邊的“PPT架構師”。 ### 架構設計流程總結： 設計架構的時候，首先要分析出系統的復雜性。 架構師根據自己對業務的理解，挑選合適的架構模式進行組合，再對組合后的方案進行修改和調整。 新技術都是在現有技術的基礎上發展起來的，現有技術又源于先前的技術。 備選方案的數量以3～5個備選方案為最佳。 備選方案的差異要比較明顯。 備選方案的技術不要只局限于已經熟悉的技術。 通過360度環評的方式來評估備選方案。 按照質量屬性的優先級來判斷備選方案的優劣。 架構師需要對技術的細節和原理有較深入的理解，避免成為“PPT架構師”。 通過分步驟、分階段、分系統等方式，盡量降低方案復雜度。 采取設計團隊的方式來進行設計，可以博采眾長，匯集團隊經驗，減少思維和經驗盲區。 ### 存儲高性能總結： - 高性能數據庫集群的第一種方式是“讀寫分離”，其本質是將訪問壓力分散到集群中的多個節點，但是沒有分散存儲壓力。 - 數據庫讀寫分流需要考慮“復制延遲”帶來的復雜性。 - 數據庫讀寫分離的分配機制有兩種方式：程序代碼封裝和中間件封裝。 - 高性能數據庫集群的第二種方式是“分庫分表”，就可以分散訪問壓力，又可以分散存儲壓力。 - 業務分庫指的是按照業務模塊將數據分散到不同的數據庫服務器。 - 業務分庫會引起join操作問題、事務問題、成本問題三個復雜度相關的問題。 - 數據庫分表分為垂直分表和水平分表。 - 垂直分表引入的復雜性主要體現在表操作的數量要增加。 - 水平分表引入了路由、join操作、count()操作、order by操作等復雜度問題。 - K-V存儲在數據結構方面相比關系型數據庫具備較大優勢。 - 文檔數據庫最大的特點就是no-schema，可以存儲和讀取任意的數據。 - 列式存儲在某些場景下能夠大大節省I/O。 - 列式存儲具備很高的壓縮比，能夠節省存儲空間。 - 全文搜索引擎的基本源流是倒排索引。 - 為了讓全文搜索引擎支持關系型數據的全文搜索，需要做一些轉換操作，即將關系型數據轉換為文檔數據。 - 緩存穿透是指業務系統查詢的數據在緩存系統中沒有的時候，每次查詢都會訪問存儲系統。 - 緩存雪崩是指當緩存失效（過期）后引起系統性能急劇下降的情況。 - 緩存熱點指大部分甚至所有業務請求都命中同一份緩存數據。 ### 計算高性能總結： - RPC模型：每次有新的連接就新建一個進程去專門處理這個連接請求。 - TPC模型：每次有新的連接就新建一個線程去專門處理這個連接的請求。 - Reactor模型的基礎是I/O多路復用。 - Proactor模型是非阻塞異步網絡模式。 - 常見的負載均衡系統有3種：DNS負載均衡、硬件負載均衡和軟件負載均衡。 - 硬件負載均衡用于實現集群級別的負載均衡。 - 軟件負載均衡用于實現機器級別的負載均衡。 - 負載均衡算法分為：任務平分類、負載均衡類、性能最優類和Hash類。 ### CAP總結： - CAP理論三個核心要素：一致性、可用性和分區容忍性。 - CAP理論指分布式系統中涉及讀寫操作時，一致性、可用性、分區容忍性三個要素只能保證兩個，另外一個必須被犧牲。 - 分布式系統理論上不可能選擇CA架構，只能選擇CP或AP架構。 - CAP關注的粒度是數據，而不是整個系統。 - CAP是忽略網絡延遲的。 - 正常運行的情況下，不存在CP和AP的選擇，可以同時滿足CA。 - CAP中放棄某個要素并不等于什么都不做，需要為分區恢復后做準備。 - ACID的應用場景是數據庫事務，CAP關注的是分布式系統數據讀寫。 - BASE是CAP理論中的AP方案的延伸。 ### FMEA總結： - FMEA是一種在各行各業都有廣泛應用的可用性分析方法，通過對系統范圍內潛在的故障模式加以分析，并按照嚴重程度進行分類，以確保失效對于系統的最終影響。 - FMEA分析方法很簡單，就是一個FMEA分析表。 - FMEA分析中的“功能點”是從用戶的角度來看的，而不是從系統各個模塊功能點劃分來看的。 - FMEA分析中的“故障模式”的描述要盡量精確，多使用量化描述，避免使用泛化的描述。 - FMEA分析中的“嚴重程序”指站在業務的角度，故障的影響程度一般分為“致命/高/中/低/無“五個檔次。 - FMEA分析中不同的”故障原因“發生概率、檢測手段和處理措施可能不同。 - FMEA分析中的”風險程度“就是綜合嚴重程度和故障概率來一起判斷某個故障的最終等級。 - FMEA分析中不一定所有的問題都要解決，采取規避措施也可以。 ### 存儲高可用總結： - 主備架構中的”備機“主要還是起一個備份作用，并不承擔實際的業務讀寫操作。 - 主從架構中的主機負責讀寫操作，從機只負責讀操作，不負責寫操作。 - 主備倒換和主從倒換架構的復雜點主要體現在：狀態判斷、倒換決策和數據沖突修復三方面。 - 主主復制架構必須保證數據能夠雙向復制，而很多數據是不能雙向復制的。 - 根據集群中機器承擔的不同角色來劃分，集群可以分為兩類：數據集中集群、數據分散集群。 - 數據集中集群可以看作一主多備或一主多從，但復雜度比主備或主從要高出很多。 - 數據分散集群中每臺服務器都會負責存儲一部分數據和同時也會備份一部分數據。 - 數據分區主要應對地理級別的故障。 - 數據分區的復制規則分為集中式、互備式和獨立式。 ### 計算高可用總結： - 主備架構時計算高可用最簡單的架構，可以細分為冷備結構和溫備架構，常用溫備架構。 - 計算高可用的主備架構也比較適合與內部管理系統、后臺管理系統這類使用人數不多、使用頻率不高的業務，不太適合在線的業務。 - 主從架構與主備架構相比，發揮了硬件的性能，但設計要復雜一些。 - 高可用計算的集群根據集群中服務器節點角色的不同，可以分為對稱集群和非對稱集群。 - 對稱集群中每臺服務器的角色都是一樣的，都可以執行所有任務。 - 非對稱集群中的服務器分為多個不同的角色，不同角色執行不同的任務。 - 非對稱集群相比負載均衡集群，設計復雜度主要體現在任務分配策略和角色分配策略會更加復雜。 ### 業務高可用總結： - 異地多活架構的關鍵點就是異地、多活，其中異地就是指地理位置上不同的地方，多活就是指不同地理位置上的系統都能夠提供業務服務。 - 異地多活雖然功能很強大，但也不是每個業務不管三七二十一都要上異地多活。 - 如果業務規模很大，能夠做異地多活的情況下盡量實現異地多活。 - 異地多活架構可以分為同城異區、跨城異地、跨國異地。 - 異地多活設計技巧：保證核心業務的異地多活、保證核心數據最終以執行、采用多種手段同步數據、只保證絕大部分用戶的異地多活。 - 接口級故障的主要應對方案：降級、熔斷、限流、排隊。 - 降級的核心思想就是丟車保帥，優先保證核心業務。 - 限流指只允許系統能夠承受的用戶量進來訪問，超出系統訪問能力的用戶將被拋棄。 - 排隊實際上是限流的一個變種，限流是直接拒絕用戶，排隊是讓用戶等待很長水間。 ### 可擴展模式總結： - 軟件系統與硬件和建筑系統最大的差異在于軟件是可擴展的。 - 真正有生命力的軟件系統都是在不斷迭代和發展的。 - 所有可擴展性架構設計，背后的基本思想都可以總結為一個字：拆。 - 面向流程拆分：分層架構 - 面向服務拆分：SOA、微服務。 - 面向功能拆分：微內核架構。 - 不同的拆分方式將得到不同的系統架構。 ### 分層架構總結： - 分層架構是很常見的架構模式，也叫N層架構，通常情況下，N至少是2層，一般不超過5層。 - C/S架構、B/S架構劃分的對象是整個業務系統，劃分的維度是職責，將不同的職責劃分到獨立層。 - MVC架構、MVP架構劃分的對象是單個業務子系統，劃分的維度是職責，將不同的職責劃分到獨立層。 - 邏輯分層架構劃分的對象可以是單個業務子系統，也可以是整個業務系統，劃分的維度也是職責。 - 無論采用何種分層維度，分層架構設計最核心的一點就是需要保證各層之間的差異足夠清晰，邊界足夠明顯。 - 分層架構之所以能夠較好地支撐系統擴展，本質在于：隔離關注點。 - 分層架構的一個特點就是層層傳遞。 - 分層架構一個典型的缺點就是性能。 ### SOA架構總結： - SOA提出的背景是企業內部的IT系統重復建設且效率低下。 - SOA更多是在傳統企業（例如，制造業、金融業等）落地和推廣，在互聯網行業并沒有多大規模的時間和推廣。 - SOA三個關鍵概念：服務、ESB和松耦合。 - SOA架構中，每項業務功能都是一項服務，服務就意味著對外提供開放的能力。 - SOA使用ESB來屏蔽異構系統對外提供各種不同的接口方式，以此來達到服務間高效的互聯互通。 - SOA解決了傳統IT系統重復建設和擴展效率低的問題，但其本身也引入了更多的復雜性，SOA最廣為人詬病的就是ESB。 - SOA的ESB設計也是無奈之舉，企業在應用SOA時，各種異構的IT系統都已經踩在很多年了，完全重寫或者按照統一標準進行改造的成本是非常大的，只能通過ESB方式其適配已經存在的各種異構系統。 ### 微服務架構總結 - 微服務概念的歷史要早得多，也不是Martin Flower創造出來的，Martin只是將微服務進行了系統的闡述。 - 微服務是一種和SOA相似但本質上不同的架構理念。 - 微服務的三個關鍵詞 : small（微小的）、lightweight(輕量的)、automated（自動化）。 - 微服務和SOA不存在孰優孰劣，只是應用場景不同。 - 微服務并不是沒有代價，而是會帶來系統復雜度、運維復雜度、性能下降等問題。 - 微服務拆分的粒度遵循“三個火槍手”原則。 - 真正決定微服務成敗的，恰恰是那個被大部分人都忽略的“automated”，而不是“lightweight”和“small”。 - 微服務并不是很多人認為的那樣又簡單又輕量級，要做好微服務，基礎設施是必不可少的。 ### 微內核架構總結 - 微內核架構也被稱為插件化架構(Plug-in-Architecture)，是一種面向功能進行拆分的可擴展性架構。 - 微內核架構通常用于實現基于產品的應用 - 微內核架構包含兩類組件:核心系統(core system) 和插件模塊(plug-in modules)。 - 微內核的核心系統設計的關鍵技術有幾部分: 插件管理、插件連接和插件通信。 - Eclipse采用OSGi標準后，OSGi更是成為首選的插件化標準。