最近又把RPC框架的底層協議翻出來回顧了一遍，梳理一下有什麼可以學習和借鑑的地方，重點看了一下RPC連線的實現方案。看了之後，覺得可以談談服務間連線的方式及區別，所以按照自己的理解寫了一下。
(圖片來源於cs.rutgers.edu/)
連線的方式
（1）短連線，對於每一次請求，都需要單獨建立一個tcp連線，請求完成之後關閉連線，每一個請求都需要獨佔一個tcp連線。
通常的短連線操作步驟是： 連線→資料傳輸→關閉連線；
（圖片來源於教材截圖）
（2）短連線執行緒池，對建立的tcp連線不是簡單的釋放掉，而是快取起來，每一次rpc請求都需要佔用該連線。
（3）長連線，只建立一個連線，所有請求都共享這個連線，通過一些請求id來標示返回的資料應該屬於哪一個請求。
長連線的操作步驟就是：
連線→資料傳輸→保持連線(心跳)→資料傳輸→保持連線(心跳)→……→關閉連線；
簡單來說，短連結一般都是基於HTTP的,會遵循三次握手原則，web站點對外服務都是使用的短連線。
長連線主要基於Socket，長連線的框架有最出名的Netty了，Dubbo框架也是基於Netty而來。長連線框架優勢在於效率高（大量建立連線的開銷真心很高），適用於內部業務系統間的呼叫。
連線的傳送/接收方式
1、非同步, 報文傳送和接收是分開的，相互獨立的，互不影響。
2、同步, 報文傳送和接收是同步進行，既報文傳送後等待接收返回報文。 同步方式需要考慮超時問題。
長連線的管理
建立一個連線管理器，每一次在發起請求的時候，都需要在聯結器中申請一個連線，連線管理器負責連線狀態監測；
每次在獲取連線的時候，做一次連線狀態的監測，確保連線的狀態確實是正常的；
根據請求的一些狀態，主動的處理連線，例如出現了一些意料之外的異常，那麼為了安全，需要將當前執行緒主動關閉掉。通過上下文管理Context Manager捕獲外部程式碼的一些異常，從而在一些特殊情況下主動關閉連線;
客戶端連線請求的timeout時間一定需要要設定，服務端需要監控執行緒執行狀態，防止永久性的阻塞造成記憶體洩露，設定超時閾值，在需要的時候直接終止正在執行請求。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
