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物件通過切斷所有外部連接改進單元測驗的隔離性，通常在系統層級之間的邊界處使用
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556355.html
標籤：架構設計
上一篇：教你如何用Vue3搭配Spring Framework
下一篇：返回列表