微服務(wù)跨語言調(diào)用（摘選）

微服務(wù)架構(gòu)已成為目前互聯(lián)網(wǎng)架構(gòu)的趨勢，關(guān)于微服務(wù)的討論，幾乎占據(jù)了各種技術(shù)大會的絕大多數(shù)版面。國內(nèi)使用最多的服務(wù)治理框架非阿里開源的 dubbo 莫屬，千米網(wǎng)也選擇了 dubbo 作為微服務(wù)治理框架。另一方面，和大多數(shù)互聯(lián)網(wǎng)公司一樣，千米的開發(fā)語言是多樣的，大多數(shù)后端業(yè)務(wù)由 java 支撐，而每個業(yè)務(wù)線有各自開發(fā)語言的選擇權(quán)，便出現(xiàn)了 nodejs，python，go 多語言調(diào)用的問題。

創(chuàng)新互聯(lián)公司是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，專業(yè)領(lǐng)域包括成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、電商網(wǎng)站制作開發(fā)、微信小程序定制開發(fā)、微信營銷、系統(tǒng)平臺開發(fā)，與其他網(wǎng)站設(shè)計及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！

跨語言調(diào)用是一個很大的話題，也是一個很有挑戰(zhàn)的技術(shù)活，目前業(yè)界經(jīng)常被提及的解決方案有如下幾種，不妨拿出來老生常談一番：

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

如果一個新型的團(tuán)隊面臨技術(shù)選型，我認(rèn)為上述的方案都可以納入?yún)⒖迹煽紤]到遺留系統(tǒng)的兼容性問題

舊系統(tǒng)的遷移成本

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

通用協(xié)議的跨語言支持

springmvc的美好時代

springmvc

springmvc

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

通用協(xié)議的支持

事實上，大多數(shù)服務(wù)治理框架都支持多種協(xié)議，dubbo 框架除默認(rèn)的 dubbo 協(xié)議之外，還有當(dāng)當(dāng)網(wǎng)擴展的?rest協(xié)議和千米網(wǎng)擴展的?json-rpc?協(xié)議可供選擇。這兩者都是通用的跨語言協(xié)議。

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

和 rest 協(xié)議類似，json-rpc 的實現(xiàn)也是文本序列化http 協(xié)議。dubbox 在 restful 接口上已經(jīng)做出了嘗試，但是 rest 架構(gòu)和 dubbo 原有的 rpc 架構(gòu)是有區(qū)別的，rest 架構(gòu)需要對資源(Resources)進(jìn)行定義， 需要用到 http 協(xié)議的基本操作 GET、POST、PUT、DELETE。在我們看來，restful 更合適互聯(lián)網(wǎng)系統(tǒng)之間的調(diào)用，而 rpc 更適合一個系統(tǒng)內(nèi)的調(diào)用。使用 json-rpc 協(xié)議使得舊接口得以兼顧，開發(fā)習(xí)慣仍舊保留，同時獲得了跨語言的能力。

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

dubbo 協(xié)議主要支持 java 間的相互調(diào)用，適配老接口；json-rpc 協(xié)議主要支持異構(gòu)語言的調(diào)用。

定制協(xié)議的跨語言支持

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

motan2協(xié)議的跨語言支持

???motan2

motan2

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

???agent

agent

仔細(xì)揣摩下可以發(fā)現(xiàn)這么做和雙協(xié)議的配置區(qū)別并不是大，只不過這里的 agent 是隱式存在的，與主服務(wù)共生。明顯的區(qū)別在于 agent 方案中異構(gòu)語言并不直接交互。

dubbo協(xié)議的跨語言支持

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

Dubbo協(xié)議報文格式

???dubbo協(xié)議

dubbo協(xié)議

dubbo協(xié)議報文消息頭詳解：

magic：類似java字節(jié)碼文件里的魔數(shù)，用來判斷是不是 dubbo 協(xié)議的數(shù)據(jù)包。魔數(shù)是常量 0xdabb

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

