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

標籤：

Ruby是電腦語言中的紳士，如果要用一個詞來形容，那一定是優雅，有這麼一位Rubyist，他的座右銘是“寫優雅的程式，做一個優雅的人”，他是來自七牛小夥伴“薄荷”的Co-founder兼CTO謝文威（英文名Vincent）。薄荷的核心系統完全基於Ruby構建，關於Ruby服務間通訊模式，他在“七牛彎區課堂”給Ruby愛好者們做了一次分享。

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

一、A服務需要使用Ｂ服務的一些資料 共用資料庫

應用情境：使用者的年齡、性別、身高和體重等資料存放區在帳號子系統中，其它子系統經常需要使用這些資料。

處理方式：共用資料庫

App2直接建立串連訪問 App1的資料庫。這種方式的優點是效能較好，避免了介面處理和訊息封裝種種開銷，適用於通訊特別頻繁或者資料量特別大的場合。薄荷的帳號和會話資料即採取這種方案。但是，該方式導致服務間有很強的耦合，App2對App1的資料結構有緊密的依賴，導致App1的實現難以變更。

共用資料庫方法：

ActiveRecord支援多資料庫配置有一些注意的事項：

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

• 測試資料最好使用factory_girl

• 為避免資料混亂，只有一個服務可寫

共用模型使用

• gem model

• git submodule

二、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則是一種比較成熟的方案。

三、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任務處理，以下是其核心代碼：

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

應用情境：比如帳號基本資料，基於效能考慮，在子系統中儲存了使用者名稱副本。當使用者名稱在賬戶子系統中發生變化時，需要通知其它子系統更新。

處理方式：訊息佇列

Sidekiq-driver 是Vincent正在寫的基於sidekiq輕量訂閱和通知解決方案的gem，大家可以盡情期待這個項目的開源。

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

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