1,、前言

微服務(wù)架構(gòu)已成為目前互聯(lián)網(wǎng)架構(gòu)的趨勢(shì)，關(guān)于微服務(wù)的討論,，幾乎是各大技術(shù)論壇,、技術(shù)大會(huì)的熱門(mén)話題。而Surging是高性能的模塊化微服務(wù)引擎,，是大家首選微服務(wù)引擎架構(gòu)之一,，而針對(duì)于框架有個(gè)突出的缺點(diǎn)就是只能支持基于.NET CORE開(kāi)發(fā)，而現(xiàn)如今各大公司開(kāi)發(fā)語(yǔ)言是多樣的,，每個(gè)業(yè)務(wù)線有各自開(kāi)發(fā)的語(yǔ)言,，所以出現(xiàn)了 多語(yǔ)言之間服務(wù)調(diào)用的問(wèn)題。

跨語(yǔ)言調(diào)用是大家比較關(guān)心的話題,，在這里我也提出自己的構(gòu)思,，后面計(jì)劃實(shí)現(xiàn)基于java的surging ，可以和.NET CORE 進(jìn)行互相調(diào)用,。在這篇文章也會(huì)大致討論一下我的構(gòu)思：

而在開(kāi)始之前,，我想說(shuō)下surging 是開(kāi)源的，大家可以花時(shí)間去專研研究代碼,，也歡迎大家提供想法,，貢獻(xiàn)PR,但是如果你想節(jié)約時(shí)間，想深入了解surging,或者熟知如何部署,，您可以購(gòu)買作者的時(shí)間給你來(lái)四場(chǎng)一對(duì)多的直播,，或者您有技術(shù)的疑難也可以通過(guò)購(gòu)買企業(yè)服務(wù)的方式進(jìn)行一對(duì)一的解答,。而大家關(guān)心的事，有沒(méi)有企業(yè)購(gòu)買或者使用,，在這里可以告訴你有,，有很多。而且已經(jīng)做了多場(chǎng)直播,，還有購(gòu)買OEM版權(quán)的,。

2、協(xié)議之間適配

大家最初最常用的想要實(shí)現(xiàn)“跨語(yǔ)言”大多數(shù)方案是使用 http 協(xié)議做一層轉(zhuǎn)換,，最常見(jiàn)的手段莫過(guò)于借助 webapi 提供的 controller/action,，間接通過(guò)httpclient調(diào)用webapi 提供的rest。這種方案的調(diào)用使得鏈路變長(zhǎng),，tcp 通信之上又多了一層 http 通信,還需要寫(xiě)一套外層的webapi,不論是開(kāi)發(fā)時(shí)間還是性能都有所拉長(zhǎng)。

   而針對(duì)于surging 是支持多種協(xié)議,，surging內(nèi)部提供了基于netty 的RPC協(xié)議之外,，還有rest協(xié)議和grpc協(xié)議可供選擇。這兩者都是通用的跨語(yǔ)言協(xié)議,。

  rest 協(xié)議為滿足 標(biāo)準(zhǔn)規(guī)范,，在開(kāi)發(fā)過(guò)程中引入了 GET、POST,、PUT,、DELETE 等特性，而這些特性可以通過(guò)元數(shù)據(jù)的方式注冊(cè)到注冊(cè)中心,，對(duì)于習(xí)慣于編寫(xiě)傳統(tǒng)rest 接口的人可以通過(guò)rest進(jìn)行對(duì)接,。

 Gprc 更可以通過(guò)Google Protocol Buffers做到跨協(xié)議調(diào)用

RPC 跨協(xié)議調(diào)用就需要考慮 消息模型報(bào)文格式和序列化方案，而針對(duì)于消息報(bào)文包括了消息Id,，消息類型,，消息內(nèi)容，而消息內(nèi)容有兩種類型,，一種是遠(yuǎn)程調(diào)用消息,，一種是遠(yuǎn)程調(diào)用結(jié)果消息。只要滿足以上報(bào)文傳遞就可以了,，而針對(duì)于報(bào)文必然要序列化和反序列化,，而框架中提供了messagepack、ProtocolBuffers,、Json.

3,、服務(wù)治理與注冊(cè)中心適配

談到服務(wù)治理必然要談到容錯(cuò)規(guī)則、負(fù)載均衡,、服務(wù)路由,，對(duì)于這些參數(shù)的適配，必然需要注冊(cè)中心進(jìn)行存儲(chǔ)，而框架實(shí)現(xiàn)了基于consul 和 zookeeper 注冊(cè)中心,。

而談到多語(yǔ)言混合,，必然針對(duì)于每種語(yǔ)言都要考慮如何把服務(wù)路由信息注冊(cè)到注冊(cè)中心，并且需要實(shí)現(xiàn)一套基于consul 的心跳方式交互,，還有一套基于zookeeper 的watcher 機(jī)制交互,，而針對(duì)于服務(wù)路由里面包含了服務(wù)地址列表，需要實(shí)現(xiàn)針對(duì)于每種語(yǔ)言寫(xiě)一套負(fù)載算法,，包括了輪詢,、哈希、隨機(jī)算法,，還需要實(shí)現(xiàn)一套各語(yǔ)言容錯(cuò)規(guī)則的判斷,，再發(fā)生錯(cuò)誤時(shí)，能通過(guò)容錯(cuò)規(guī)則發(fā)生熔斷,。

4,、服務(wù)鏈路跟蹤適配

而針對(duì)于框架實(shí)現(xiàn)了一套基于skywalking的服務(wù)鏈路跟蹤，它支持基于rpc,、rest,、mqtt 協(xié)議服務(wù)跟蹤，如果沒(méi)有通過(guò)rest 主入口訪問(wèn)調(diào)用所產(chǎn)生的調(diào)用都是單鏈路的,，而通過(guò)rest,可以產(chǎn)生調(diào)用鏈路,，

可以通過(guò)TraceId傳遞，來(lái)銜接多語(yǔ)言混合鏈路跟蹤,，并且需要把收集性能跟蹤信息交互到skywalking,以下是實(shí)現(xiàn)的鏈路跟蹤

4,、攔截器的適配

而針對(duì)于攔截器考慮到需要跨語(yǔ)言和擴(kuò)展性，在框架內(nèi)部已經(jīng)把攔截器參數(shù)和ID抽象化到服務(wù)路由元數(shù)據(jù)當(dāng)中,。并且可以針對(duì)于攔截器進(jìn)行擴(kuò)展,，而框架實(shí)現(xiàn)了ServiceCacheIntercept和ServiceLogIntercept，而針對(duì)于跨語(yǔ)言需要做的是解析元數(shù)據(jù),，轉(zhuǎn)化成攔截器參數(shù),，再通過(guò)參數(shù)去實(shí)現(xiàn)業(yè)務(wù)攔截降級(jí)，而以下是基于consul 注冊(cè)的服務(wù)路由,，里面包含了攔截器元數(shù)據(jù)

5,、總結(jié)

 以上是對(duì)于多語(yǔ)言混合微服務(wù)架構(gòu)的一些構(gòu)思，在以下日子里會(huì)去實(shí)現(xiàn)多語(yǔ)言混合架構(gòu),，第一目標(biāo)是先實(shí)現(xiàn)JAVA,，還需要去花一些時(shí)間去做企業(yè)微服務(wù)培訓(xùn)和幫助企業(yè)更快熟悉如何構(gòu)建微服務(wù)程序