微服務跨語言調用（摘選）

微服務架構已成為目前互聯網架構的趨勢，關于微服務的討論，幾乎占據了各種技術大會的絕大多數版面。國內使用最多的服務治理框架非阿里開源的 dubbo 莫屬，千米網也選擇了 dubbo 作為微服務治理框架。另一方面，和大多數互聯網公司一樣，千米的開發語言是多樣的，大多數后端業務由 java 支撐，而每個業務線有各自開發語言的選擇權，便出現了 nodejs，python，go 多語言調用的問題。

創新互聯公司是網站建設專家,致力于互聯網品牌建設與網絡營銷，專業領域包括成都網站建設、成都網站制作、電商網站制作開發、微信小程序定制開發、微信營銷、系統平臺開發，與其他網站設計及系統開發公司不同，我們的整合解決方案結合了恒基網絡品牌建設經驗和互聯網整合營銷的理念，并將策略和執行緊密結合，且不斷評估并優化我們的方案，為客戶提供全方位的互聯網品牌整合方案！

跨語言調用是一個很大的話題，也是一個很有挑戰的技術活，目前業界經常被提及的解決方案有如下幾種，不妨拿出來老生常談一番：

當我們再聊跨語言調用時我們在聊什么？縱觀上述幾個較為通用，成熟的解決方案，可以得出結論：解決跨語言調用的思路無非是兩種：

如果一個新型的團隊面臨技術選型，我認為上述的方案都可以納入參考，可考慮到遺留系統的兼容性問題

舊系統的遷移成本

這也關鍵的選型因素。我們做出的第一個嘗試，便是在 RPC 協議上下功夫。

通用協議的跨語言支持

springmvc的美好時代

springmvc

springmvc

在沒有實現真正的跨語言調用之前，想要實現“跨語言”大多數方案是使用 http 協議做一層轉換，最常見的手段莫過于借助 springmvc 提供的 controller/restController，間接調用 dubbo provider。這種方案的優勢和劣勢顯而易見

通用協議的支持

事實上，大多數服務治理框架都支持多種協議，dubbo 框架除默認的 dubbo 協議之外，還有當當網擴展的?rest協議和千米網擴展的?json-rpc?協議可供選擇。這兩者都是通用的跨語言協議。

rest 協議為滿足 JAX-RS 2.0 標準規范，在開發過程中引入了 @Path，@POST，@GET 等注解，習慣于編寫傳統 rpc 接口的人可能不太習慣 rest 風格的 rpc 接口。一方面這樣會影響開發體驗，另一方面，獨樹一幟的接口風格使得它與其他協議不太兼容，舊接口的共生和遷移都無法實現。如果沒有遺留系統，rest 協議無疑是跨語言方案最簡易的實現，絕大多數語言支持 rest 協議。

和 rest 協議類似，json-rpc 的實現也是文本序列化http 協議。dubbox 在 restful 接口上已經做出了嘗試，但是 rest 架構和 dubbo 原有的 rpc 架構是有區別的，rest 架構需要對資源(Resources)進行定義， 需要用到 http 協議的基本操作 GET、POST、PUT、DELETE。在我們看來，restful 更合適互聯網系統之間的調用，而 rpc 更適合一個系統內的調用。使用 json-rpc 協議使得舊接口得以兼顧，開發習慣仍舊保留，同時獲得了跨語言的能力。

千米網在早期實踐中采用了 json-rpc 作為 dubbo 的跨語言協議實現，并開源了基于 json-rpc 協議下的 python 客戶端?dubbo-client-py?和 node 客戶端?dubbo-node-client，使用 python 和 nodejs 的小伙伴可以借助于它們直接調用 dubbo-provider-java 提供的 rpc 服務。系統中大多數 java 服務之間的互相調用還是以 dubbo 協議為主，考慮到新舊協議的適配，在不影響原有服務的基礎上，我們配置了雙協議。

dubbo 協議主要支持 java 間的相互調用，適配老接口；json-rpc 協議主要支持異構語言的調用。

定制協議的跨語言支持

微服務框架所謂的協議(protocol)可以簡單理解為：報文格式和序列化方案。服務治理框架一般都提供了眾多的協議配置項供使用者選擇，除去上述兩種通用協議，還存在一些定制化的協議，如 dubbo 框架的默認協議：dubbo 協議以及 motan 框架提供的跨語言協議：motan2。

motan2協議的跨語言支持

???motan2

motan2

