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，還需要去花一些時間去做企業微服務培訓和幫助企業更快熟悉如何構建微服務程序