status：狀態(tài)位, 設(shè)置請求響應(yīng)狀態(tài)，dubbo 定義了一些響應(yīng)的類型。具體類型見com.alibaba.dubbo.remoting.exchange.Response

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

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

body content：請求參數(shù)，響應(yīng)參數(shù)的抽象序列化之后存儲于此。

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

ps：dubbo 協(xié)議通訊demo（ ）

Dubbo 協(xié)議

Dubbo是 Alibaba 開源的分布式服務(wù)框架遠(yuǎn)程調(diào)用框架，在網(wǎng)絡(luò)間傳輸數(shù)據(jù)，就需要通信協(xié)議和序列化。

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多種協(xié)議，但是Dubbo官網(wǎng)是推薦我們使用Dubbo協(xié)議的，默認(rèn)也是用的dubbo協(xié)議。

先介紹幾種常見的協(xié)議：

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

連接個數(shù)：單連接

連接方式：長連接

傳輸協(xié)議：TCP

傳輸方式：NIO異步傳輸

序列化：Hessian二進(jìn)制序列化

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

適用場景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用

1、dubbo默認(rèn)采用dubbo協(xié)議，dubbo協(xié)議采用單一長連接和NIO異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費者機器數(shù)遠(yuǎn)大于服務(wù)提供者機器數(shù)的情況

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

配置如下：

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協(xié)議缺省每服務(wù)每提供者每消費者使用單一長連接，如果數(shù)據(jù)量較大，可以使用多個連接。

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

4、為防止被大量連接撐掛，可在服務(wù)提供方限制大接收連接數(shù)，以實現(xiàn)服務(wù)提供方自我保護(hù)

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

Java標(biāo)準(zhǔn)的遠(yuǎn)程調(diào)用協(xié)議。

連接個數(shù)：多連接

連接方式：短連接

傳輸協(xié)議：TCP

傳輸方式：同步傳輸

序列化：Java標(biāo)準(zhǔn)二進(jìn)制序列化

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

適用場景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用，與原生RMI服務(wù)互操作

RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實現(xiàn)，采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式 。

基于Hessian的遠(yuǎn)程調(diào)用協(xié)議。

連接個數(shù)：多連接

連接方式：短連接

傳輸協(xié)議：HTTP

傳輸方式：同步傳輸

序列化：表單序列化

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

適用場景：需同時給應(yīng)用程序和瀏覽器JS使用的服務(wù)。

1、Hessian協(xié)議用于集成Hessian的服務(wù)，Hessian底層采用Http通訊，采用Servlet暴露服務(wù)，Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實現(xiàn)。

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

基于http表單的遠(yuǎn)程調(diào)用協(xié)議。參見：[HTTP協(xié)議使用說明]

連接個數(shù)：多連接

連接方式：短連接

傳輸協(xié)議：HTTP

傳輸方式：同步傳輸

序列化：表單序列化

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

適用場景：需同時給應(yīng)用程序和瀏覽器JS使用的服務(wù)。

基于WebService的遠(yuǎn)程調(diào)用協(xié)議。

連接個數(shù)：多連接

連接方式：短連接

傳輸協(xié)議：HTTP

傳輸方式：同步傳輸

序列化：SOAP文本序列化

適用場景：系統(tǒng)集成，跨語言調(diào)用

序列化是將一個對象變成一個二進(jìn)制流就是序列化， 反序列化是將二進(jìn)制流轉(zhuǎn)換成對象

為什么要序列化？

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

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

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

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

2022-04-03 dubbogo 調(diào)用部署在不同zk的同一服務(wù)

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

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

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

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

服務(wù)1 的日志如下：

服務(wù)2 的日志如下：

github-dubbogodemo

Go微服務(wù)--常見的微服務(wù)框架

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

Go在微服務(wù)框架中有其獨特的優(yōu)勢，至于優(yōu)勢在哪，自行g(shù)oogle。

1、GoKit框架

