1. 完全的解耦
1.1. 各臺服務器、層級和應用程式解耦得越徹底，集成點、層疊失效、回應緩慢和執行緒阻塞等問題就越少
1.2. 應用程式解耦后，系統可以單獨更改其他應用程式的所有配件，因此也更具適應性
2. 中間件
2.1. 在極其雜亂無章的環境中，集成原本就不在一起作業的系統
2.2. 中間件既可以做到將其集成，又可以做到將其解耦
2.3. 由于集成點是導致系統不穩定的首要原因，因此“既可集成，又能解耦”是件好事
2.4. 松耦合的中間件允許呼叫系統和接收系統在不同的地點和時間處理訊息
2.4.1. IBM MQSeries
2.4.2. 所有基于佇列或發布-訂閱機制的訊息傳遞系統
2.4.3. 實作系統間訊息傳遞的SMTP或SMS系統
2.4.3.1. SMTP和SMS系統通常由人（而不是服務器）充當訊息代理，且系統延遲往往很高
2.5. 面向訊息的中間件，在空間和時間上實作端點解耦
2.5.1. 發出請求的系統不會“坐等回復”
2.5.2. 不會導致層疊失效
2.6. 從同步的“請求-回復”到異步的通信方式的轉變，需要完全不同的設計
2.6.1. 需要考慮轉換成本
2.6.2. 中間件解耦是架構決策
2.6.2.1. 相關的實施會波及系統的每個部分
2.6.3. 應該在最后責任時刻到來時，盡早做出這種幾乎不可逆轉的決策
3. 背壓機制
3.1. 每個性能問題都源于其背后的一個等待佇列
3.1.1. 套接字的監聽佇列
3.1.2. 作業系統的運行佇列
3.1.3. 資料庫的I/O佇列
3.2. 如果佇列無限長，那么它就會耗盡所有可用的記憶體
3.3. 隨著佇列長度的增加，完成佇列中某項作業的時間也會增加
3.3.1. 當佇列長度達到無窮大時，回應時間也會趨向無窮大
3.4. 要想獲得有限的回應時間，就需要構建有限長度的等待佇列
3.5. 如果佇列的長度是有限的，那么當佇列已滿且生產者仍試圖再塞入一個新請求時，必須立刻采取應對措施
3.5.1. 假裝接受新請求，但實際上將其拋棄
3.5.2. 確實接受新請求，但拋棄佇列中的某一個請求
3.5.2.1. 隨著時間的推移價值迅速降低的資料，拋棄佇列中最先發出的請求可能是最佳選擇
3.5.3. 拒絕新請求
3.5.4. 阻塞生產者，直至佇列出現空的位置
3.5.4.1. 一種流量控制手段，允許佇列向發送資料包的上游系統實施“背壓”措施
3.5.4.2. 消費者必須當心，不要永久阻塞
3.6. TCP在每個資料包中都采用額外的欄位構建背壓機制
3.6.1. 來自TCP接收方視窗的背壓，會讓發送方填滿其發送緩沖區，這時后續寫入套接字的呼叫將被阻塞
3.7. 背壓機制通過讓消費者放慢作業來實作安全性
3.8. 背壓機制會導致執行緒阻塞
3.9. 背壓機制最適合異步呼叫和編程
3.9.1. Rx框架、actor或channel工具實作這個機制
3.10. 在系統邊界內運用背壓機制效果最好
3.10.1. 在系統邊界之間，還是需要使用卸下負載模式和異步呼叫
4. 卸下負載
4.1. 服務、微服務、網站和開放式API都有一個共同特點：無法控制其需求量
4.1.1. 總能對某個系統施加超出其處理能力的負載
4.2. 服務應該模仿TCP的做法
4.2.1. 當負載過高時，就開始拒絕新的作業請求
4.2.2. 當請求花費的時間超過SLA規定的回應時長時，就可以卸下一些負載
4.2.2.1. 讓系統的回應時間得到控制，而不是任其讓呼叫方超時
4.3. 將負載均衡器用作減震器
4.4. 運用背壓機制會更有效
5. 自動化機制
5.1. 自動化機制缺乏判斷能力，一旦出錯，就錯得驚人
5.2. 自動化機制處理人類不擅長的事情
5.2.1. 重復的任務和快速的回應
5.3. 自動化機制不擅長的事情
5.3.1. 自動化機制不擅長的事情
6. 調速器
6.1. 使用調速器限制發動機的速度，即使動力源可以更快地驅動，調速器也可以防止它以不安全的轉速運轉
6.2. 調速器可以感知狀態和時間，知道一段時間以來自身執行的操作
6.3. 調速器往往是不對稱的
6.3.1. 在不安全的方向上施加阻力
6.3.2. 一旦超出范圍，就可以運用調速器增加操作阻力
6.4. 使用調速器的意義在于放緩做事的速度，以便人工干預
6.4.1. 需要監控回應曲線的兩端，當有情況發生時能夠提醒人們，并給他們足夠的可視化資訊理解所發生的事情
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556512.html
標籤：架構設計
下一篇：返回列表