在 gRPC 里客戶端應(yīng)用可以像調(diào)用本地對(duì)象一樣直接調(diào)用另一臺(tái)不同的機(jī)器上服務(wù)端 應(yīng)用的方法,使得您能夠更容易地創(chuàng)建分布式應(yīng)用和服務(wù)。與許多 RPC 系統(tǒng)類似,gRPC 也是基于以下理念:定義一個(gè)服務(wù),指定其能夠被遠(yuǎn)程調(diào)用的方法(包含參數(shù)和返回類型)。在服務(wù)端實(shí)現(xiàn)這個(gè)接口,并運(yùn)行一個(gè) gRPC 服務(wù)器來(lái)處理客戶端調(diào)用。在客戶端擁有一個(gè)存根能夠像服務(wù)端一樣的方法。
成都創(chuàng)新互聯(lián)成立與2013年,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元興山做網(wǎng)站,已為上家服務(wù),為興山各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220
gRPC 客戶端和服務(wù)端可以在多種環(huán)境中運(yùn)行和交互 - 從 google 內(nèi)部的服務(wù)器到你自己的筆記本,并且可以用任何 gRPC 支持的語(yǔ)言來(lái)編寫(xiě)。所以,你可以很容易地用 Java 創(chuàng)建一個(gè) gRPC 服務(wù)端,用 Go、Python、Ruby 來(lái)創(chuàng)建客戶端。此外,Google 最新 API 將有 gRPC 版本的接口,使你很容易地將 Google 的功能集成到你的應(yīng)用里。
gRPC 默認(rèn)使用 protocol buffers,這是 Google 開(kāi)源的一套成熟的結(jié)構(gòu)數(shù)據(jù)序列化機(jī)制(當(dāng)然也可以使用其他數(shù)據(jù)格式如 JSON)。名叫 proto3 的新風(fēng)格的 protocol buffers,它擁有輕量簡(jiǎn)化的語(yǔ)法、一些有用的新功能,并且支持更多新語(yǔ)言。當(dāng)前針對(duì) Java 和 C++ 發(fā)布了 beta 版本,針對(duì) JavaNano(即 Android Java)發(fā)布 alpha 版本,在protocol buffers Github 源碼庫(kù)里有 Ruby 支持, 在golang/protobuf Github 源碼庫(kù)里還有針對(duì) Go 語(yǔ)言的生成器, 對(duì)更多語(yǔ)言的支持正在開(kāi)發(fā)中。
有了 gRPC, 我們可以一次性的在一個(gè) .proto 文件中定義服務(wù)并使用任何支持它的語(yǔ)言去實(shí)現(xiàn)客戶端和服務(wù)器,反過(guò)來(lái),它們可以在各種環(huán)境中,從Google的服務(wù)器到你自己的平板電腦—— gRPC 幫你解決了不同語(yǔ)言及環(huán)境間通信的復(fù)雜性.使用 protocol buffers 還能獲得其他好處,包括高效的序列號(hào),簡(jiǎn)單的 IDL 以及容易進(jìn)行接口更新。
現(xiàn)在讓我們來(lái)仔細(xì)了解一下當(dāng) gRPC 客戶端調(diào)用 gRPC 服務(wù)端的方法時(shí)到底發(fā)生了什么。我們不究其實(shí)現(xiàn)細(xì)節(jié),關(guān)于實(shí)現(xiàn)細(xì)節(jié)的部分,你可以在我們的特定語(yǔ)言頁(yè)面里找到更為詳盡的內(nèi)容。
首先我們來(lái)了解一下最簡(jiǎn)單的 RPC 形式:客戶端發(fā)出單個(gè)請(qǐng)求,獲得單個(gè)響應(yīng)。
服務(wù)端流式 RPC 除了在得到客戶端請(qǐng)求信息后發(fā)送回一個(gè)應(yīng)答流之外,與我們的簡(jiǎn)單例子一樣。在發(fā)送完所有應(yīng)答后,服務(wù)端的狀態(tài)詳情(狀態(tài)碼和可選的狀態(tài)信息)和可選的跟蹤元數(shù)據(jù)被發(fā)送回客戶端,以此來(lái)完成服務(wù)端的工作??蛻舳嗽诮邮盏剿蟹?wù)端的應(yīng)答后也完成了工作。
客戶端流式 RPC 也基本與我們的簡(jiǎn)單例子一樣,區(qū)別在于客戶端通過(guò)發(fā)送一個(gè)請(qǐng)求流給服務(wù)端,取代了原先發(fā)送的單個(gè)請(qǐng)求。服務(wù)端通常(但并不必須)會(huì)在接收到客戶端所有的請(qǐng)求后發(fā)送回一個(gè)應(yīng)答,其中附帶有它的狀態(tài)詳情和可選的跟蹤數(shù)據(jù)。
雙向流式 RPC ,調(diào)用由客戶端調(diào)用方法來(lái)初始化,而服務(wù)端則接收到客戶端的元數(shù)據(jù),方法名和截止時(shí)間。服務(wù)端可以選擇發(fā)送回它的初始元數(shù)據(jù)或等待客戶端發(fā)送請(qǐng)求。 下一步怎樣發(fā)展取決于應(yīng)用,因?yàn)榭蛻舳撕头?wù)端能在任意順序上讀寫(xiě) - 這些流的操作是完全獨(dú)立的。例如服務(wù)端可以一直等直到它接收到所有客戶端的消息才寫(xiě)應(yīng)答,或者服務(wù)端和客戶端可以像"乒乓球"一樣:服務(wù)端后得到一個(gè)請(qǐng)求就回送一個(gè)應(yīng)答,接著客戶端根據(jù)應(yīng)答來(lái)發(fā)送另一個(gè)請(qǐng)求,以此類推。
通過(guò)運(yùn)行下面的命令克隆并安裝grpc-go代碼庫(kù):
下載protobuf源碼包
安裝golang-protobuf
第一步使用 protocol buffers去定義 gRPC service 和方法 request 以及 response 的類型。
要定義一個(gè)服務(wù),必須在.proto 文件中指定 service:
然后在服務(wù)中定義 rpc 方法,指定請(qǐng)求的和響應(yīng)類型,gRPC 允許定義4種類型的 service 方法。
服務(wù).proto文件如下所示:
Micro的api就是api網(wǎng)關(guān)
API參考了 API網(wǎng)關(guān)模式 為服務(wù)提供了一個(gè)單一的公共入口?;诜?wù)發(fā)現(xiàn),使得micro api可以提供具備http及動(dòng)態(tài)路由的服務(wù)。
Micro的API基于HTTP協(xié)議。請(qǐng)求的API接口通過(guò)HTTP協(xié)議訪問(wèn),并且路由是基于服務(wù)發(fā)現(xiàn)機(jī)制向下轉(zhuǎn)發(fā)的。 Micro API在 go-micro 之上開(kāi)發(fā),所以它集成了服務(wù)發(fā)現(xiàn)、負(fù)載均衡、編碼及基于RPC的通信。
因?yàn)閙icro api內(nèi)部使用了go-micro,所以它自身也是可插拔的。 參考 go-plugins 了解對(duì)gRPC、kubernetes、etcd、nats、及rabbitmq等支持。另外,api也使用了 go-api ,這樣,接口handler也是可以配置的。
ACME( Automatic Certificate Management Environment)是由 Let’s Encrypt 制定的安全協(xié)議。
可以選擇是否配置白名單
API服務(wù)支持TLS證書(shū)
API使用帶分隔符的命名空間來(lái)在邏輯上區(qū)分后臺(tái)服務(wù)及公開(kāi)的服務(wù)。命名空間及http請(qǐng)求路徑會(huì)用于解析服務(wù)名與方法,比如 GET /foo HTTP/1.1 會(huì)被路由到 go.micro.api.foo 服務(wù)上。
API默認(rèn)的命名空間是 go.micro.api ,當(dāng)然,也可以修改:
我們演示一個(gè)3層的服務(wù)架構(gòu):
完整示例可以參考: examples/greeter
先決條件:我們使用Consul作為默認(rèn)的服務(wù)發(fā)現(xiàn),所以請(qǐng)先確定它已經(jīng)安裝好了,并且已經(jīng)運(yùn)行,比如執(zhí)行 consul agent -dev 這樣子方式運(yùn)行。
向micro api發(fā)起http請(qǐng)求
HTTP請(qǐng)求的路徑 /greeter/say/hello 會(huì)被路由到服務(wù) go.micro.api.greeter 的方法 Say.Hello 上。
繞開(kāi)api服務(wù)并且直接通過(guò)rpc調(diào)用:
使用JSON的方式執(zhí)行同一請(qǐng)求:
micro api提供下面類型的http api接口
請(qǐng)看下面的例子
Handler負(fù)責(zé)持有并管理HTTP請(qǐng)求路由。
默認(rèn)的handler使用從注冊(cè)中心獲取的端口元數(shù)據(jù)來(lái)決定指向服務(wù)的路由,如果路由不匹配,就會(huì)回退到使用”rpc” hander。在注冊(cè)時(shí),可以通過(guò) go-api 來(lái)配置路由。
API有如下方法可以配置請(qǐng)求handler:
通過(guò) /rpc 入口可以繞開(kāi)handler處理器。
API處理器接收任何的HTTP請(qǐng)求,并且向前轉(zhuǎn)發(fā)指定格式的RPC請(qǐng)求。
RPC處理器接收json或protobuf格式的HTTP POST請(qǐng)求,然后向前轉(zhuǎn)成RPC請(qǐng)求。
代理Handler其實(shí)是內(nèi)置在服務(wù)發(fā)現(xiàn)中的反向代理服務(wù)。
事件處理器使用go-micro的broker代理接收http請(qǐng)求并把請(qǐng)求作為消息傳到消息總線上。
Web處理器是,它是內(nèi)置在服務(wù)發(fā)現(xiàn)中的HTTP反向代理服務(wù),支持web socket。
/rpc 端點(diǎn)允許繞過(guò)主handler,然后與任何服務(wù)直接會(huì)話。
示例:
更多信息查看可運(yùn)行的示例: github.com/micro/examples/api
解析器,Micro使用命名空間與HTTP請(qǐng)求路徑來(lái)動(dòng)態(tài)路由到具體的服務(wù)。
API命名的空間是 go.micro.api ??梢酝ㄟ^(guò)指令 --namespace 或者環(huán)境變量 MICRO_NAMESPACE= 設(shè)置命名空間。
下面說(shuō)一下解析器是如何使用的:
RPC解析器示例中的RPC服務(wù)有名稱與方法,分別是 go.micro.api.greeter , Greeter.Hello 。
URL會(huì)被解析成以下幾部分:
帶版本號(hào)的API URL也可以很容易定位到具體的服務(wù):
代理解析器只處理服務(wù)名,所以處理方案和RPC解析器有點(diǎn)不太一樣。
URL會(huì)被解析成以下幾部分:
網(wǎng)關(guān)=反向代理+負(fù)載均衡+各種策略,技術(shù)實(shí)現(xiàn)也有多種多樣,有基于 nginx 使用 lua 的實(shí)現(xiàn),比如 openresty、kong;也有基于 zuul 的通用網(wǎng)關(guān);還有就是 golang 的網(wǎng)關(guān),比如 tyk。
這篇文章主要是講如何基于 golang 實(shí)現(xiàn)一個(gè)簡(jiǎn)單的網(wǎng)關(guān)。
轉(zhuǎn)自: troy.wang/docs/golang/posts/golang-gateway/
整理:go語(yǔ)言鐘文文檔:
啟動(dòng)兩個(gè)后端 web 服務(wù)(代碼)
這里使用命令行工具進(jìn)行測(cè)試
具體代碼
直接使用基礎(chǔ)庫(kù) httputil 提供的NewSingleHostReverseProxy即可,返回的reverseProxy對(duì)象實(shí)現(xiàn)了serveHttp方法,因此可以直接作為 handler。
具體代碼
director中定義回調(diào)函數(shù),入?yún)?http.Request,決定如何構(gòu)造向后端的請(qǐng)求,比如 host 是否向后傳遞,是否進(jìn)行 url 重寫(xiě),對(duì)于 header 的處理,后端 target 的選擇等,都可以在這里完成。
director在這里具體做了:
modifyResponse中定義回調(diào)函數(shù),入?yún)?http.Response,用于修改響應(yīng)的信息,比如響應(yīng)的 Body,響應(yīng)的 Header 等信息。
最終依舊是返回一個(gè)ReverseProxy,然后將這個(gè)對(duì)象作為 handler 傳入即可。
參考 2.2 中的NewSingleHostReverseProxy,只需要實(shí)現(xiàn)一個(gè)類似的、支持多 targets 的方法即可,具體實(shí)現(xiàn)見(jiàn)后面。
作為一個(gè)網(wǎng)關(guān)服務(wù),在上面 2.3 的基礎(chǔ)上,需要支持必要的負(fù)載均衡策略,比如:
隨便 random 一個(gè)整數(shù)作為索引,然后取對(duì)應(yīng)的地址即可,實(shí)現(xiàn)比較簡(jiǎn)單。
具體代碼
使用curIndex進(jìn)行累加計(jì)數(shù),一旦超過(guò) rss 數(shù)組的長(zhǎng)度,則重置。
具體代碼
輪詢帶權(quán)重,如果使用計(jì)數(shù)遞減的方式,如果權(quán)重是5,1,1那么后端 rs 依次為a,a,a,a,a,b,c,a,a,a,a…,其中 a 后端會(huì)瞬間壓力過(guò)大;參考 nginx 內(nèi)部的加權(quán)輪詢,或者應(yīng)該稱之為平滑加權(quán)輪詢,思路是:
后端真實(shí)節(jié)點(diǎn)包含三個(gè)權(quán)重:
操作步驟:
具體代碼
一致性 hash 算法,主要是用于分布式 cache 熱點(diǎn)/命中問(wèn)題;這里用于基于某 key 的 hash 值,路由到固定后端,但是只能是基本滿足流量綁定,一旦后端目標(biāo)節(jié)點(diǎn)故障,會(huì)自動(dòng)平移到環(huán)上最近的那么個(gè)節(jié)點(diǎn)。
實(shí)現(xiàn):
具體代碼
每一種不同的負(fù)載均衡算法,只需要實(shí)現(xiàn)添加以及獲取的接口即可。
然后使用工廠方法,根據(jù)傳入的參數(shù),決定使用哪種負(fù)載均衡策略。
具體代碼
作為網(wǎng)關(guān),中間件必不可少,這類包括請(qǐng)求響應(yīng)的模式,一般稱作洋蔥模式,每一層都是中間件,一層層進(jìn)去,然后一層層出來(lái)。
中間件的實(shí)現(xiàn)一般有兩種,一種是使用數(shù)組,然后配合 index 計(jì)數(shù);一種是鏈?zhǔn)秸{(diào)用。
具體代碼
網(wǎng)頁(yè)題目:go語(yǔ)言rpc路由 golang rpc框架
URL分享:http://vcdvsql.cn/article0/hepdio.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供做網(wǎng)站、企業(yè)網(wǎng)站制作、電子商務(wù)、虛擬主機(jī)、全網(wǎng)營(yíng)銷推廣、自適應(yīng)網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)