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的“心理準備”