motan2 協議被設計用來滿足跨語言的需求主要體現在兩個細節中—MetaData 和 motan-go。在最初的 motan 協議中，協議報文僅由 Header+Body 組成，這樣導致 path，param，group 等存儲在 Body 中的數據需要反序列得到，這對異構語言來說是很不友好的，所以在 motan2 中修改了協議的組成；weibo 開源了?motan-go?，motan-php?，motan-openresty?,并借助于 motan-go 充當了 agent 這一翻譯官的角色，使用 simple 序列化方案來序列化協議報文的 Body 部分（simple 序列化是一種較弱的序列化方案）。

???agent

agent

仔細揣摩下可以發現這么做和雙協議的配置區別并不是大，只不過這里的 agent 是隱式存在的，與主服務共生。明顯的區別在于 agent 方案中異構語言并不直接交互。

dubbo協議的跨語言支持

dubbo 協議設計之初只考慮到了常規的 rpc 調用場景，它并不是為跨語言而設計，但跨語言支持從來不是只有支持、不支持兩種選擇，而是要按難易程度來劃分。是的，dubbo 協議的跨語言調用可能并不好做，但并非無法實現。千米網便實現了這一點，nodejs 構建的前端業務是異構語言的主戰場，最終實現了 dubbo2.js，打通了 nodejs 和原生 dubbo 協議。作為本文第二部分的核心內容，重點介紹下我們使用 dubbo2.js 干了什么事。

Dubbo協議報文格式

???dubbo協議

dubbo協議

dubbo協議報文消息頭詳解：

magic：類似java字節碼文件里的魔數，用來判斷是不是 dubbo 協議的數據包。魔數是常量 0xdabb

flag：標志位, 一共8個地址位。低四位用來表示消息體數據用的序列化工具的類型（默認 hessian），高四位中，第一位為 1 表示是 request 請求，第二位為 1 表示雙向傳輸（即有返回 response），第三位為 1 表示是心跳 ping 事件。

status：狀態位, 設置請求響應狀態，dubbo 定義了一些響應的類型。具體類型見com.alibaba.dubbo.remoting.exchange.Response

invoke id：消息 id, long 類型。每一個請求的唯一識別 id（由于采用異步通訊的方式，用來把請求 request 和返回的 response 對應上）

body length：消息體 body 長度, int 類型，即記錄 Body Content 有多少個字節

body content：請求參數，響應參數的抽象序列化之后存儲于此。

協議報文最終都會變成字節，使用 tcp 傳輸，任何語言只要支持網絡模塊，有類似 Socket 之類的封裝，那么通信就不成問題。那，跨語言難在哪兒？以其他語言調用 java 來說，主要有兩個難點：

ps：dubbo 協議通訊demo（ ）

Dubbo 協議

Dubbo是 Alibaba 開源的分布式服務框架遠程調用框架，在網絡間傳輸數據，就需要通信協議和序列化。

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多種協議，但是Dubbo官網是推薦我們使用Dubbo協議的，默認也是用的dubbo協議。

先介紹幾種常見的協議：

缺省協議，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

連接個數：單連接

連接方式：長連接

傳輸協議：TCP

傳輸方式：NIO異步傳輸

序列化：Hessian二進制序列化

適用范圍：傳入傳出參數數據包較小（建議小于100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。

適用場景：常規遠程服務方法調用

1、dubbo默認采用dubbo協議，dubbo協議采用單一長連接和NIO異步通訊，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況

2、他不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很低。

配置如下：

dubbo:protocol name="dubbo" port="20880" /

dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo”

serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9”

buffer=“8192” accepts=“1000” payload=“8388608” /

3、Dubbo協議缺省每服務每提供者每消費者使用單一長連接，如果數據量較大，可以使用多個連接。

dubbo:protocol name="dubbo" connections="2" /

4、為防止被大量連接撐掛，可在服務提供方限制大接收連接數，以實現服務提供方自我保護

dubbo:protocol name="dubbo" accepts="1000" /

Java標準的遠程調用協議。

連接個數：多連接

連接方式：短連接

傳輸協議：TCP

傳輸方式：同步傳輸

序列化：Java標準二進制序列化

適用范圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。

適用場景：常規遠程服務方法調用，與原生RMI服務互操作

RMI協議采用JDK標準的java.rmi.*實現，采用阻塞式短連接和JDK標準序列化方式 。

基于Hessian的遠程調用協議。

連接個數：多連接

連接方式：短連接

傳輸協議：HTTP

傳輸方式：同步傳輸

序列化：表單序列化

適用范圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。

適用場景：需同時給應用程序和瀏覽器JS使用的服務。

1、Hessian協議用于集成Hessian的服務，Hessian底層采用Http通訊，采用Servlet暴露服務，Dubbo缺省內嵌Jetty作為服務器實現。

