文章很長，且持續更新，建議收藏起來，慢慢讀！瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 ：
免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ，幫你 實現技術自由，完成職業升級， 薪酬猛漲！加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷1）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷2）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程（卷3）加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取
一張圖總結架構設計的40個黃金法則
尼恩說在前面
在40歲老架構師 尼恩的讀者交流羣(50+)中，很多小夥伴拿到非常優質的架構機會，常常找尼恩求助：
尼恩，我這邊有一個部門技術負責人+資深架構師的機會，非常難得， 但是有一個大廠高P在搶， 如何一招制敵？
在此之前，已經有很多很多小夥伴遇到這樣的難題，找尼恩來求助。
這裏，尼恩藉着幫助這個小夥伴的機會，給大家梳理 40條黃金架構法則，幫助大家一招制敵。
同時，把這個40條黃金架構法則，也收入咱們的 《尼恩Java面試寶典PDF》V160版本《架構專題》，供後面的小夥伴參考，提升大家的 3高 架構、設計、開發水平。
《尼恩 架構筆記》《尼恩高併發三部曲》《尼恩Java面試寶典》的PDF，請到公衆號【技術自由圈】獲取
本文目錄
- 一張圖總結架構設計的40個黃金法則
- 尼恩說在前面
- 本文目錄
- 如何搶到一個年薪100W的offer？
- 架構學問，也是藝術
- 架構的36條黃金法則
- 黃金法則1：演進式法則
- 黃金法則2：先進性法則
- 黃金法則3：高併發 法則
- 黃金法則4：高可用 法則
- 黃金法則5： 高性能法則
- 黃金法則6：高併發讀 架構法則
- 黃金法則7：高併發寫架構法則
- 黃金法則8：靜態資源緩存架構法則
- 黃金法則9：垂直擴展架構
- 黃金法則10：水平擴展架構
- 黃金法則11： 索引架構法則
- 黃金法則12：事務性數據存儲架構法則
- 黃金法則13：非結構化數據存儲架構法則
- 黃金法則14： 複雜對象存儲架構法則
- 黃金法則15：高性能搜索的架構法則
- 黃金法則16：海量結構化數據的擴展架構
- 黃金法則17：圖形數據存儲架構
- 黃金法則18：時序數據存儲架構
- 黃金法則19：隊列緩衝+批處理法則
- 黃金法則20：預加載架構
- 黃金法則21：懶加載架構
- 黃金法則22：單一責任原則（SRP）
- 黃金法則23：松耦合原則
- 黃金法則24：領域驅動原則，不數據驅動原則，也不是界面驅動原則
- 黃金法則25：架構分層職責明確，嚴守調用規範，規避 “微服務小泥球”
- 黃金法則26：進行全方位的監控、記錄
- 黃金法則27：開發運維一體化法則
- 黃金法則28： API 網關法則
- 黃金法則29： 冗餘法則
- 黃金法則30： 數據容錯法則
- 黃金法則31：數據容災法則
- 黃金法則30： 心跳法則
- 黃金法則32：限流法則
- 黃金法則33：熔斷法則
- 黃金法則34：隔離架構
- 黃金法則34：一致性hash
- 黃金法則35：Gossip 協議 法則
- 黃金法則36：WebSocket推送 法則
- 黃金法則37：內存池 法則
- 黃金法則38：對象池 法則
- 黃金法則39：CAP法則
- 黃金法則40：最終一致性
- 說在最後：有問題找老架構取經
- 技術自由的實現路徑：
- 免費獲取11個技術聖經PDF：
如何搶到一個年薪100W的offer？
首先拋一個比較棘手的問題：
如何搶到一個年薪100W，管理幅度在100人以，優質架構offer？
今天上午，咱們社羣一個43歲的小夥， 找到尼恩， 求助這個難題。 他正在搶奪這個崗位。
爲啥叫做搶奪呢？
因爲和他競爭這個崗位的， 是來自另外一個大廠的候選人， 候選人是大廠P8+， 有大廠背景背書。看上去競爭很佔優勢。
而咱們社羣這一個43歲的小夥，沒有大廠背景，這點是他的短板。
所以，叫做搶奪。
當然，咱們這個小夥伴，也有長板。
-
第一個長板是： 他本人的人脈。 小夥爲人和善，言談舉止令人很舒服， 公司高層映像好，有人推薦他。
-
第二個長板是： 他本人的外援。 小夥伴有尼恩幫忙， 尼恩這邊長時間梳理架構方案/架構套路/架構實操。 尼恩3高宇宙理論既能夠上得廳堂（理論層面、宏觀層面的架構能力強），也能夠下得廚房（技術走地、代碼落地層面的架構強）， 而據說小夥伴的競爭對手，也那個大廠P8+， 在落地層面非常虛弱。
看看尼恩給小夥伴出的一個 技術架構圖，就知道有點乾貨了：
注意：請點擊圖像以查看清晰的視圖！
注意，這個僅僅是大系統的三分之一。 僅僅是三分之一。
畢竟，人家是年薪100W的offer。 其他的三分之二，沒有辦法露哈。
架構學問，也是藝術
架構師是學問，也是藝術。
架構師學問，這裏架構構師至少需要掌握網絡知識，硬件，軟件，架構理論、架構哲學等方方面面的知識：
-
硬件知識。CPU/硬盤/內存/物理網絡
-
軟件知識。操作系統/數據庫/應用服務器...。
-
通訊協議。TCP/IP/HTTP/MQTT....。
-
分佈式知識。
-
架構知識。 比如說尼恩的3高架構知識圖譜。
-
架構哲學。 比如尼恩的架構師哲學。
-
意志堅強。但不偏執。
-
善於溝通。但不花言巧語。
除此之外， 架構師在做方案的時候，有很大的發揮空間。
所以，架構師就是一位大廚， 當然，架構也是一門藝術。
回到此文，此文的目標和意義：主要是給前面說的那位小夥伴幫忙，助力的。
所以，接下來，梳理一下架構的36條黃金法則， 幫助他逐鹿100W年薪offer。
大家也可以收藏起來， 作爲自己做架構的參考資料。
架構的36條黃金法則
黃金法則1：演進式法則
“一個優秀的大型互聯網系統架構，不是設計出來的，而是不斷演進而來的” ，
架構的演進，其本質在於技術是服務於業務需求。
業務需求是不斷變化發展的，而這，天生就註定了技術架構的不斷演變，是一種必然的選擇。
一般來說， 演進的路線是： 單體架構-> 集羣架構-> 大型中臺化架構
1、單體架構
產品早期，通常是一些嘗試性的產品探索/試驗。
特點是： 用戶少、數據量小、吞吐量小、可用性要求低。
需要的是快速驗證，然後不斷收集用戶反饋，完善產品業務邏輯。
典型特點就是時效要求高、產品邏輯不夠完善、不確定性大。
在這一階段，對技術架構通常沒有太高的要求，只需要實現基本的業務功能就行，從而技術投入自然也就不大，因此，單節點架構是比較適合的。
2、集羣架構
隨着業務的發展，對系統的處理能力、高可用性也就提出了越來越高的要求.
這樣，系統就演進到了集羣架構階段。
在集羣架構階段，引入的技術/組件會慢慢變多，團隊成員也會逐漸壯大。
3、大型中臺化架構
爲解決系統重複建設、能力複用性低的問題，啓動了中臺化建設步伐。
中臺建設並非從零開始，前期已經積累了行業中多個場景的業務和技術的中臺能力。因系統建設的複雜，亟需一箇中臺大腦站在全局視角進行公司中臺能力的梳理和建設。
DDD建模流程、設計流程是 中臺化架構 的絕配。 通過引入新的建模流程，完成 中臺化的宏觀分析和架構建模。
Tips:
在雲服務廠商的支持下，集羣架構已經能夠支撐較大的用戶流量了。雲服務器、雲數據庫等雲端基礎服務的支撐能力，也比前些年要好了很多，升級擴容也方便了許多，已經足夠滿足一般規模下的系統性能需求了。所以，不要覺得業務量一上來，就立馬要改系統架構，因爲這反而可能帶來不必要的麻煩。有時，直接通過升級雲服務器/雲數據庫等的配置，就可以解決問題了。（通常來說，常規業務場景下，通過一些優化改造，頂住1萬以內的QPS是沒有太大問題的）。
具體請參見尼恩的《DDD學習聖經》
黃金法則2：先進性法則
使用先進的、主流的 架構方法論、架構思想、架構原則 ，去指導 項目的架構。
哲學上有一個天條：存在即合理。
先進的方法、理論、思想、原則 之所以先進， 必有某些優勢的地方， 所以需要吸納這些優勢，去指導項目的架構。
比如說這幾年 比較先進 的DDD架構、中臺化架構等等。
具體請參見尼恩的《DDD學習聖經》
黃金法則3：高併發 法則
高併發指的是系統同時處理很多請求。
例如：淘寶的雙11、春運時的搶票、微博大V的熱點新聞等。
高併發架構涉及到了 很多細分領域的架構，比如 緩存架構、異步架構、鏈路保護架構、自伸縮架構、、分庫分表架構等等。
具體請參見尼恩的《價值10W的3高架構知識圖譜》
黃金法則4：高可用 法則
高可用，英文單詞High Availability，縮寫HA，它是分佈式系統架構設計中一個重要的度量。
業界通常用多個9來衡量系統的可用性，如下表：
既然有可用率，有一定會存在不可用的情況。
不可用一般分爲有計劃的和無計劃的，有計劃的如日常維護、系統升級等，無計劃的如設備故障、突發斷電等。
我們對此作如下分類：
-
設備故障：機房斷電、硬盤損壞、交換機故障。
-
網絡故障：網絡帶寬擁堵、網絡連接中斷。
-
安全問題：利用系統漏洞進行網絡攻擊。
-
性能問題：CPU利用率太高、內存不足、磁盤IO過載、數據庫慢SQL。
-
升級維護：由於業務變更或技術改進而引起的系統升級。
-
系統問題：分佈式系統中存在服務的依賴而導致數據的不一致性，或是核心服務出現異常。
高可用包括 去掉IDC機房內部的 single of failure， 也包括 去掉 IDC機房之間的 single of failure，
去掉IDC機房內部的 single of failure，參見下面的案例
《美團面試：ES+Redis+MySQL高可用，如何實現？》
去掉 IDC機房之間的 single of failure，主要是異地多活
關於高可用的系統化介紹，請參見尼恩 《Java高併發核心編程卷3 加強版》
黃金法則5： 高性能法則
主要是無鎖化編程
比如 netty 就用了很多 無鎖化架構
具體，請參見尼恩的 netty 資源，包括《Java高併發核心編程卷1 加強版》和 《穿透Netty架構和源碼》視頻
比如 Disruptor也 就用了很多 無鎖化架構
具體，請參見尼恩的 Disruptor 視頻，
關於高性能法則的系統化介紹，請參見尼恩 《Java高併發核心編程卷3 加強版》
黃金法則6：高併發讀 架構法則
對於讀取操作量大的場景 ，使用緩存。
適當的場景，要使用三級緩存。
注意，要配套有 緩存的一致性架構。
具體，請參見 尼恩的 《三級緩存架構與實操》
黃金法則7：高併發寫架構法則
對於寫入量大的場景 ， 使用消息隊列進行異步處理。
具體請參見尼恩的 《Rocketmq四部曲》
黃金法則8：靜態資源緩存架構法則
對於靜態資源，
首先，進行動靜分離
然後，對於靜態資源，考慮Nginx文件緩存和 CDN。
黃金法則9：垂直擴展架構
垂直擴展架構的核心: 通過提升單節點的能力，線性擴充系統性能。
垂直擴展的方式又有兩種：
（1）增強單機硬件性能，例如：增加CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬盤如SSD，擴充硬盤容量如2T，擴充系統內存如128G；
（2）提升單機架構性能，例如：使用Cache來減少IO次數，使用異步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間；
單節點的潛力，有極限的。所以，解決單節點的 瓶頸，還是水平擴展。
黃金法則10：水平擴展架構
水平擴展架構的核心: 通過增加服務器數量，線性擴充系統性能。
水平擴展對系統架構設計是有要求的，如何在架構各層進行可水平擴展的設計。
DB的水平擴展：在數據量很大的情況下，DB涉及數據的水平擴展，將原本存儲在一臺服務器上的數據水平拆分到不同服務器上去，以達到擴充系統性能的目的。
redis的水平擴展：在數據量很大的情況下，使用redis Cluster 替代單節點的redis。
服務層的水平擴展： 使用分佈式的微服務架構，替代單體應用。
黃金法則11： 索引架構法則
高性能數據查詢，需要索引。
目前大多數流行的索引是基於B-Tree或LSM(Log Structured Merge) Tree這兩種數據結構來設計的。
- B-Tree
像Oracle、SQL Server、DB2、MySQL (InnoDB)和PostgreSQL這些傳統的關係數據庫依賴的底層存儲引擎是基於B-Tree開發的；
- LSM Tree
像Clickhouse、Cassandra、Elasticsearch (Lucene)、Google Bigtable、Apache HBase、LevelDB和RocksDB這些當前比較流行的NoSQL數據庫存儲引擎是基於LSM開發的。
兩種結構，使用與不同場景，當寫讀比例很大的時候（寫比讀多），LSM樹相比於B樹有更好的性能
- 插件式替換模式：
大部分中間件，想辦法兼容兩個場景，所以，會採用了插件式的存儲引擎架構，Server層和存儲層進行解耦。
所以，大部分中間件，同時支持多種存儲引擎。
比如，MySQL既可以支持B-Tree結構的InnoDB存儲引擎，還可以支持LSM結構的RocksDB存儲引擎。
比如，MongoDB採用了插件式存儲引擎架構，底層的WiredTiger存儲引擎還可以支持B-Tree和LSM兩種結構組織數據,但MongoDB在使用WiredTiger作爲存儲引擎時，目前默認配置是使用了B-Tree結構。
黃金法則12：事務性數據存儲架構法則
對於需要事務性的數據操作，也就是需要
- 𝐀原子性
- 𝐂一致性
- 𝐈隔離性
- D持久性
事務性數據操作架構場景，使用 RDBMS/SQL 數據庫。
黃金法則13：非結構化數據存儲架構法則
對於非強事務的數據操作，或者非結構化的文檔數據，使用NoSQL
注意Nosql的選型，具體請參見尼恩的博客文章
其中，有一個重要的文章，可以參考
黃金法則14： 複雜對象存儲架構法則
對於複雜的數據，比如文件、圖像、視頻、音頻等
選擇對象存儲，比如minio。
黃金法則15：高性能搜索的架構法則
如果是海量數據需要全文搜索，需要使用搜索索引，比如ElasticSearch。
這時候，需要考慮全量數據和ElasticSearch的數據一致性問題。
黃金法則16：海量結構化數據的擴展架構
億級庫表規模架構設計
百億級庫表架構設計
具體，請參見尼恩 《Java高併發核心編程卷3 加強版》
黃金法則17：圖形數據存儲架構
圖形數據（具有節點、邊和關係的數據）存儲場景，利用圖形數據庫，比如neo4j。
其實用起來很簡單，尼恩在數據中臺架構中，用neo4j 存儲過數據血緣。
黃金法則18：時序數據存儲架構
對於與時間序列有關的數據，比如iot監控數據、系統監控數據（如Prometheus），需要用到時序數據存儲
時序數據庫全稱爲時間序列數據庫。時間序列數據庫指主要用於處理帶時間標籤（按照時間的順序變化，即時間序列化）的數據，帶時間標籤的數據也稱爲時間序列數據。與傳統的關係型數據庫不同，時序數據庫能夠高效地處理大量時間序列數據，適用於各種領域和應用場景，如物聯網、金融市場、工業監控等。
類似的一些比較常見的框架：
-
InfluxDB：一個流數據平臺，專注於存儲、查詢和分析大規模、高維度的數據。它支持 SQL 查詢和 InfluxQL 查詢，可以多維度的對數據進行可視化和分析。
-
TimescaleDB：一個開源的關係型數據庫，支持高效、高可擴展的時序數據存儲和高級時序數據分析。
-
OpenTSDB：一個分佈式的時序數據存儲系統，支持海量數據存儲，並提供了大量的數據查詢API和數據可視化選項。
-
CrateDB：新興的開源分佈式 SQL 數據庫，具有高可擴展性和高速度，目前已成爲處理實時數據的優選解決方案之一。
黃金法則19：隊列緩衝+批處理法則
在高併發場景，可以用隊列對數據進行緩衝， 然後通過異步批處理的模式，提升性能。
比如 Netty源碼中的隊列緩衝+批處理架構
比如 消息隊列寫入場景的隊列緩衝+批處理架構
比如 DB寫入場景的隊列緩衝+批處理架構
黃金法則20：預加載架構
預加載是一種常見的優化技術，它可以提高程序的性能和響應速度。
預加載，指的是預先加載對象或資源到內存中，以便在程序執行過程中能夠更快地訪問這些對象或資源。
通過預加載，可以避免在程序運行過程中頻繁地加載對象，從而提高程序的性能和響應速度。
預加載的場景
-
比如hotkey的緩存預加載
-
比如一些耗時的資源可以預加載，比如數據庫連接、文件等，以便在程序執行過程中能夠更快地訪問這些資源。
單例模式的 餓漢子模式，就屬於 預加載架構的內存
具體請參見尼恩的《Java高併發核心編程卷2》
黃金法則21：懶加載架構
延遲加載是指在第一次訪問對象時，或在第一次使用資源時再加載，而不是在程序啓動時就加載。
延遲加載可以減少程序啓動時間，並在真正需要使用對象或資源時才進行加載。
比如經典的CachAside 模式，就屬於懶加載架構
CachAside 模式，請參見尼恩的《Java高併發核心編程卷3 加強版》
比如經典的DCL 雙檢鎖，就屬於懶加載架構
DCL 雙檢鎖，請參見尼恩的《Java高併發核心編程卷2 加強版》
黃金法則22：單一責任原則（SRP）
SRP是微服務架構重要的原則。
每個微服務都應該負責一個單一的業務，並確保做好這個業務，這個業務粒度的大小取決於你對業務和架構綜合考慮。
SRP能夠確保微服務職責單一性、功能完整性拆分， 這樣，就便於維護、測試和部署。
注意：請點擊圖像以查看清晰的視圖！
黃金法則23：松耦合原則
什麼事松耦合：松耦合是指每個微服務都應該是獨立的，並通過API與其他服務進行通信。
松耦合的優勢：可以降低 級聯故障 的風險，也可以提高服務可擴展性，提高微服務的可複用性。
儘量做徹底解耦，包含數據庫層的解耦：
- 數據庫層的解耦，就是避免一個微服務與其他微服務共享數據庫，因爲這可能會導致數據不一致，並且會使故障排查變得非常困難。
- 每個微服務也都應該只管理自己的數據，每個微服務都有自己的數據庫來存儲數據，以確保可擴展性和可靠性。
在設計微服務時，應該專注於創建小型、鬆散耦合和高度內聚的服務。
注意：請點擊圖像以查看清晰的視圖！
黃金法則24：領域驅動原則，不數據驅動原則，也不是界面驅動原則
DDD是一種軟件設計方法，它專注於特定業務領域的軟件設計。
微服務架構、微服務設計非常適合採用DDD，爲啥呢？
因爲每個服務都可以設計爲特定業務領域的具體實現。
注意：請點擊圖像以查看清晰的視圖！
領域驅動設計，首先應建立領域模型，確定領域限界上下文，然後才進行微服務拆分，
如果是 數據驅動原則/界面驅動原則 ，那麼，是一上來就定義數據庫表結構，就去調整領域邏輯代碼。
領域模型和領域服務應具有高度通用性、穩定性，通過接口層和應用層屏蔽外部變化對業務邏輯的影響，保證核心業務功能的穩定性。
基於領域模型進行拆分，圍繞業務領域按職責單一性、功能完整性拆分。
黃金法則25：架構分層職責明確，嚴守調用規範，規避 “微服務小泥球”
老的單體架構， 常常被成爲大泥球。
“大泥球”單體，主要的問題：
- 代碼腐化：業務代碼經過長時間的迭代，有很多重複代碼。比如一個功能可能有 3,4 種實現。
- 業務邏輯交織：業務應用經過長時間發展，功能變多，業務功能裏的邏輯代碼可能相互引用，交織不清。
- 代碼複雜：功能多，業務邏輯複雜，只有少數員工能理解。這也是代碼腐化一種。
- 維護性變差：修改 bug 或增加新功能時，牽一髮而動全身。一個 bug 沒修好可能導致整個軟件不可用。
- 擴展性變差：增加新功能時，牽一髮而動全身。
- 編譯發佈變長：軟件代碼量大，編譯時長變長，導致發佈時長也變長。
化解“大泥球”單體的措施，是微服務架構。微服務架構最基本的一個點：分而治之，由大化小。
- 松耦合：劃分爲一個一個小的微服務，代碼之間邏輯交織降低。
- 獨立部署：每個劃分的微服務都是一個獨立的項目，可以獨立部署。
- 編譯發佈改善：劃分爲獨立的小項目，編譯時長變短，發佈時長相應變短。
- 故障隔離：由於劃分爲一個一個微服務，故障僅發生在獨立的微服內。
- 可擴展性：每個服務可以獨立橫向擴展，也可以從應用程序中提出獨立功能變成服務，擴展變強。
- 職責單一團隊：每個小的微服務都由一個小型的高度專注的團隊負責。
- 技術異構：每個團隊可以選擇適合該業務的技術。
微服務架構目的就是把一個大單體劃分爲各種微服務，松耦合，獨立自治。
微服務架構把一個大泥球，變成了很多個小而美的顆粒。
每個小顆粒職責單一，邊界明確，可以通過簡單組裝完成大的功能，自然就比之前的大泥球好處理得多
但是，迭代過程中，出現了一種奇怪現象，微服務內部沒有進行內部的模塊劃分，代碼耦合嚴重，調用關係混亂，就像一個小泥球。
在騰訊視頻的DDD重構案例中，在老的微服務架構中，存在分層不明確，下層服務過於理解業務邏輯，存在下層調用上層的問題，出現了代碼耦合嚴重，調用關係混亂的 “微服務小泥球”。
具體請參考《DDD落地：從騰訊視頻DDD重構之路，看DDD極大價值》
在騰訊視頻的DDD重構的過程中，明確架構分層，降低模塊間不必要的耦合；
嚴格遵守分層架構原則，上層服務可調用下層服務，下層服務不涉及業務邏輯。如上下層服務需交互，可通過邏輯解耦方式實現，如消息隊列或中轉。
如果規避 “微服務小泥球”？各層職能定位清晰，只能上層調用下層，也就是說只能從外層調用內層服務，下層服務通過封裝、組合或編排對上層暴露，服務粒度由細到粗。
微服中，各層職能定位清晰：
- 基礎層爲各層提供資源服務
- 領域層負責領域業務邏輯的實現
- 應用層負責服務的編排和組合
- 接口層對外進行服務暴露
注意：請點擊圖像以查看清晰的視圖！
黃金法則26：進行全方位的監控、記錄
監控和日誌記錄對於微服務架構的安全、維護和調優都至關重要。
在擁有數百個微服務的項目中開發的主要困難之一是調試非常困難，因爲服務分散、日誌分散，很難找到失敗的原因。
因此，每個服務都應該有日誌記錄和監控措施，以跟蹤其性能並檢測錯誤。
注意：請點擊圖像以查看清晰的視圖！
黃金法則27：開發運維一體化法則
CI/CD是一種軟件開發運維過程實踐，打通開發和運維環節，實現應用程序的構建、測試和部署自動化。
任何微服務都應該是可持續部署的，實現微服務的快速高效部署，縮短了微服務上線時間。
注意：請點擊圖像以查看清晰的視圖！
總之，採用微服務架構開發有許多優勢，但要確保爲微服務系統成功實施就需要遵循一些設計原則。
包括但不限於上面介紹的幾個基礎原則，在此基礎上還需要有與所在領域或者行業的做定製化優化實踐。
黃金法則28： API 網關法則
API 網關是伴隨着微服務架構一同引入的基礎設施。
一般來說，隨着服務化在公司內的迅速推進，網關逐步成爲應用程序暴露在外網的標準解決方案。
前面，已經梳理了下面的經典案例：
- 《日均數十億訪問，個推API網關如何架構？》
- 《工業級Netty網關，京東是如何架構的？》
- 《2億用戶，B站API網關如何架構？》
- 《100萬級連接，石墨文檔WebSocket網關如何架構？》
- 《單體120萬連接，小愛網關如何架構？》
- 《億級長連接，淘寶接入層網關的架構設計》
- 《100萬級連接，愛奇藝WebSocket網關如何架構》
- 《日200億次調用，喜馬拉雅網關的架構設計》
- 《千萬級連接，知乎如何架構長連接網關？》
- 《日流量200億，攜程網關的架構設計》
黃金法則29： 冗餘法則
單點故障是指在一個系統中出現的只有一個組件或節點導致整個系統停止工作或無法正常運行的情況。
當系統中的某個關鍵組件或節點發生故障時，可能會引發連鎖反應，導致整個系統崩潰或無法提供正常的服務。
單點故障是系統中的薄弱環節，其發生故障的概率相對較高。
在計算機網絡、電力系統、交通運輸系統等各個領域都存在單點故障的風險。一旦發生單點故障，可能會導致系統停止運行，造成重大的經濟損失和社會影響。
單點故障可以發生在硬件層面，如計算機服務器、網絡交換機等設備發生故障；
單點故障也可以發生在軟件層面，如程序運行錯誤、數據庫崩潰等。此外，還有可能是人爲因素導致的單點故障，如誤操作、管理失誤等。
爲了避免單點故障對系統造成的影響，核心是 冗餘法則。
冗餘法則，也就是冗餘設計，即在系統中引入冗餘組件或節點，當一個組件或節點發生故障時，可以自動切換到備用組件或節點，保證系統的連續可用性。
總之，單點故障是系統中非常重要但相對薄弱的環節，一旦發生故障可能會對整個系統造成嚴重影響。
因此，必須重視並採取相應的措施來預防和應對單點故障的發生，確保系統的穩定運行和連續可用性。
黃金法則30： 數據容錯法則
數據容錯：讓錯誤不再蔓延
數據容錯是指通過技術手段，避免因硬件故障、軟件錯誤、人爲操作失誤等原因導致的數據錯誤。、
常見的數據容錯方法包括冗餘技術、校驗和檢查、自動恢復技術等。
（1）冗餘技術：通過在系統中添加額外的硬件或軟件組件，提高系統的可靠性。例如，使用雙電源、雙硬盤等，確保在某個部件發生故障時，系統仍能正常運行。
（2）校驗和檢查：通過計算數據的校驗和，在數據傳輸或存儲過程中進行檢查。如果數據發生錯誤，可以通過校驗和及時發現並糾正。
（3）自動恢復技術：通過備份和恢復系統中的數據，確保在發生故障時能迅速恢復數據。例如，使用RAID技術、定期備份數據等。
黃金法則31：數據容災法則
數據容災：未雨綢繆，災難無虞
數據容災是指在災難發生時，通過技術手段和備份策略，確保數據不會丟失或損壞。
常見的數據容災方法包括遠程備份、數據快照、鏡像複製等。
（1）遠程備份：在遠離災難發生地的位置備份數據，確保在災難發生時數據不會丟失。同時，要定期測試備份數據的可訪問性和完整性。
（2）數據快照：通過定時拍攝數據快照，記錄數據的最新狀態。在災難發生時，可以通過回滾到快照時間點的狀態，迅速恢復數據。
（3）鏡像複製：將數據複製到遠程站點，確保在災難發生時可以通過遠程站點快速恢復數據。同時，要確保複製數據的同步性和完整性。
黃金法則30： 心跳法則
分佈式心跳機制是着重使用於分佈式系統中，主要是爲了確保系統中的各個節點狀態保持高可用性，保證系統的正常運行。
心跳機制的主要功能就是短時間內確認對方的存活狀態，使用心跳機制就可以簡單實現各個節點的狀態信息的可靠傳輸，避免無用的信息流傳遞，從而提高系統的效率。
心跳機制主要包括兩部分：發送端發送心跳信號、接收端接收心跳信號，當接收端收到發送端發送的心跳信號時，進行確認，從而保證信號的傳輸的可靠性；發送端沒有收到接收端的確認，則可以重複發送心跳信號，提高系統的可用性。
黃金法則32：限流法則
限流在很多場景中用來限制併發和請求量，比如說秒殺搶購，保護自身系統和下游系統不被巨型流量沖垮等。
以微博爲例，例如某某明星公佈了戀情，訪問從平時的50萬增加到了500萬，系統的規劃能力，最多可以支撐200萬訪問，那麼就要執行限流規則，保證是一個可用的狀態，不至於服務器崩潰，所有請求不可用。
限流：計數器、漏桶、令牌桶 三大算法的原理與實戰（史上最全）
黃金法則33：熔斷法則
具體參見 《尼恩Java高併發核心卷3》
黃金法則34：隔離架構
隔離架構的一個典型案例，如艙壁模式
具體參見 《尼恩Java高併發核心卷3》
黃金法則34：一致性hash
分治模式在存儲領域的使用：數據分⽚
數據分⽚指按照某個維度將存放在單⼀數據庫中的數據， 分散地存放⾄多個數據庫或表中以達到提升性能瓶頸以及可⽤性的效果。
主要的分片算法
- range 分片
- ID取模分片
- hash 哈希分佈
- 一致性hash
range 分片
一種是按照 range 來分，就是每個片，一段連續的數據，這個一般是按比如時間範圍/數據範圍來的，但是這種一般較少用，因爲很容易發生數據傾斜，大量的流量都打在最新的數據上了。
比如，安裝數據範圍分片，把1到100個數字，要保存在3個節點上
按照順序分片，把數據平均分配三個節點上
- 1號到33號數據保存到節點1上
- 34號到66號數據保存到節點2上
- 67號到100號數據保存到節點3上
ID取模分片
此種分片規則將數據分成n份（通常dn節點也爲n），從而將數據均勻的分佈於各個表中，或者各節點上。
擴容方便。
ID取模分片常用在關係型數據庫的設計
具體請參見 秒殺視頻的 億級庫表架構設計
hash 哈希分佈
使用hash 算法，獲取key的哈希結果，再按照規則進行分片，這樣可以保證數據被打散，同時保證數據分佈的比較均勻
哈希分佈方式分爲三個分片方式：
- 哈希取餘分片
- 一致性哈希分片
- 虛擬槽分片
哈希取餘模分片
例如1到100個數字，對每個數字進行哈希運算，然後對每個數的哈希結果除以節點數進行取餘，餘數爲1則保存在第1個節點上，餘數爲2則保存在第2個節點上，餘數爲0則保存在第3個節點，這樣可以保證數據被打散，同時保證數據分佈的比較均勻
比如有100個數據，對每個數據進行hash運算之後，與節點數進行取餘運算，根據餘數不同保存在不同的節點上
哈希取餘分片是非常簡單的一種分片方式
哈希取餘分片優點：
- 配置簡單：對數據進行哈希，然後取餘
哈希取餘分片缺點：
- 數據節點伸縮時，導致數據遷移
- 遷移數量和添加節點數據有關，建議翻倍擴容
一致性哈希分片
一致性哈希原理：
將所有的數據當做一個token環，
token環中的數據範圍是0到2的32次方。
然後爲每一個數據節點分配一個token範圍值，這個節點就負責保存這個範圍內的數據。
對每一個key進行hash運算，被哈希後的結果在哪個token的範圍內，則按順時針去找最近的節點，這個key將會被保存在這個節點上。
一致性哈希分片的節點擴容
在下面的圖中：
- 有4個key被hash之後的值在在n1節點和n2節點之間，按照順時針規則，這4個key都會被保存在n2節點上
- 如果在n1節點和n2節點之間添加n5節點，當下次有key被hash之後的值在n1節點和n5節點之間，這些key就會被保存在n5節點上面了
下圖的例子裏，添加n5節點之後：
- 數據遷移會在n1節點和n2節點之間進行
- n3節點和n4節點不受影響
- 數據遷移範圍被縮小很多
同理，如果有1000個節點，此時添加一個節點，受影響的節點範圍最多隻有千分之2。所以，一致性哈希一般用在節點比較多的時候，節點越多，擴容時受影響的節點範圍越少
分片方式：哈希 + 順時針(優化取餘)
一致性哈希分片優點：
- 一致性哈希算法解決了分佈式下數據分佈問題。比如在緩存系統中，通過一致性哈希算法把緩存鍵映射到不同的節點上，由於算法中虛擬節點的存在，哈希結果一般情況下比較均勻。
- 節點伸縮時，隻影響鄰近節點，但是還是有數據遷移
“但沒有一種解決方案是銀彈，能適用於任何場景。所以實踐中一致性哈希算法有哪些缺陷，或者有哪些場景不適用呢？”
一致性哈希分片缺點：
一致性哈希在大批量的數據場景下負載更加均衡，但是在數據規模小的場景下，會出現單位時間內某個節點完全空閒的情況出現。
黃金法則35：Gossip 協議 法則
gossip協議，顧名思義，就像流言蜚語一樣，利用一種隨機、帶有傳染性的方式，將信息傳播到整個網絡中，並在一定時間內，使得系統內的所有節點數據一致。
去中心化的通訊場景，可以使用Gossip 協議。
Gossip是一種去中心化思路的分佈式協議，解決信息在集羣中的傳播和最終一致性。
黃金法則36：WebSocket推送 法則
服務端向客戶端的推送，使用WebSocket
最好使用Netty假設WEBSocket 服務器，單節點支持100W連接
黃金法則37：內存池 法則
內存池(Memory Pool)是一種內存分配方式。
內存池則是在真正使用內存之前，先申請分配一定數量的、大小相等(一般情況下)的內存塊留作備用。當有新的內存需求時，就從內存池中分出一部分內存塊，若內存塊不夠再繼續申請新的內存。這樣做的一個顯著優點是儘量避免了內存碎片，使得內存分配效率得到提升。
具體 參見Netty 內存池、 Golang 中的內存池
黃金法則38：對象池 法則
如果一個類被頻繁請求使用，那麼不必每次都生成一個實例，可以將這個類都一些實例保存到一個“池”中，待需要使用的時候直接從“池”中獲取。
這個“池”就被稱爲對象池，它可以是一個數組，一個鏈表或者任何集合。
對象池其實就是一個集合，裏面包含了我們需要的對象集合，當然這些對象都被池化了，也就是被對象池所管理，想要這樣的對象，從池子裏取個就行，但是用完得歸還。
對象池的對象最好是創建比較費時的大對象。
如果是太簡單的對象，再進入池化的時間比自己構建還多，就不划算了。但是對於有些對象來說，其創建的代價還是比較昂貴的，比如線程、tcp連接、rpc連接、數據庫連接等對象，因此對象池技術還是有其存在的意義。
在程序中使用數據庫連接池和線程池，可以理解爲一種特殊的對象池， 可以有效的改善系統在高併發下的性能，這是兩個非常重要的性能組件，任何對性能敏感的系統，都需要考慮合理配置這兩個組件。
Apache 的commons-pool是一個通用的開源"對象池"組件,即通過一定的規則來維護對象集合的容器; 大家常用的dbcp數據庫連接池,也是基於commons-pool實現.
commons-pool實現思想非常簡單,它主要的作用就是將對象集合池化,任何通過pool進行對象存取的操作,都會嚴格按照pool配置(比如池的大小)實時的創建對象/阻塞控制/銷燬對象等.
commons-pool 實現了對象集合的管理以及對象的分發.
- 將創建對象的方式,使用工廠模式;
- 通過"pool配置"來約束對象存取的時機
- 將對象列表保存在隊列中(
LinkedList)
另外，Netty 也提供了自己的 對象池實現， 尼恩在第35章視頻中，會給大家做系統化，體系化的介紹。
黃金法則39：CAP法則
分佈式系統中有一個重要理論：CAP。
-
C：一致性（Consistency）
在分佈式系統中，數據會在多個副本中存在，一些問題可能導致在寫入數據時，部分副本成功，部分副本失敗，從而導致數據不一致。一致性 C 的要求是，數據更新操作成功後，多個副本的數據必須保持一致。
-
A：可用性（Availability）
無論何時，客戶端對集羣進行讀寫操作，請求都應能得到正常的響應。
-
P：分區容錯性（Partition Tolerance）
當發生通信故障，集羣被分割成多個無法通信的分區時，集羣仍應能正常運行。
CAP的一個重要結論：AP、CP 是不能同時滿足的，這是鐵律。
黃金法則40：最終一致性
AP、CP 是不能同時滿足的，這是鐵律。
AP、CP的權衡——最終一致性。
往往爲了AP，忍痛放棄強一致支持，轉而追求最終一致性。
大部分業務場景下，我們是可以接受短暫的不一致的。
說在最後：有問題找老架構取經
以上的內容，如果大家能對答如流，如數家珍，基本上 面試官會被你 震驚到、吸引到。
最終，讓面試官愛到 “不能自已、口水直流”。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：
