1. 握手

1.1. 發送方和接收方之間的信號傳遞過程

1.2. 模擬數據機使用一種握手形式，協商兩個設備都能接受的速度和信號編碼

1.3. TCP使用三次握手建立套接字連接

1.4. TCP握手還允許接收方發信號告訴發送方：在接收方準備好之前不要發送數據

1.5. EIA-232C（以前稱為RS-232）的串列協議，是從接收方那裡知道它何時能準備好接收數據

1.6. 握手在低層通信協議中無處不在，但幾乎很少出現在應用程式層

1.7. 握手是一種未被充分利用的技術，在應用層協議中擁有巨大的優勢

1.7.1. HTTP並不擅長握手

2. 創建基於合作的需求控制機制

2.1. 客戶端和伺服器之間的握手，允許將需求的流量調節到可服務的級別

2.2. 在構建客戶端和伺服器時，兩者都必須實現握手

2.3. 讓伺服器通過限制自己的工作量保護自己

2.3.1. 伺服器應該有辦法拒絕執行發來的工作，而不是成為滿足任何要求的“受氣包”

2.3.2. 基於HTTP的伺服器需要依賴負載均衡器與Web伺服器或應用程式伺服器之間的合作關係實現“握手”

3. 健康狀況檢查

3.1. 在集群或負載均衡服務中，使用健康狀況檢查實現實例與負載均衡器握手

3.2. 當失衡的系統容量導致響應緩慢時，“握手”可能是最有價值的

3.3. 當調用缺乏握手機制的服務時，斷路器是一種可以使用的權宜之計

3.4. 在層疊失效情況下，握手是一種防止裂紋跨層蔓延的有效方法

4. 在自己的低層協議中構建握手

4.1. 如果創建了基於套接字的協議，那麼可以在其中構建握手機制

4.2. 端點就可以在未準備好接受工作時，通知其他端點

5. 考驗機

5.1. 分散式系統的失效方式很難在開發環境或QA環境中顯現

5.2. 可以創建考驗機來模擬每個集成點另一端的遠程系統

5.2.1. 硬體工程師和機械工程師一直使用考驗機

5.2.2. 軟體工程師雖然也已經在使用，但其考驗機過於簡單

5.2.3. 像設計應用程式伺服器一樣來設計考驗機，其中與真實應用程式相關的那些測試，可以設計為可插拔的形式

5.3. 優秀的考驗機嚴格測試系統，像現實世界的系統一樣“惡毒”

5.4. 考驗機應該給被測系統留下“傷疤”，它的意義就是讓被測系統做到不信有好事

5.4.1. 考驗機應該像一個小“黑客”，嘗試各種不良行為來給調用方搞破壞

5.5. 考驗機會引出混沌工程

5.6. 考驗機作為一臺單獨的伺服器運行，沒有義務遵循任何介面規範，可以激髮網絡錯誤、協議錯誤或應用程式級錯誤

5.6.1. 每個系統最終都會偏離介面規範，因此在遠程系統無法使用時，測試本地系統的行為就變得至關重要

5.6.2. 模擬偏離介面規範的系統失效方式

5.7. 遠程調用使用網路，套接字連接容易出現的失效

5.7.1. 網路傳輸問題

5.7.2. 網路協議問題

5.7.3. 應用程式協議問題

5.7.4. 應用程式邏輯問題

5.8. 考驗機知道其存在的意義是且僅是進行測試

5.8.1. 真正的應用程式不會直接調用低層網路API，但考驗機可以

5.8.2. 其位元組發送速度能快能慢

5.8.3. 能建立極長的監聽隊列

5.8.4. 能與套接字綁定卻從不發起連接

5.9. 考驗機僅是補充，不能取代其他測試方法

5.10. 考驗機有助於驗證非功能性行為，同時又與遠程系統保持隔離

6. mock對象

6.1. mock對象只能產生符合已定義介面的行為

6.2. mock對象通過切斷所有外部連接改進單元測試的隔離性，通常在系統層級之間的邊界處使用