2、Hessian是Caucho開源的一個RPC框架： ，其通訊效率高于WebService和Java自帶的序列化。

基于http表單的遠程調用協議。參見：[HTTP協議使用說明]

連接個數：多連接

連接方式：短連接

傳輸協議：HTTP

傳輸方式：同步傳輸

序列化：表單序列化

適用范圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。

適用場景：需同時給應用程序和瀏覽器JS使用的服務。

基于WebService的遠程調用協議。

連接個數：多連接

連接方式：短連接

傳輸協議：HTTP

傳輸方式：同步傳輸

序列化：SOAP文本序列化

適用場景：系統集成，跨語言調用

序列化是將一個對象變成一個二進制流就是序列化， 反序列化是將二進制流轉換成對象

為什么要序列化？

Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默認hessian2。其中java、compactedjava、nativejava屬于原生java的序列化。

hessian2序列化：hessian是一種跨語言的高效二進制序列化方式。但這里實際不是原生的hessian2序列化，而是阿里修改過的，它是dubbo RPC默認啟用的序列化方式。

json序列化：目前有兩種實現，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實現的簡單json庫，但其實現都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進制序列化。

java序列化：主要是采用JDK自帶的Java序列化實現，性能很不理想。

2022-04-03 dubbogo 調用部署在不同zk的同一服務

在 2021-10-17 dubbogo 基礎使用 中，介紹了如何用 go 寫一個部署到 zookeeper 的 dubbo 服務，這次編寫一個 go 語言的 dubbo 調用端。并且支持同時連接到多個 zookeeper ，根據需要調用不同 zk 上的同一個服務

這里我們部署兩個 zookeeper ，端口號分別是 2181 和 2182

這里我們配置了兩個 UserService 的引用，并且設置了不同的別名。指定了每個引用連接各自的 zk .

注意，這里 service.UserService 為服務提供方的接口，我們直接繼承他

服務1 的日志如下：

服務2 的日志如下：

github-dubbogodemo

Go微服務--常見的微服務框架

近幾年誕生了很多微服務框架，比如JAVA的Spring Cloud、Dubbo;Golang的GoKit和GoMicro以及NodeJs的Seneca。幾乎每種主流語言都有其對應的微服務框架。

Go在微服務框架中有其獨特的優勢，至于優勢在哪，自行google。

1、GoKit框架

這是一個工具包的集合，可以幫助攻城獅構建強大、可靠和可維護的微服務。提供了用于實現系統監控和彈性模式組件的庫，例如日志、跟蹤、限流、熔斷等。

基于這個框架的應用程序架構由三個主要的部分組成：

傳輸層：用于網絡通信，服務通常使用HTTP或者gRPC等網絡傳輸協議，或者使用NATS等發布訂閱系統相互通信。

接口層：是服務器和客戶端的基本構建塊。每個對外提供的接口方法都會定義為一個Endpoint，一遍在服務器和客戶端之間進行網絡通信，每個端點使用傳輸層通過HTTP或gRPC等具體通信模式對外提供服務

服務成：具體的業務邏輯實現

2、GoMicro框架

這是一個基于Go語言實現的插件化RPC微服務框架。提供了服務發現、負載均衡、同步傳輸、異步通信以及事件驅動等機制，嘗試簡化分布式系統之間的通信，讓開發者更專注于自身業務邏輯的開發。

GoMicro的設計哲學是可插拔的架構理念，提供了可快速構建系統的組件，并且可以根據自身的需求對GoMicro提供的默認實現進行定制。所有插件都可在倉庫github.com/micro/go-plugins 中找到。

分布式架構的注冊中心，該怎么選？

互聯網架構下，大部分系統已經轉型分布式。其中服務注冊發現中心，分布式服務中非常重要的組成部分。按需選擇合適的注冊中心，也變的尤為重要。

Eureka是SpringCloud全家桶中非常重要的一個組件，主要是實現服務的注冊和發現。Eureka做到了CAP理論中的AP，強調服務的高可用性。實現中分Eureka Server和Eureka Client兩部分。

Eureka客戶端會向Eureka注冊中心注冊為服務，并通過心跳來更新它的服務租約。同時也可以從服務端查詢當前注冊的服務信息并把他們緩存到本地并周期性的刷新服務狀態。若服務集群出現分區故障時，Eureka會轉入自動保護模式，允許分區故障的節點繼續提供服務；若分區故障恢復，集群中其他分區會把他們的狀態再次同步回來。

SpringCloud對其做了非常好的集成封裝，是官方推薦的注冊中心。

