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，還需要去花一些時間去做企業微服務培訓和幫助企業更快熟悉如何構建微服務程式
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/47017.html
標籤：.NET Core