.NET Core微服务之路：让我们对上一个Demo通讯进行修改，完成RPC通讯
最近一段時間有些事情耽擱了更新，抱歉各位了。
上一篇我們簡單的介紹了DotNetty通信框架，并簡單的介紹了基于DotNetty實現了回路（Echo）通信過程。
我們來回憶一下上一個項目的整個流程：
當服務端啟動后，綁定并監聽（READ）設定的端口，比如1889。
當客戶端啟動后，綁定指定端口，等待用戶輸入。
當用戶輸入任意字符串數據后，客戶端將這組數據進行轉碼為byte格式進行傳輸到服務端。
當服務端收到客戶端傳來的數據，進行轉碼后輸出控制臺，并將這組數據再次回傳到客戶端。
客戶端收到數據，也打印出來。
?
很簡單的實現了一個點對點的通信例子。接下來我們將對這個DEMO進行簡單的修改，模擬最簡單的gRPC通信的一個構造過程。
?
本篇很簡單，只要實現了上一個demo，稍作修改，就能實現gRPC了（當然實際構建gRPC根本不會這么簡單），本篇也是順帶一下這幾天搞出來的一個輕量級RPC框架，先接上一個例子。
?
服務端
增加兩個靜態方法SayHello和SayByebye，用于提供遠程調用，超級簡單，不解釋。
在我們原來的ChannelRead函數中，將原有的Echo回路傳輸，直接替換成如下內容。
（1）：有這樣一句話Replace(")", "")，筆者不知為何每次傳送過來從buffer里轉義出來的字符串，始終會有一個左括號在里面，也許是消息頭，也許是protobuf-net的標記頭，因為都是byte格式，在服務端偷懶就沒有再進行一次protobuf的反序列化了。
為何要用Dictionary來作為中間對象轉換，因為序列化需要實體對象作為類型，為了簡單的介紹RPC，目前也就這么干了，例如上面代碼所示。
（2）：通過判斷“func”字段中的內容進行方法調用，并將調用過程的返回結果轉為BYTE格式。
（3）：設置本次傳輸中的Buffer大小。
（4）：將消息（數據）寫入到DotNetty的Buffer。
（5）：最終將Buffer寫入到當前上下文（包含通道，傳輸對象，連接對象等等）。?
客戶端
我們將上一個demo中的EchoClientHandler做如下修改，以完成一個簡單的請求
（1）：建立與服務端相關的通信數據。
（2）：將數據序列化為二進制流。
（3）：將數據寫入到ByteBuffer中。
?
啟動一下
由于在客戶端明文標注了使用sayHello這個方法，客戶端會收到服務端返回的"hello stevelee"。
這樣一個最簡單的RPC遠程調用就完成了（其實上一篇就也屬于RPC，只是這里用方法和過濾來指定調用）。
?
?問題
服務端不可能都通過這樣笨拙的過濾方式來調用方法吧？是的，這只是DEMO，為了演示和理解基礎概念而已，而是要動過動態代理來實現方法Invoke。
這個DEMO只是一個點對點的遠程調用，不會涉及到任何服務路由和轉發等高級特性。
有新的接口的時候時候，需要重新編譯和暴露，如果有上萬個新的接口，這樣的重復工作豈不是瘋了。
...etc
這里推薦一下最近構建的一個小框架:Easy.Rpc(連接點我)，實現了路由，轉發，代理，動態編譯的特性。這里也幫朋友們推薦一個同樣基于DotNetty的RPC框架（連接點我）張隊推薦我加入他們，可我不知道怎么加入他們的團隊，悲催啊...
?
簡單介紹一下使用方法，本篇不詳細介紹這個框架是如何實現的，估計會好幾十萬字，單獨擰出來做個系列會更好，框架設計需要哪些原則，需要考慮到的問題，包含設計模式、依賴注入、動態代理、動態編譯、路由轉發等等特性。
?
Esay.Rpc
正如上面提到問題，需要解決這些問題，就需要修改諸多內容，
?
例如把函數改為接口，把接口的定義放置服務端并對外開放相應端口，把接口的實現同樣放置服務端，提供接口的調用，客戶端通過類似API的方式進行遠程接口調用，因此這個接口的定義必須單列的一個項目；
如何將接口自動部署（暴露）出來，可以通過中間協調器（也叫服務注冊中心，如ETCD，consul，zookeeper），如何將這些接口自動注冊到服務中心呢，需要實現反射自動掃描并添加到注冊中心。
?
我們添加一個Rpc.Common的中間通用庫，當然Easy.Rpc的框架源碼也在這個里面（框架目前不探討），添加IUserService接口，UserModel實體類，UserServiceImpl實現類。其實通用類庫只需要接口和實體就行，接口實現完全放置服務端，這樣這個庫也能完全分離出來。（不過筆者偷懶都寫到Rpc.Common庫中去了，實際生產決不能這么膜，分離，分離，分離，這也是微服務的主要概念之一）
?
DEMO結構如下（Easy.Rpc源碼目前也包含在這個里面，過兩天單獨拎出來做成框架，方便調用）
?
?
先看看接口定義了些什么：
8個接口，幾乎囊括了目前RPC調用測試的所有方法場景。接口實現就不貼了，你完全可以自定義接口的任何實現，或者就一句Console.Write("哇涼哇涼完啦")都可以。
接口參數中有個UserModel的實體對象，這里也貼上來。
上面有兩個不一樣的標記，也是protobuf-net中獨有的特性。
ProtoContract標記：該類是參與序列化內容的數據類。
ProtoMember標題：該類需要序列化的字段和順序。?
protobuf-net的坑
默認例子中該類沒有任何繼承，因此不會存在一個妖孽問題，但如果UserModel是一個子類，他繼承于一個父類，而這個父類也同樣擁有多個子類，直接ProtoContract參與序列化將會報錯，需要在特性上增加DataMemberOffset = x，此處的x不是字母，而是這個子類的一個序列化順序。比如有3個子類繼承同一個父類，前面兩個子類的偏移量分別是1和2，那么這個類的偏移量將設置為3，以此類推。
默認的數據類型中，系統定義的標準類型沒問題，但有個妖孽的int[]這樣的數組類型，那也將是個噩夢，官網團隊沒有解釋為何不支持數組的序列化，我猜測估計是因為數組的不規則性（比如多維數組、甚至不規則的多維數組）而放棄了這個類型的序列化，畢竟序列化是不能影響性能的。
接下來繼續服務端的代碼
全程基于serviceCollection實現自動裝配和構造，相信用過Ioc容器都能明白這上面幾條依賴注入和自動構建服務的含義。
再添加客戶端代碼：
我想看到這里，明白上面代碼的作用，也就明白了這個框架的作用，客戶端能像調用本地方法一樣去調用遠程方法，并且中間過程是完全透明的，分離，分離，分離。
微服務的作用不再介紹，呵呵。
原文地址:https://www.cnblogs.com/SteveLee/p/Simple_Rpc_Demo.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.NET Core微服务之路：让我们对上一个Demo通讯进行修改，完成RPC通讯的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [翻译]初试C# 8.0
- 下一篇： .NET Core实战项目之CMS 第十