Zookeeper是大數據Hadoop中的一個分布式調度組件，強調數據一致性和擴展性，可用于服務的注冊和發現。她是dubbo中默認的服務注冊中心，也是目前使用最廣泛的分布式服務發現組件。注重CAP理論中的CP。

Consul是一個高可用的分布式服務注冊中心，由HashiCorp公司推出，Golang實現的開源共享的服務工具。Consul在分布式服務注冊與發現方面有自己的特色，解決方案更加“一站式”，不再需要依賴其他工具。

1、通過HTTP接口和DNS協議調用API存儲鍵值對，使服務注冊和服務發現更容易；

2、支持 健康 檢查，可以快速的告警在集群中的操作

3、支持key/value存儲動態配置

4、支持任意數量的區域

ETCD是一個高可用的分布式鍵值數據庫，可用于共享配置、服務的注冊和發現。ETCD采用Raft一致性算法，基于Go語言實現。ETCD作為后起之秀，又非常大的優勢。

1、基于HTTP+JSON的API，使用簡單；

2、可選SSL客戶認證機制，更安全；

3、單個實例支持每秒千次寫操作，快速。

4、采用Raft一致性算法保證分布式。

Dubbo——HTTP 協議 + JSON-RPC

Protocol 還有一個實現分支是 AbstractProxyProtocol，如下圖所示：

從圖中我們可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等協議對應的 Protocol 實現，都是繼承自 AbstractProxyProtocol 抽象類。

目前互聯網的技術棧百花齊放，很多公司會使用 Node.js、Python、Rails、Go 等語言來開發 一些 Web 端應用，同時又有很多服務會使用 Java 技術棧實現，這就出現了大量的跨語言調用的需求。Dubbo 作為一個 RPC 框架，自然也希望能實現這種跨語言的調用，目前 Dubbo 中使用“HTTP 協議 + JSON-RPC”的方式來達到這一目的，其中 HTTP 協議和 JSON 都是天然跨語言的標準，在各種語言中都有成熟的類庫。

下面就重點來分析 Dubbo 對 HTTP 協議的支持。首先，會介紹 JSON-RPC 的基礎，并通過一個示例，快速入門，然后介紹 Dubbo 中 HttpProtocol 的具體實現，也就是如何將 HTTP 協議與 JSON-RPC 結合使用，實現跨語言調用的效果。

Dubbo 中支持的 HTTP 協議實際上使用的是 JSON-RPC 協議。

JSON-RPC 是基于 JSON 的跨語言遠程調用協議。Dubbo 中的 dubbo-rpc-xml、dubbo-rpc-webservice 等模塊支持的 XML-RPC、WebService 等協議與 JSON-RPC 一樣，都是基于文本的協議，只不過 JSON 的格式比 XML、WebService 等格式更加簡潔、緊湊。與 Dubbo 協議、Hessian 協議等二進制協議相比，JSON-RPC 更便于調試和實現，可見 JSON-RPC 協議還是一款非常優秀的遠程調用協議。

在 Java 體系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身體積小巧，使用方便，既可以獨立使用，也可以與 Spring 無縫集合，非常適合基于 Spring 的項目。

下面先來看看 JSON-RPC 協議中請求的基本格式：

JSON-RPC請求中各個字段的含義如下：

在 JSON-RPC 的服務端收到調用請求之后，會查找到相應的方法并進行調用，然后將方法的返回值整理成如下格式，返回給客戶端：

JSON-RPC響應中各個字段的含義如下：

Dubbo 使用 jsonrpc4j 庫來實現 JSON-RPC 協議，下面使用 jsonrpc4j 編寫一個簡單的 JSON-RPC 服務端示例程序和客戶端示例程序，并通過這兩個示例程序說明 jsonrpc4j 最基本的使用方式。

首先，需要創建服務端和客戶端都需要的 domain 類以及服務接口。先來創建一個 User 類，作為最基礎的數據對象：

接下來創建一個 UserService 接口作為服務接口，其中定義了 5 個方法，分別用來創建 User、查詢 User 以及相關信息、刪除 User：

UserServiceImpl 是 UserService 接口的實現類，其中使用一個 ArrayList 集合管理 User 對象，具體實現如下：

整個用戶管理業務的核心大致如此。下面我們來看服務端如何將 UserService 與 JSON-RPC 關聯起來。

首先，創建 RpcServlet 類，它是 HttpServlet 的子類，并覆蓋了 HttpServlet 的 service() 方法。我們知道，HttpServlet 在收到 GET 和 POST 請求的時候，最終會調用其 service() 方法進行處理；HttpServlet 還會將 HTTP 請求和響應封裝成 HttpServletRequest 和 HttpServletResponse 傳入 service() 方法之中。這里的 RpcServlet 實現之中會創建一個 JsonRpcServer，并在 service() 方法中將 HTTP 請求委托給 JsonRpcServer 進行處理：

