談談surging 與多語言混合微服務構思

1、前言

微服務架構已成爲目前互聯網架構的趨勢，關於微服務的討論，幾乎是各大技術論壇、技術大會的熱門話題。而Surging是高性能的模塊化微服務引擎，是你們首選微服務引擎架構之一，而針對於框架有個突出的缺點就是隻能支持基於.NET CORE開發，而現現在各大公司開發語言是多樣的，每一個業務線有各自開發的語言，因此出現了 多語言之間服務調用的問題。

跨語言調用是你們比較關心的話題，在這裏我也提出本身的構思，後面計劃實現基於java的surging ，能夠和.NET CORE 進行互相調用。在這篇文章也會大體討論一下個人構思：

而在開始以前，我想說下surging 是開源的，你們能夠花時間去專研研究代碼，也歡迎你們提供想法，貢獻PR,可是若是你想節約時間，想深刻了解surging,或者熟知如何部署，您能夠購買做者的時間給你來四場一對多的直播，或者您有技術的疑難也能夠經過購買企業服務的方式進行一對一的解答。而你們關心的事，有沒有企業購買或者使用，在這裏能夠告訴你有，有不少。並且已經作了多場直播，還有購買OEM版權的。

2、協議之間適配

你們最初最經常使用的想要實現「跨語言」大多數方案是使用 http 協議作一層轉換，最多見的手段莫過於藉助 webapi 提供的 controller/action，間接經過httpclient調用webapi 提供的rest。這種方案的調用使得鏈路變長，tcp 通訊之上又多了一層 http 通訊,還須要寫一套外層的webapi,不管是開發時間仍是性能都有所拉長。

   而針對於surging 是支持多種協議，surging內部提供了基於netty 的RPC協議以外，還有rest協議和grpc協議可供選擇。這二者都是通用的跨語言協議。

  rest 協議爲知足 標準規範，在開發過程當中引入了 GET、POST、PUT、DELETE 等特性，而這些特性能夠經過元數據的方式註冊到註冊中心，對於習慣於編寫傳統rest 接口的人能夠經過rest進行對接。

 Gprc 更能夠經過Google Protocol Buffers作到跨協議調用

RPC 跨協議調用就須要考慮 消息模型報文格式和序列化方案，而針對於消息報文包括了消息Id，消息類型，消息內容，而消息內容有兩種類型，一種是遠程調用消息，一種是遠程調用結果消息。只要知足以上報文傳遞就能夠了，而針對於報文必然要序列化和反序列化，而框架中提供了messagepack、ProtocolBuffers、Json.

 

3、服務治理與註冊中心適配

談到服務治理必然要談到容錯規則、負載均衡、服務路由，對於這些參數的適配，必然須要註冊中心進行存儲，而框架實現了基於consul 和 zookeeper 註冊中心。

而談到多語言混合，必然針對於每種語言都要考慮如何把服務路由信息註冊到註冊中心，而且須要實現一套基於consul 的心跳方式交互，還有一套基於zookeeper 的watcher 機制交互，而針對於服務路由裏面包含了服務地址列表，須要實現針對於每種語言寫一套負載算法，包括了輪詢、哈希、隨機算法，還須要實現一套各語言容錯規則的判斷，再發生錯誤時，能經過容錯規則發生熔斷。

4、服務鏈路跟蹤適配

而針對於框架實現了一套基於skywalking的服務鏈路跟蹤，它支持基於rpc、rest、mqtt 協議服務跟蹤，若是沒有經過rest 主入口訪問調用所產生的調用都是單鏈路的，而經過rest,能夠產生調用鏈路，

能夠經過TraceId傳遞，來銜接多語言混合鏈路跟蹤，而且須要把收集性能跟蹤信息交互到skywalking,如下是實現的鏈路跟蹤

 

 

 

4、攔截器的適配

而針對於攔截器考慮到須要跨語言和擴展性，在框架內部已經把攔截器參數和ID抽象化到服務路由元數據當中。而且能夠針對於攔截器進行擴展，而框架實現了ServiceCacheIntercept和ServiceLogIntercept，而針對於跨語言須要作的是解析元數據，轉化成攔截器參數，再經過參數去實現業務攔截降級，而如下是基於consul 註冊的服務路由，裏面包含了攔截器元數據

 

 

五、總結

以上是對於多語言混合微服務架構的一些構思，在如下日子裏會去實現多語言混合架構，第一目標是先實現JAVA，還須要去花一些時間去作企業微服務培訓和幫助企業更快熟悉如何構建微服務程序