這是一個工具包的集合，可以幫助攻城獅構(gòu)建強大、可靠和可維護(hù)的微服務(wù)。提供了用于實現(xiàn)系統(tǒng)監(jiān)控和彈性模式組件的庫，例如日志、跟蹤、限流、熔斷等。

基于這個框架的應(yīng)用程序架構(gòu)由三個主要的部分組成：

傳輸層：用于網(wǎng)絡(luò)通信，服務(wù)通常使用HTTP或者gRPC等網(wǎng)絡(luò)傳輸協(xié)議，或者使用NATS等發(fā)布訂閱系統(tǒng)相互通信。

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

服務(wù)成：具體的業(yè)務(wù)邏輯實現(xiàn)

2、GoMicro框架

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

GoMicro的設(shè)計哲學(xué)是可插拔的架構(gòu)理念，提供了可快速構(gòu)建系統(tǒng)的組件，并且可以根據(jù)自身的需求對GoMicro提供的默認(rèn)實現(xiàn)進(jìn)行定制。所有插件都可在倉庫github.com/micro/go-plugins 中找到。

分布式架構(gòu)的注冊中心，該怎么選？

互聯(lián)網(wǎng)架構(gòu)下，大部分系統(tǒng)已經(jīng)轉(zhuǎn)型分布式。其中服務(wù)注冊發(fā)現(xiàn)中心，分布式服務(wù)中非常重要的組成部分。按需選擇合適的注冊中心，也變的尤為重要。

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

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

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

Zookeeper是大數(shù)據(jù)Hadoop中的一個分布式調(diào)度組件，強調(diào)數(shù)據(jù)一致性和擴展性，可用于服務(wù)的注冊和發(fā)現(xiàn)。她是dubbo中默認(rèn)的服務(wù)注冊中心，也是目前使用最廣泛的分布式服務(wù)發(fā)現(xiàn)組件。注重CAP理論中的CP。

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

1、通過HTTP接口和DNS協(xié)議調(diào)用API存儲鍵值對，使服務(wù)注冊和服務(wù)發(fā)現(xiàn)更容易；

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

3、支持key/value存儲動態(tài)配置

4、支持任意數(shù)量的區(qū)域

ETCD是一個高可用的分布式鍵值數(shù)據(jù)庫，可用于共享配置、服務(wù)的注冊和發(fā)現(xiàn)。ETCD采用Raft一致性算法，基于Go語言實現(xiàn)。ETCD作為后起之秀，又非常大的優(yōu)勢。

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

2、可選SSL客戶認(rèn)證機制，更安全；

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

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

Dubbo——HTTP 協(xié)議 + JSON-RPC

Protocol 還有一個實現(xiàn)分支是 AbstractProxyProtocol，如下圖所示：

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

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

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

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

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

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

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

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

在 JSON-RPC 的服務(wù)端收到調(diào)用請求之后，會查找到相應(yīng)的方法并進(jìn)行調(diào)用，然后將方法的返回值整理成如下格式，返回給客戶端：

JSON-RPC響應(yīng)中各個字段的含義如下：

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

首先，需要創(chuàng)建服務(wù)端和客戶端都需要的 domain 類以及服務(wù)接口。先來創(chuàng)建一個 User 類，作為最基礎(chǔ)的數(shù)據(jù)對象：

接下來創(chuàng)建一個 UserService 接口作為服務(wù)接口，其中定義了 5 個方法，分別用來創(chuàng)建 User、查詢 User 以及相關(guān)信息、刪除 User：

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

整個用戶管理業(yè)務(wù)的核心大致如此。下面我們來看服務(wù)端如何將 UserService 與 JSON-RPC 關(guān)聯(lián)起來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章標(biāo)題：go語言的dubbo,go語言的優(yōu)點和缺點
標(biāo)題路徑：http://chinadenli.net/article12/hshsdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、域名注冊、品牌網(wǎng)站設(shè)計、移動網(wǎng)站建設(shè)、網(wǎng)站排名、用戶體驗

廣告

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