最后，創建一個 JsonRpcServer 作為服務端的入口類，在其 main() 方法中會啟動 Jetty 作為 Web 容器，具體實現如下：

這里使用到的 web.xml 配置文件如下：

完成服務端的編寫之后，下面再繼續編寫 JSON-RPC 的客戶端。在 JsonRpcClient 中會創建 JsonRpcHttpClient，并通過 JsonRpcHttpClient 請求服務端：

在 AbstractProxyProtocol 的 export() 方法中，首先會根據 URL 檢查 exporterMap 緩存，如果查詢失敗，則會調用 ProxyFactory.getProxy() 方法將 Invoker 封裝成業務接口的代理類，然后通過子類實現的 doExport() 方法啟動底層的 ProxyProtocolServer，并初始化 serverMap 集合。具體實現如下：

在 HttpProtocol 的 doExport() 方法中，與前面介紹的 DubboProtocol 的實現類似，也要啟動一個 RemotingServer。為了適配各種 HTTP 服務器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 層抽象出了一個 HttpServer 的接口。

dubbo-remoting-http 模塊的入口是 HttpBinder 接口，它被 @SPI 注解修飾，是一個擴展接口，有三個擴展實現，默認使用的是 JettyHttpBinder 實現，如下圖所示：

HttpBinder 接口中的 bind() 方法被 @Adaptive 注解修飾，會根據 URL 的 server 參數選擇相應的 HttpBinder 擴展實現，不同 HttpBinder 實現返回相應的 HttpServer 實現。HttpServer 的繼承關系如下圖所示：

這里以 JettyHttpServer 為例簡單介紹 HttpServer 的實現，在 JettyHttpServer 中會初始化 Jetty Server，其中會配置 Jetty Server 使用到的線程池以及處理請求 Handler：

可以看到 JettyHttpServer 收到的全部請求將委托給 DispatcherServlet 這個 HttpServlet 實現，而 DispatcherServlet 的 service() 方法會把請求委托給對應接端口的 HttpHandler 處理：

了解了 Dubbo 對 HttpServer 的抽象以及 JettyHttpServer 的核心之后，回到 HttpProtocol 中的 doExport() 方法繼續分析。

在 HttpProtocol.doExport() 方法中會通過 HttpBinder 創建前面介紹的 HttpServer 對象，并記錄到 serverMap 中用來接收 HTTP 請求。這里初始化 HttpServer 以及處理請求用到的 HttpHandler 是 HttpProtocol 中的內部類，在其他使用 HTTP 協議作為基礎的 RPC 協議實現中也有類似的 HttpHandler 實現類，如下圖所示：

在 HttpProtocol.InternalHandler 中的 handle() 實現中，會將請求委托給 skeletonMap 集合中記錄的 JsonRpcServer 對象進行處理：

skeletonMap 集合中的 JsonRpcServer 是與 HttpServer 對象一同在 doExport() 方法中初始化的。最后，我們來看 HttpProtocol.doExport() 方法的實現：

介紹完 HttpProtocol 暴露服務的相關實現之后，下面再來看 HttpProtocol 中引用服務相關的方法實現，即 protocolBindinRefer() 方法實現。該方法首先通過 doRefer() 方法創建業務接口的代理，這里會使用到 jsonrpc4j 庫中的 JsonProxyFactoryBean 與 Spring 進行集成，在其 afterPropertiesSet() 方法中會創建 JsonRpcHttpClient 對象：

下面來看 doRefer() 方法的具體實現：

在 AbstractProxyProtocol.protocolBindingRefer() 方法中，會通過 ProxyFactory.getInvoker() 方法將 doRefer() 方法返回的代理對象轉換成 Invoker 對象，并記錄到 Invokers 集合中，具體實現如下：

本文重點介紹了在 Dubbo 中如何通過“HTTP 協議 + JSON-RPC”的方案實現跨語言調用。首先介紹了 JSON-RPC 中請求和響應的基本格式，以及其實現庫 jsonrpc4j 的基本使用；接下來我們還詳細介紹了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心類，剖析了 Dubbo 中“HTTP 協議 + JSON-RPC”方案的落地實現。

文章標題：go語言的dubbo,go語言的優點和缺點
標題路徑：http://vcdvsql.cn/article12/hshsdc.html

成都網站建設公司_創新互聯，為您提供品牌網站建設、域名注冊、品牌網站設計、移動網站建設、網站排名、用戶體驗

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