文章很長，且持續更新，建議收藏起來，慢慢讀！瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 ：
免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ，幫你 實現技術自由，完成職業升級， 薪酬猛漲！加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷1）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷2）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷3）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取
網易面試：請設計一個高可用性的軟件架構，說明設計思路
尼恩說在前面
在40歲老架構師 尼恩的讀者交流羣(50+)中，最近有小夥伴拿到了一線互聯網企業如阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試資格，遇到很多很重要的面試題：
請設計一個高可用性的軟件架構，說明設計思路
最近有小夥伴在面試網易，又遇到了相關的面試題。小夥伴懵了，因爲沒有遇到過，所以支支吾吾的說了幾句，面試官不滿意，面試掛了。
所以，尼恩給大家做一下系統化、體系化的梳理，使得大家內力猛增，可以充分展示一下大家雄厚的 “技術肌肉”，讓面試官愛到 “不能自已、口水直流”，然後實現”offer直提”。
當然，這道面試題，以及參考答案，也會收入咱們的 《尼恩Java面試寶典PDF》V168版本，供後面的小夥伴參考，提升大家的 3高 架構、設計、開發水平。
《尼恩 架構筆記》《尼恩高併發三部曲》《尼恩Java面試寶典》的PDF，請到文末公號【技術自由圈】獲取
本文目錄
HA的目標
高可用，英文單詞High Availability，縮寫HA，它是分佈式系統架構設計中一個重要的度量。
業界通常用多個9來衡量系統的可用性，如下表：
既然有可用率，有一定會存在不可用的情況。
不可用一般分爲有計劃的和無計劃的，有計劃的如日常維護、系統升級等，無計劃的如設備故障、突發斷電等。
我們對不可用的問題作如下分類：
-
設備故障：機房斷電、硬盤損壞、交換機故障。
-
網絡故障：網絡帶寬擁堵、網絡連接中斷。
-
安全問題：利用系統漏洞進行網絡攻擊。
-
性能問題：CPU利用率太高、內存不足、磁盤IO過載、數據庫慢SQL。
-
升級維護：由於業務變更或技術改進而引起的系統升級。
-
系統問題：分佈式系統中存在服務的依賴而導致數據的不一致性，或是核心服務出現異常。
-
雲平臺崩潰： 2023-11月左右，互聯網P0級（宕機幾個小時）故障頻發：語雀一個月前崩了，接着阿里雲崩，阿里雲崩完、滴滴崩......而且都是宕機幾個小時，影響面廣，例如由於滴滴平臺不能提供服務。 這些事故都是底層基礎架構崩潰，比如雲平臺崩潰導致，問題非常難定
-
機房宕機：2023 年6 月 5 日，唯品會發布關於 329 機房宕機故障處理公告。官方在公告中稱，南沙機房重大故障影響時間持續 12 個小時，導致公司業績損失超億元，影響客戶達 800 多萬。公司讓對應部門的直接管理者承擔此次事故責任，基礎平臺部負責人予以免職處理。
-
其他問題： 其他的引發線上故障的問題。
如何體系化、系統化、徹底化的解決 HA 問題。
總的策略：高可用分而治之
在尼恩的 經典文章中， 一張圖總結架構設計的40個黃金法則 ，給大家介紹了架構的本質：
典型架構分層設計如下：按照功能處理順序劃分應用，這是面向業務深度的劃分。
每個公司的架構分層可能不一樣，但是目的都是爲了統一架構術語，方便團隊內部溝通。
-
接入層：主要流量入口，經過簡單
-
應用層：直接對外提供產品功能，例如網站、API接口等。應用層不包含複雜的業務邏輯，只做呈現和轉換。
-
服務層：根據業務領域每個子域單獨一個服務，分而治之。
-
數據層：數據庫和NoSQL，文件存儲等。
和 高併發/大數據的架構設計一樣， HA 一般是分層進行， 有關 高併發/大數據的架構設計， 具體請參見尼恩的另一篇硬核文章：
HA 可以的架構設計 從下面的5大層來建設和分析：
1：接入層：
主要流量入口
2：應用層：
負責具體業務和視圖展示；
網站首頁、用戶中心、商品中心、購物車、紅包業務、活動中心等，
3：服務層：
根據業務領域每個子域單獨一個服務，分而治之。
服務層爲應用層提供服務支持； 比如：訂單服務、用戶管理服務、紅包服務、商品服務等
這個是我們重點要關注的架構設計，架構設計不合理，就很難抗住高併發，主要包括各種架構和模塊的設計。
4：數據層：
數據庫和NoSQL，文件存儲等。
關係數據庫、nosql數據庫等，提供數據存儲查詢服務。
5：基礎設施層：
這個是最基礎的依賴，主要是一些服務的部署。
基礎設施層一般包含了服務器、中間件、部署方式等等。
第1層： 接入層的HA架構方案：
接入層 總的策略：動靜分離，分而治之
- 動態資源使用 Nginx+LVS+KeepAlive 進行負載均衡
- 靜態資源使用 CDN進行加速
接入層的HA架構方案，包括：
- DNS高可用，採用 雙域名、 多接入點等措施，避免dns單點故障，和性能不足
- LVS 高可用
- Nginx 高可用
DNS高可用 應對措施如下：
LVS 高可用 + Nginx 高可用, 可以參見尼恩之前的文章：
10Wqps網關接入層，LVS+Keepalived(DR模式)如何搭建？
主要策略：採用keepalive 保證 nginx、lvs 的高可用避免單點瓶頸
第2/3層：應用層/服務層HA架構方案：
應用層/服務層HA架構的主要原則：
原則1、可以水平擴展：
首先通過業務解耦、技術解耦， 把大單體架構解耦爲 微服務架構。
然後對後端微服務，通過接入層的負載均衡，實現故障自動轉移。
原則2、無狀態設計：
無狀態的系統更利於水平擴展，更利於做負載均衡。
狀態是系統的吞吐量、易用性、可用性、性能和可擴展性的大敵，要盡最大可能避免。
原則3、監控預警（可監控）：
至少包括三個維度的監控預警： Logging（日誌） 的監控 、Tracing（調用鏈）監控、Metrics（指標）監控。
原則4、灰度發佈（可灰度）：
結合接入層設計A/B 功能，實現灰度發佈，比如按ip，請求參數等分發流量。
原則5、回滾設計(可回滾) ：
確保系統可以向後兼容，如果應用服務上線後出現bug，可以緊急回滾。
應用層/服務層HA架構的主要策略：
可以水平擴展 的前提，就是先業務解耦
1： 業務解耦
對一個複雜的業務，需要分割成不同的模塊單元，分而治之
一個大的問題域，需要分解爲很多小的問題域，分而治之
就是是微服務劃分、微服務架構
微服務架構解決大單體架構的的很多問題，比如擴展性、彈性伸縮能力、小規模團隊的敏捷開發等等。
如何進行微服務架構，如何劃分微服務：
- 高內聚低耦合
- 單一職責
- 可擴展原則
- 等等等等
如何進行業務解耦，如何劃分微服務？
在實操過程中， 建議使用DDD的建模方法進行建模。
具體請參見尼恩的系列文章
《字節面試：微服務一定要DDD，爲什麼？TDD和DDD 有何關係？》
2：橫向擴展設計
橫向擴展設計，包括：應用集羣、服務集羣
應對高併發系統，單節點模式都不可能搞定，因此都需要搭建應用集羣、服務集羣，
常見的微服務Provider的自動伸縮策略有以下兩種：
1）通過Kubernetes HPA組件實現自動伸縮。
2）通過微服務Provider自動伸縮伺服組件實現自動伸縮。
具體請參見尼恩的卷3：
3：鏈路隔離、分級冗餘
服務層冗餘設計最主要原則：服務分級管理
不同的服務，可用性要求不一樣，我們需要先這些服務做分級。
或者說：不同的鏈路，可用性要求不一樣，我們需要先這些鏈路做分級。 有些是黃金鍊路， 有的是非核鏈路。
1、各級服務的HA部署原則：
- 鏈路隔離
- 分級冗餘
黃金鍊路上的核心服務：進行鏈路隔離， 獨立服務器，且N+1部署。
非核鏈路上的普通服務：集中部署，可以共享服務器部署。
2、各級服務HA上線發佈原則：
-
核黃金鍊路上的核心服務：晚上12點上線。
-
非核鏈路上的普通服務：隨時可上線
4：服務的三可原則落地
原則3、監控預警（可監控）：
至少包括三個維度的監控預警： Logging（日誌） 的監控 、Tracing（調用鏈）監控、Metrics（指標）監控。
服務要能接入 elk、 Skywalking 、metric 三大監控底座
有關elk的原理和實操， 請參見尼恩的
- 《視頻第14章：橫掃全網，elasticsearch底層原理與高可用架構實操，40歲老架構師細緻解讀，處處透着原理和精髓》
- 《視頻第23章：100W級別QPS日誌平臺實操》
Skywalking原理和實操 請參考 尼恩的 《視頻第24章：資深架構必備，徹底穿透Skywalking鏈路跟蹤源碼、JavaAgent探針技術》
metric原理和實操 請參見尼恩的《視頻第33章：10Wqps 高併發 Netty網關架構與實操》
原則4、灰度發佈（可灰度）：
結合接入層設計A/B 功能，實現灰度發佈，比如按ip，請求參數等分發流量。
請參見尼恩的 《視頻第28章：穿透雲原生K8S+Jenkins+SpringCloud底層原理和實操》
原則5、回滾設計(可回滾) ：
確保系統可以向後兼容，如果應用服務上線後出現bug，可以緊急回滾。
請參見尼恩的 《視頻第28章：穿透雲原生K8S+Jenkins+SpringCloud底層原理和實操》
第四層：數據層HA架構方案
數據庫的HA架構設計旨在提供高可用性、高性能和可擴展性的數據庫服務。
數據層HA架構方案包括主從複製、自動切換和負載均衡等關鍵技術，以確保數據的持久性、可靠性和可用性。
一、主從複製
主從複製是一種常見的數據庫同步技術，通過將主數據庫的數據，實時同步到多個從數據庫來實現的。
在該架構中，主庫負責處理寫入操作，而從庫則負責處理讀取操作。
主從複製的工作原理是，主庫接收到寫入請求後，將數據變更記錄在二進制日誌（Binlog）中，並將其同步到從庫。從庫通過讀取主庫的Binlog，並將其中的數據變更應用到自身的數據庫中。
通過這樣的複製機制，從庫能夠實現與主庫的數據同步，從而保證了數據的一致性。
二、自動切換
自動切換是數據庫HA架構設計中的另一個關鍵技術。
當主庫發生故障或不可用時，自動切換機制能夠快速將從庫切換爲主庫，以確保系統的持續可用性。
在自動切換機制中，通常會採用心跳檢測的方式來監測主庫的狀態。
當主庫無法正常響應時，自動切換機制會立即啓動，並將系統切換到可用的從庫上。同時，還需要確保新的主庫能夠接收和處理寫入請求，以保證系統的正常運行。
三、負載均衡
負載均衡是數據庫HA架構設計中不可或缺的一環。
通過負載均衡技術，可以將用戶的請求均勻地分發到不同的數據庫節點上，以實現請求的並行處理和數據的平衡負載。
在負載均衡的實現中，通常會採用多個數據庫節點來共同處理用戶的請求。
通過將用戶請求導入到不同的節點上，並根據節點的負載情況進行動態調整，可以實現對數據庫系統的優化和提升。
四、容災備份
容災備份是雲數據庫HA架構設計中的重要環節。
通過將數據進行備份，並將備份數據存儲在不同的地理位置，可以在發生災難性故障時，儘快恢復數據庫的可用性。
容災備份通常會採用異地備份的方式，即將數據備份複製到不同的數據中心或服務器上。
這樣一來，即使某個數據中心或服務器發生故障，備份數據仍然可用，從而實現了對數據庫系統的災難恢復能力。
第五層：基礎設施層架構
基礎設施層架構 包含：
- 監控三大件: logging、tracing、metrics。
- 各種中間件：nacos，redis， rocketmq 等等各類中間件，都要高可用部署
- cicd組件
具體，請參見尼恩的文章
綜合性的措施和機制
除了以上五層，每一層的方案， 需要一些綜合性的措施和機制，包括但不限於:
- 360度全方位的監控告警機制
綜合措施1：360度全方位的監控告警機制
在高可用服務設計章節提到，核心服務可以監控：服務流量預警、端口存活、進程佔用的資源、服務接口功能邏輯是否正常，應用FGC等情況，需要一個完善監控告警機制，並在告警後，通過一定的策略進行處理，以致服務可以快速恢復。例如，監控FGC，如果在一分鐘內存出現10次FGC，自動重啓服務。
360度全方位的監控告警機制，包括但不限於:
-
網絡流量監控 。
-
系統監控：服務器資源和網絡相關監控（CPU、內存等）
-
日誌監控：統一日誌收集（各個服務）監控，跟蹤(log2) 。
-
應用監控：端口存活、進程佔用的資源，應用FGC等情況
-
業務監控 ：服務接口功能邏輯是否正常
-
立體監控 監控數據採集後，除了用作系統性能評估、集羣規模伸縮性預測等， 最終目標是還可以根據實時監控數據進行風險預警，並對服務器進行失效轉移，自動負載調整，最大化利用集羣所有機器的資源。
綜合措施2：做好過載保護
-
備份：數據備份（熱備，冷備（冗餘），異地）
-
過載保護：熔斷，限流，降級
-
重試，防雪崩（概率很小，成本很高）
綜合措施3：異地容災，單元化+異地多活設計
單元化+異地多活設計，既是高併發的核武器，也是高可用的核武器
在一些極端場景下，有可能所有服務器都出現故障，例如機房斷電、機房火災、地震等這些不卡抗拒因素會導致系統所有服務器都故障從而導致業務整體癱瘓，而且即使有其他地區的備份，把備份業務系統全部恢復到能夠正常提供業務，花費的時間也比較長。
爲了滿足中心業務連續性，增強抗風險能力，多活作爲一種可靠的高可用部署架構，成爲各大互聯網公司的首要選擇。
1：單元化（Set化）設計
一個服務對外的使用方可能有 A 業務、B 業務，那麼如何保證 AB 業務不會相互影響，那麼就是單元化（Set化）設計。
所謂單元，是指一個能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務，以及單元的數據分片。
單元化架構就是把單元作爲系統部署的基本單位，在全站所有idc機房中部署數個單元.
每個idc機房裏的單元數目不定，任意一個單元都部署了系統所需的所有的服務。
任意一個單元的數據是首先擁有分片數據，但是爲了切流的方便， 最終需要擁有全量數據。
傳統意義上的 SOA 化（服務化）架構，服務是分層的，每層的節點數量不盡相同，上層調用下層時，隨機選擇節點。
單元化架構下，服務仍然是分層的，
不同的是每一層中的任意一個節點都屬於且僅屬於某一個單元，上層調用下層時，僅會選擇本單元內的節點。
而要做到單元化，必須要滿足以下要求：
-
業務必須是可分片的，如 淘寶按照用戶分片， 餓了麼按照地理位置分片
-
單元內的業務是自包含的，調用盡量封閉
單元化署就是把業務系統分爲多個可擴展的邏輯分區，每個 SET 的邏輯分區都可以獨立部署並提供服務，SET 也可以理解爲 ”邏輯機房“ ，主要目的就是爲了進行獨立部署並且做到業務上的邏輯隔離。
關於 單元化SET 的具體例子：
-
微信紅包用戶發一個紅包時，微信紅包系統生成一個ID作爲這個紅包的唯一標識。
-
接下來這個紅包的所有發紅包、搶紅包、拆紅包、查詢紅包詳情等操作，都根據這個ID關聯。
-
紅包系統根據這個紅包ID，按一定的規則（如按ID尾號取模等），垂直上下切分。
-
切分後，一個垂直鏈條上的邏輯Server服務器、DB統稱爲一個SET。
單元化SET 部署之後，系統將所有紅包請求這個巨大的洪流分散爲多股小流，互不影響，分而治之。
現在稍微有點體量的公司都在做單元化，單元化的好處
1. 多AZ(可用區) 容災、異地多活。
2. 服務器體量太大，單一IDC沒有足夠的機器。
3. 提升用戶請求訪問速度。
2：多 IDC + 異地多活
基礎設施層一般包含了服務器、IDC、部署方式等等。
-
多 IDC 部署。比如服務同時在廣州、上海兩地部署。這個依賴我們的服務是無狀態的；
-
其他的參考下異地多活架構等相關部署。
3：流量分片路由+ 流量切換
在接入層之上，再部署一個「路由層」（通常部署在雲服務器上），自己可以配置路由規則，把用戶「分流」到不同的機房內。
但這個路由規則，具體怎麼定呢？有很多種實現方式，最常見的總結了 3 類：
1.按地理位置分片
非常適合與地理位置密切相關的業務，例如打車、外賣服務就非常適合這種方案。
拿外賣服務舉例，你要點外賣肯定是「就近」點餐，整個業務範圍相關的有商家、用戶、騎手，它們都是在相同的地理位置內的。舉例：北京、河北地區的用戶點餐，請求只會打到北京機房，而上海、浙江地區的用戶，請求則只會打到上海機房。這樣的分片規則，也能避免數據衝突。
但是，上海機房和 北京機房進行數據複製， 當一個機房發生故障時，路由層把流量切換到 另一個機房。
2.按業務類型分片
假設一共有 4 個應用，北京和上海機房都部署這些應用。但應用 1、2 只在北京機房接入流量，在上海機房只是熱備。應用 3、4 只在上海機房接入流量，在北京機房是熱備。
這樣一來，應用 1、2 的所有業務請求，只讀寫北京機房存儲，應用 3、4 的所有請求，只會讀寫上海機房存儲。
但是，上海機房和 北京機房進行數據複製， 當一個機房發生故障時，路由層 把流量切換到 另一個機房。
3.直接哈希分片
會根據用戶 ID 計算「哈希」取模，然後從路由表中找到對應的機房，之後把請求轉發到指定機房內。
舉例：一共 200 個用戶，根據用戶 ID 計算哈希值，然後根據路由規則，把用戶 1 - 100 路由到北京機房，101 - 200 用戶路由到上海機房，這樣，就避免了同一個用戶修改同一條數據的情況發生。
但是，上海機房和 北京機房進行數據複製， 當一個機房發生故障時，路由層 把流量切換到 另一個機房。
分片的核心思路在於，讓同一個用戶的相關請求，只在一個機房內完成所有業務「閉環」，不再出現「跨機房」訪問。正因爲如此，阿里在實施這種方案時，給它起了個名字，叫做「單元化」。
尼恩的HA高可用的系列文章
異地多活方案複雜， 尼恩之前積累過一系列的問題，可供參考：
高可用包括 去掉IDC機房內部的 single of failure， 也包括 去掉 IDC機房之間的 single of failure，
去掉IDC機房內部的 single of failure，參見下面的案例
《美團面試：ES+Redis+MySQL高可用，如何實現？》
去掉 IDC機房之間的 single of failure，主要是異地多活
說在最後：有問題找老架構取經
以上的內容，如果大家能對答如流，如數家珍，基本上 面試官會被你 震驚到、吸引到。
最終，讓面試官愛到 “不能自已、口水直流”。offer， 也就來了。
在面試之前，建議大家系統化的刷一波 5000頁《尼恩Java面試寶典PDF》，裏邊有大量的大廠真題、面試難題、架構難題。很多小夥伴刷完後， 吊打面試官， 大廠橫着走。
在刷題過程中，如果有啥問題，大家可以來 找 40歲老架構師尼恩交流。
另外，如果沒有面試機會，可以找尼恩來改簡歷、做幫扶。
遇到職業難題，找老架構取經， 可以省去太多的折騰，省去太多的彎路。
尼恩指導了大量的小夥伴上岸，前段時間，剛指導一個40歲+被裁小夥伴，拿到了一個年薪100W的offer。
狠狠卷，實現 “offer自由” 很容易的， 前段時間一個武漢的跟着尼恩捲了2年的小夥伴， 在極度嚴寒/痛苦被裁的環境下， offer拿到手軟， 實現真正的 “offer自由” 。
技術自由的實現路徑：
實現你的 架構自由：
《阿里二面：千萬級、億級數據，如何性能優化？ 教科書級 答案來了》
《峯值21WQps、億級DAU，小遊戲《羊了個羊》是怎麼架構的？》
… 更多架構文章，正在添加中
實現你的 響應式 自由：
這是老版本 《Flux、Mono、Reactor 實戰（史上最全）》
實現你的 spring cloud 自由：
《Spring cloud Alibaba 學習聖經》 PDF
《分庫分表 Sharding-JDBC 底層原理、核心實戰（史上最全）》
《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關係（史上最全）》
實現你的 linux 自由：
實現你的 網絡 自由：
《網絡三張表：ARP表, MAC表, 路由表，實現你的網絡自由！！》
實現你的 分佈式鎖 自由：
實現你的 王者組件 自由：
《隊列之王： Disruptor 原理、架構、源碼 一文穿透》
《緩存之王：Caffeine 源碼、架構、原理（史上最全，10W字 超級長文）》
《Java Agent 探針、字節碼增強 ByteBuddy（史上最全）》
實現你的 面試題 自由：
免費獲取11個技術聖經PDF：
