讀釋出！設計與部署穩定的分布式系統2版筆記25_互聯層路由和服務

1. 控制請求數量

1.1. 這個世界可以随時摧毀我們的系統

1.1.1. 要麼拒絕工作

1.1.2. 要麼擴充容量

1.1.3. 沒有人會在與世隔絕的環境中使用服務，現在的服務大多必須處理網際網路規模的負載

1.2. 系統的每次失效，都源自某個等待隊列

1.3. 每個請求都會在它所經過的每一層上占用一個套接字，當請求被執行個體處理後，該執行個體就臨時少了一個處理其他新請求的套接字

1.4. 可用套接字數量與服務每秒可以處理的請求數量之間存在一定關系，這取決于請求處理的持續時間

1.5. 服務完成請求處理的速度越快，其可處理的吞吐量就越高

1.6. 以太網本質上就是一個串行協定

1.6.1. 把資料包“放到”導線上需要時間，在端口繁忙時，任何待發送的資料包都必須排隊

1.6.2. 當寫入緩沖區已滿時，TCP協定棧将不會接受任何新的寫入，并且write調用将被阻塞

1.7. 伺服器套接字上的“監聽隊列”

1.7.1. 如果監聽隊列已滿，那麼嘗試連接配接的用戶端會進行一系列的重試，最終放棄連接配接

1.8. 甩負載

1.8.1. 是控制傳入請求數量的首要方式

1.8.2. 在高負載情況下最好把那些無法及時完成的工作“擋在門外”

1.8.3. 當套接字監聽隊列已滿時，就可以快速進行甩負載，快速拒絕勝于慢速逾時

1.8.4. 盡可能在網絡的邊緣拒絕額外的請求

1.8.4.1. 能盡早甩負載，進而避免在拒絕請求之前就已經占滿多個層級上的資源

1.8.4.2. 請求進入系統越深，占用的資源就越多

1.8.5. 提供健康狀況檢查，允許負載均衡器保護應用程式

1.8.6. 服務可以通過度量自身響應時間，來協助解決高負載的問題

1.8.6.1. 檢查自身的運維狀态，檢視是否能及時回複請求

1.8.7. 在因響應時間過長引發通路重試時，開始拒絕請求

1.8.8. 服務也應該有相對較短的監聽隊列

1.8.8.1. 每個請求都會在監聽隊列中等待一些時間，并花一些時間進行處理，稱這兩個時間之和為“駐留時間”

1.8.8.2. 監聽隊列是串行的，而處理是多線程的，是以排隊時間最終會比處理時間要長

1.8.9. 需要知道該服務是直接面向網際網路（适用于所有實用場景，請求數量無限），還是僅向内部開放（請求數量有限）

1.9. TIME WAIT

1.9.1. 關閉的套接字會在TIME_WAIT狀态下保持一段時間，來讓所有在網際網路上遊蕩的“掉隊”的包逾時，或在其到達時被丢棄

1.9.2. 由于目前用戶端并沒有發送這些資料，是以導緻TCP流不再同步。這樣的資料包就被稱為bogon

1.9.2.1. IME_WAIT則可以防止系統出現這種情況

2. 網絡路由

2.1. 伺服器必須要知道使用哪個接口才能通路特定的目标IP位址

2.1.1. 伺服器的前端網絡接口接入一個虛拟區域網路與Web伺服器通信

2.1.2. 伺服器的後端網絡接口接入另一個虛拟區域網路與資料庫伺服器通信

2.1.3. 當涉及遠端服務時（可能是第三方服務），路由就會變得更複雜

2.2. 現代作業系統力圖使路由自動發生且不可見

2.2.1. 當一台伺服器啟動其主網卡時（隻要作業系統認定其為主網卡），會将該網卡的主IP位址當作其“預設網關”，并将這個網關作為這台主機的路由表中的第一個條目

2.3. 總會出現的錯誤比間歇性的成功要好得多

2.4. 靜态路由定義

2.4.1. 網絡管理者對外都不贊同使用靜态路由，但有時這是唯一可行的方法

2.5. 軟體定義網絡

2.5.1. 與虛拟化基礎設施和基于容器的基礎設施密切相關

2.5.2. 容器和虛拟機使用虛拟IP位址、虛拟區域網路标記和虛拟交換機來建立一種“網絡上的網絡”

2.5.3. 資料包仍然在相同的網線上流動，但主機的IP位址不再牽涉其中，這就實作了虛拟交換機在實體交換機之外獨立運維

2.6. 錯誤地配置路由，不僅會降低系統的可用性，還會洩露客戶資料

2.7. 所有遠端系統連接配接都應該使用電子表格或資料庫來記錄目标主機名字、位址和所需路由

2.7.1. 有人會需要這些資訊來編寫防火牆規則

3. 發現服務

3.1. 組織有太多的服務，使用DNS管理

3.2. 部署環境高度活躍

3.3. 調用方至少需要知道一個IP位址，才能通路某個特定服務

3.4. 可以在分布式資料存儲（例如Apache ZooKeeper或etcd）上建立服務發現機制

4. 遷移虛拟IP位址

4.1. 虛拟IP位址意味着一個IP位址不會與一個以太網MAC位址嚴格綁定

4.2. 負載均衡器會使用虛拟IP位址将多個服務（每個都有自己的IP位址）複用到數量較少的實體接口上

4.3. IP位址的遷移通常用于通過主動方式和被動方式實作的資料庫叢集

4.3.1. 不能遷移應用程式記憶體中的狀态

4.3.2. 所有非持久化的互動狀态都将丢失

4.3.3. 任何通過虛拟IP位址調用資料庫的應用程式，都應做好在發生此類故障轉移時收到SQLException的“心理準備”