? ? ? 繼之前的《Asp.Net Core + Docker 搭建》文章末尾說過的，將陸續編寫基于asp.net core 打造一個內部服務治理的rpc框架。不過前端時間較忙，所以擱置了一段時間。閑話不多說，下面就來講講為什么需要去做一個該框架，以及想法的來源和設計思路。

一、產生背景

? ? ? ?公司技術棧是以微軟棧為主。整個平臺的業務并不是特別復雜。因此先前搭建每個子系統的時候都是以最簡單的方式入手（時間較緊）。但是隨著時間的推移，各個子系統之間的交互也是越來越多，當然，我們的做法也是很簡單，就是通過暴露rest api ，然后客戶端通過http調用進行交互，以至于現在很多系統都會配置其他系統的調用信息。日積月累，感覺系統越來月凌亂（有潔癖，遇到這種亂，就必須要去重構^_^，當然也是為后面維護減少成本），于是就產生了編寫一個內部服務調用的框架。

二、想法來源

? ? ? 本著遇到問題解決問題的目的，最開始也想直接使用開源的系統，如:sugring,orleans等.net 界非常著名的項目。但考慮到我的需求很簡單（以及我的想法也是做一個非常簡單，盡量不依賴其他重量級的框架，開發人員都認真閱讀代碼后，都能輕易維護的東西)，且對上述的框架目前應用到生產環境的案例不是很知曉的情況下，于是還是忍痛割愛，最終放棄了。在這里，我想表達我的目標就是我需要像dubbo一樣，調用方只需要引用服務提供者定義的相關接口庫（.Net 中定義的接口eg:IUserService），就能直接調用。服務的調用方和提供方都注冊到一個統一的注冊中心（我以consul為注冊中心，無需安裝其他運行時，非常方便）。這樣就不需要關心服務的具體地方。(該實現方式的想法在我今天(2018-12-16)看到的doteasy.rpc中的文章和我的想法幾乎一致，但是我的實現還是略有不同，它是基于pb進行傳輸實現的，我是完全基于asp.net core 中的webapi進行實現)。

三、設計思路

? ? ? 其實，asp.net core 已經是一個完善且高效的rpc框架，我們在調用每一個實現的web api實際就是一個rpc調用，只是它是基于http協議，大多數情況下，數據是通過json序列化和反序列化而已。（其他開源的優秀框架eg:surgin,oreans,dubbo...實現了自己高效的通信方式以及協議)。所以，基于asp.net core來實現，其實就是基于它來擴展，并且滿足大多數公司的業務需求的性能要求應該不是問題(何況我們的spring boot實現微服務也是走rest方式^_^)。下面是我的整個想法構思圖。

圖 1

? ? ? 場景：比如我有一個Service A的集群,依賴了Service B集群(可運行多個Service B的進程實例)的一個接口(IUserService，當然該接口在Service B中進行了實現UserService)進行數據獲取（或操作）。就可以通過啟動每個Service B實例時就將Service B要提供的服務發布出來(或叫導出)，注冊到Consul注冊集群中，同樣,Service A的實例也需要注冊到注冊中心(即使不發布供其他服務調用的接口)。此時，Service A要調用Service B的服務，首先，通過HttpServiceProxyFactory服務代理類生成IUserSerivice的代理實現類UserSeriviceImpl（通過Emit進行動態代理），再從注冊中心獲取到Service B的集群信息，根據一定的負載算法(負載是客戶端進行負載實現，目前只實現了簡單的循環負載)，選擇一個Service B的實例進行遠程調用。其中UserSeriviceImpl代理實現類中核心的代碼就是通過HttpClient進行數據的包裝，然后請求到Service B中的UserService(其實就是一個Controller)實現類中。然后在解析UserService處理后返回過來的數據。

? ? ? 以上就是我整個Rpc調用的總體思路。具體每個模塊的詳細設計與實現，接下來我會繼續寫出來，有興趣的朋友可以留言交流也可以加qq:418237014交流。

?

原文地址: https://www.jianshu.com/p/c45f56d2aa21

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的基于Asp.Net Core打造轻量级内部服务治理RPC(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。