談談後臺服務的RPC和路由管理

版權聲明：本文由廖念波原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/147

來源：騰雲閣 https://www.qcloud.com/community

 

爲何要用RPC和路由管理

RPC的概念其實出現已經好久了，記得筆者讀大學的時候，接觸到RPC的概念，總以爲不重要，畫蛇添足：

1. 我掌握好socket通訊這個利器和tcp/ip協議族原理，什麼功能不能實現？

2. RPC就跟本地函數調用同樣寫代碼，確實開發效率比較高；我本身把socket相關函數好好封裝一下，讓代碼複用起來，開發效率也很高。

3. 不懂或者不關注網絡通訊底層原理，光會函數調來調去，這樣的程序員太沒有出息了！

後來，筆者開始帶團隊，親身經歷了一些團隊協做和IT服務運營過程當中的故事，才發現RPC很是關鍵。這裏分享我經歷過的很早之前的兩個故事。

故事一：有一個基礎模塊A，被很是多的其餘模塊遠程調用，模塊A的門戶提供協議文檔、API、調用示例代碼，每當有人來申請使用，模塊A負責人就會給調用方一組接口機的IP，調用方能夠給這些IP髮網絡請求。

重視可用性的有追求的調用方，一般在拿到IP後，會把IP寫在配置文件裏，而且本身在代碼裏實現必定的容錯邏輯：若是某個IP請求連續失敗多少次，就一段時間內不要給它發請求了。這個容錯邏輯作好可不簡單，涉及到不少細節。

大多數的調用方，是把IP寫死在代碼裏，簡單的輪詢請求這些IP。

若是模塊A的某臺接口機死機了，或者網絡局部故障致使某些接口機不可達，不少調用方就會跳起來：大家怎麼回事？大家的服務水平怎麼這麼差！

若是機房裁撤，一些機器IP要下架，模塊A負責任會很是頭疼：

1. 首先不知道有哪些人在請求這個IP。讀者說：傻啊，抓包看一下不就知道有哪些調用方了？可是要知道有的請求不是持續的，是不按期的訪問一下模塊A。

2. 模塊A的負責人要大範圍的郵件通知調用方改路由（一般要改代碼編譯發佈），過一段時間後，抓包看還有哪些調用方沒有改，再挨個敦促修改路由

3. 有時候某個IP下架了，過了幾天，忽然有個調用方跳起來：咱們還在用呢！咱們是寫死IP的，代碼找不到了，只能拿二進制可執行文件「硬」改

故事二： 一個團隊裏，一般有不少技術能力、服務意識和責任心都很是強的同事，他們的工做產出質量很是高，每一個遠程調用都有次數和成功率的上報（簡單的說就是上報到一個監控系統，能夠經過監控系統web界面查看曲線圖），請求報文中的一些重要但不強校驗的字段也都認真填寫（例如染色標記），因此他們負責的模塊，若是出現異常，很容易經過監控系統和日誌監控到，並能快速定位到問題。

可是，也有一些同事責任心和能力不那麼突出，重要的監控上報缺失、請求包裏一些重要的字段沒有填寫。有時候服務的故障有異常了好久，被用戶投訴才發現，事故報告里老是會出現這樣的改進措施：增長對xxx的監控上報，加強服務運營意識。

相似的事故一般會反覆出現，管理幹部就會拉起一次運動式的梳理和整頓，但過一段時間，肯還會出現。

經過這兩個事故可見：若是沒有很好的實現RPC和路由管理，IT系統服務質量會過分的依賴人的意識，而這個一般成本很是高、效果也很差。

毫秒服務引擎(msec, 取英文名Mass Service Engine in Cluster的首字母組合)是騰訊一個開源框架，其創做衝動和構建經驗，來自QQ後臺團隊超過10年的運營思考。RPC和路由管理是毫秒服務引擎設計的重要考量點。

毫秒引擎裏是怎麼作的？

首先，毫秒引擎將每一個服務部署在哪些IP上這些信息集中管理起來，即便是調用外部的非標準服務（咱們叫異構服務），也須要將該外部服務的接口IP配置到毫秒引擎管理系統裏。這樣涉及到的IP信息就不會散落在代碼和各類配置文件裏了。

服務之間的調用，統一採用CallMethod()函數的方式，避免代碼千奇百怪；按服務名字調用和接口名調用

RPC背後的路由算法對於單機故障、網絡局部波動等異常，自動容錯。簡單的說，路由算法按必定的規則輪轉的選擇被調用模塊的接口機，並統計過去一段時間的調用成功率、時延信息，根據這些信息調整該接口機被選擇到的比例。若是某個接口機故障了，那麼就不會發送請求給它，從而實現自動容錯。

毫秒引擎框架自己，在RPC執行的時候，就上報了不少基礎屬性和日誌，這樣保證了服務監控和告警等運營措施不依賴與人的意識。下圖是叫作getMP3List這樣一個RPC調用的請求數和成功數，這些是不須要業務開發者工做就自動上報。

每一個請求有惟一ID來標識，經過該ID，毫秒引擎能夠在框圖中直觀的呈現該請求通過的模塊、模塊間的RPC名字等信息，這個一樣不須要業務開發者的工做就自動實現：

結語

互聯網服務的後臺，硬件一般是由大量的廉價機器組成；軟件架構一般採起大系統小作、分而治之的思想。這就決定了業務邏輯涉及到大量的網路IO，同時單機故障、網絡局部故障是運營的常態。那麼，RPC和路由管理就顯得尤爲重要了。毫秒服務引擎爲此提供了一個完整的解決方案。詳細的能夠見騰訊雲服務市場、毫秒服務引擎官網，或者微信公衆號:msec-engine