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 註冊的服務路由，裡面包含了攔截器元資料

5、總結

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