【七牛彎區課堂】Ruby服務間通訊模式

Ruby是計算機語言中的紳士，若是要用一個詞來形容，那必定是優雅，有這麼一位Rubyist，他的座右銘是「寫優雅的程序，作一個優雅的人」，他是來自七牛小夥伴「薄荷」的Co-founder兼CTO謝文威（英文名Vincent）。薄荷的核心繫統徹底基於Ruby構建，關於Ruby服務間通訊模式，他在「七牛彎區課堂」給Ruby愛好者們作了一次分享。

上圖是薄荷App服務劃分的例子，各子系統（服務）間須要進行各類通訊，主要通訊種類以下。

1、A服務須要使用Ｂ服務的一些數據 共享數據庫

---

應用場景：用戶的年齡、性別、身高和體重等數據存儲在帳號子系統中，其它子系統常常須要使用這些數據。

處理方式：共享數據庫

App2直接創建鏈接訪問 App1的數據庫。這種方式的優勢是性能較好，避免了接口處理和消息封裝種種開銷，適用於通訊特別頻繁或者數據量特別大的場合。薄荷的帳號和會話數據即採起這種方案。可是，該方式致使服務間有很強的耦合，App2對App1的數據結構有緊密的依賴，致使App1的實現難以變動。

共享數據庫方法：

ActiveRecord支持多數據庫配置有一些注意的事項：

• 可使用關聯，不支持join，不支持事務

• 測試數據最好使用factory_girl

• 爲避免數據混亂，只有一個服務可寫

共享模型使用

• gem model

• git submodule

2、A服務須要Ｂ服務提供某個計算結果 請求結果（同步）

---

應用場景：計算預算熱量須要使用複雜的數學模型，它放在記錄子系統中實現，別的系統須要用到相關的數據時，經過一種通訊機制拿到計算結果。

處理方式：HttpAPI Call和RPC

1）Http API Call

這是最多見的一種通訊方式，服務實現方案成熟可靠，具備服務邊際簡單清晰的特色，同時適用於外部和內部，但內部調用性能不夠好。

使用Http API注意事項

• 訪問安全控制，使用ip限制，token校驗等

• 避免調用層次過深，超時機制

• Http Client選擇（Http Client特別多，主要分爲如下幾類）

薄荷目前typhoeus和faraday用的較多，緣由是：typhoeus底層基於curl，性能比較好，而且支持並行，用異步API的方式，比較可靠，不用擔憂多線程問題。

2）RPC（Remote Procedure Call）

主要特色：

• 長鏈接，避免每次通訊建立網絡鏈接，性能較好

• 對http、消息協議更高效

• 多種跨語言RPC方案，如thriftmsgpack_rpc

RPC管理

性能上有必定優點，須要權衡其複雜度，複雜度在於服務實現方案和管理方法。

• 服務端併發模式

• 高可用方案，可用HAProxy

• 平滑部署

RPC的用法比較少見，更多地用於跨多語言的團隊，當公司使用多種語言且須要很好地整合時，RPC則是一種比較成熟的方案。

3、A服務須要Ｂ服務處理一項任務 請求任務處理（異步）

---

應用場景：在購物模塊裏面，一個訂單發生支付後，須要給用戶推送一些信息，好比發短信、郵件和手機推送等。發送消息可能須要比較長的時間才能完成，請求方不須要等待處理結果。

處理方式：消息隊列

1）傳統消息隊列系統RabbitMQ/Active MQ

MQ能夠有下降服務之間耦合度，一般用於服務之間的異步處理（傳統MQ有更豐富的處理機制），傳統MQ ruby服務實現方案，能夠參考sneakers, hutch, rack-ampq, rack-rabbit。

2）在單個應用內部經常使用基於redis的輕量消息隊列

resque&sidekiq

3）sidekiq-postman

它是Vincent寫的一個gem，基於sidekiq輕量消息隊列解決方法，簡單實用，能夠跨應用請求sidekiq任務處理，如下是其核心代碼：

4、A服務發生某件事，通知Ｂ和Ｃ進行處理 訂閱和通知

---

應用場景：好比帳號基本信息，基於性能考慮，在子系統中存儲了用戶名副本。當用戶名在帳戶子系統中發生變化時，須要通知其它子系統更新。

處理方式：消息隊列

Sidekiq-driver 是Vincent正在寫的基於sidekiq輕量訂閱和通知解決方法的gem，你們能夠盡情期待這個項目的開源。

【七牛彎區課堂】是七牛爲廣大開發者提供的技術實踐分享課堂，後續將按期邀請各技術社區的專家進行分享。以上內容便是Ruby China社區在「七牛彎區課堂」的處女做。歡迎各技術社區的小夥伴來【七牛彎區課堂】分享實踐心得，也感謝各位爲技術社區所貢獻的力量。