gRPC服務(wù)開發(fā)和接口測試初探「Go」

之前寫過了Grpc服務(wù)開發(fā)和接口測試初探【Java】，中間耽擱了一些時(shí)間，Go版本的gRPC測試開發(fā)實(shí)踐才有時(shí)間學(xué)習(xí)使用。其中也是由于自己Go語言不夠熟悉導(dǎo)致的。之前有段時(shí)間想暫時(shí)放棄Go語言的學(xué)習(xí)，導(dǎo)致了Go的生疏，原因是從Groovy到Java性能。

創(chuàng)新互聯(lián)是一家專注于成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)與策劃設(shè)計(jì),鎮(zhèn)沅網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:鎮(zhèn)沅等地區(qū)。鎮(zhèn)沅做網(wǎng)站價(jià)格咨詢:028-86922220

回歸正題，Go語言版本的gRPC實(shí)踐相對Java來說是比較簡單的，但是總體的工具鏈?zhǔn)潜容^復(fù)雜的，可能是因?yàn)镚o生態(tài)目前相比Java還是比較匱乏吧。下面我先簡述一下大致的步驟：

以上步驟親自操作可能會遇到一些小問題，我本人搜到的教程什么的也是亂七八糟，踩了一些坑。我沒有整理出一個(gè)親自實(shí)踐之后的可行的教程，原因有二：

Go語言的gRPC的 proto 編寫跟Java大致一致，只有一個(gè)報(bào)名的參數(shù)不太一樣。下面是我的 Hello.proto 內(nèi)容：

這里主要 go_package 網(wǎng)上搜到的配置方式有些不一樣，我沒有全都嘗試，大家在搜索的資料時(shí)候，盡量先看看 syntax 這個(gè)參數(shù)的值，以及文章教程寫作的時(shí)間，如果距離現(xiàn)在太久了，我建議直接關(guān)掉。搜索引擎有過濾功能，可以過濾掉過時(shí)的教程。

這里Go語言gRPC的一點(diǎn)優(yōu)勢，就是在一個(gè)項(xiàng)目中即可實(shí)現(xiàn)，Java需要先弄一個(gè)SDK這樣。Go語言的gRPC的代碼可以通過生成代碼命令中的參數(shù)實(shí)現(xiàn)指定路徑。我是放在了和 proto 文件的同級目錄。

服務(wù)端代碼也是比較格式化的內(nèi)容，如下：

其中 pb.RegisterHelloServiceServer(s, Ser{}) 如果報(bào)錯(cuò)，請檢查自己安裝的工具 protoc-gen-go 或者 protoc-gen-gofast 版本，一般提取報(bào)錯(cuò) message 搜索也能得到解決辦法。

下面是客戶端的代碼，由于學(xué)藝不精，其中大部分參數(shù)的含義目前我也不是很清楚，特別是基于 stream 的請求響應(yīng)的方式使用。后面我先把Java的學(xué)完，再回過頭來看Go的，按照這個(gè)順序?qū)W習(xí)和分享。

服務(wù)端輸出：

忘記打日志了。沒有輸出

客戶端輸出：

Go語言的gRPC測試開發(fā)實(shí)踐已經(jīng)完事兒，大概率上我不會在工作中使用Go作為主力gRPC測試語言，后面測試實(shí)踐內(nèi)容還是會以Java為主。

為什么我不喜歡Go語言式的接口

所謂Go語言式的接口，就是不用顯示聲明類型T實(shí)現(xiàn)了接口I，只要類型T的公開方法完全滿足接口I的要求，就可以把類型T的對象用在需要接口I的地方。這種做法的學(xué)名叫做Structural Typing，有人也把它看作是一種靜態(tài)的Duck Typing。除了Go的接口以外，類似的東西也有比如Scala里的Traits等等。有人覺得這個(gè)特性很好，但我個(gè)人并不喜歡這種做法，所以在這里談?wù)勊娜秉c(diǎn)。當(dāng)然這跟動態(tài)語言靜態(tài)語言的討論類似，不能簡單粗暴的下一個(gè)“好”或“不好”的結(jié)論。

我的觀點(diǎn):

Go的隱式接口Duck Typing確實(shí)不是新技術(shù), 但是在主流靜態(tài)編程語言中支持Duck Typing應(yīng)該是很少的(不清楚目前是否只有Go語言支持).

靜態(tài)類型和動態(tài)類型雖然沒有絕對的好和不好, 但是每個(gè)都是有自己的優(yōu)勢的, 沒有哪一個(gè)可以包辦一切. 而Go是試圖結(jié)合靜態(tài)類型和動態(tài)類型(interface)各自的優(yōu)勢.

那么就從頭談起：什么是接口。其實(shí)通俗的講，接口就是一個(gè)協(xié)議，規(guī)定了一組成員，例如.NET里的ICollection接口：

public interface ICollection {

int Count { get; }

object SyncRoot { get; }

bool IsSynchronized { get; }

void CopyTo(Array array, int index);

}

這就是一個(gè)協(xié)議的全部了嗎？事實(shí)并非如此，其實(shí)接口還規(guī)定了每個(gè)行為的“特征”。打個(gè)比方，這個(gè)接口的Count除了需要返回集合內(nèi)元素的數(shù)目以外，還隱含了它需要在O(1)時(shí)間內(nèi)返回這個(gè)要求。這樣一個(gè)使用了ICollection接口的方法才能放心地使用Count屬性來獲取集合大小，才能在知道這些特征的情況下選用正確的算法來編寫程序，而不用擔(dān)心帶來性能問題，這才能實(shí)現(xiàn)所謂的“面向接口編程”。當(dāng)然這種“特征”并不但指“性能”上的，例如Count還包含了例如“不修改集合內(nèi)容”這種看似十分自然的隱藏要求，這都是ICollection協(xié)議的一部分。

使用Go 語言開發(fā)大型 MMORPG 游戲服務(wù)器怎么樣

從2013年起,經(jīng)朋友推薦開始用Golang編寫游戲登陸服務(wù)器, 配合C++做第三方平臺驗(yàn)證. 到編寫?yīng)毩⒐ぞ邔?dǎo)表工具GitHub - davyxu/tabtoy: 跨平臺的高性能便捷電子表格導(dǎo)出器. 以及網(wǎng)絡(luò)庫GitHub - davyxu/cellnet: 簡單,方便,高效的Go語言的游戲服務(wù)器底層. 最終使用這些工具及庫編寫整個(gè)游戲服務(wù)器框架, 我的感受是很不錯(cuò)的

細(xì)節(jié)看來, 有如下的幾個(gè)點(diǎn):

語言, 庫

Golang語言特性和C很像, 簡單, 一張A4紙就能寫完所有特性. 你想想看, C++到了領(lǐng)悟階段, 也只用那幾個(gè)簡單特性, 剩下的都是一大堆解決各種內(nèi)存問題的技巧. 而Golang一開始就簡單, 何必浪費(fèi)生命去研究那一大堆的奇技淫巧呢?

Golang的坑只有2個(gè):1. interface{}和nil配合使用, 2. for循環(huán)時(shí), 將循環(huán)變量引入閉包(Golang, Lua, C#閉包變量捕獲差異) 完全不影響正常使用, 復(fù)合語言概念, 只是看官方后面怎么有效的避免

用Golang就忘記繼承那套東西, 用組合+接口

用Golang服務(wù)器如何保證解決游戲服務(wù)器存盤一致性問題? stop the world是肯定的, 但是Golang可以從語言層并發(fā)序列化玩家數(shù)據(jù), 再通過后臺存盤

channel是goroutine雖然是Golang的語言特性. 但是在編寫服務(wù)器時(shí), 其實(shí)只有底層用的比較多.

Golang的第三方庫簡直多如牛毛, 好的也很多

不要說模板了, C#的也不好用, 官方在糾結(jié)也不要加, 使用中, 沒模板確實(shí)有點(diǎn)不方便. 用interface{}/反射做泛型對于Golang這種強(qiáng)類型語言來說,還是有點(diǎn)打臉

運(yùn)行期

Golang和C++比性能的話, 這是C++的優(yōu)勢, Golang因?yàn)闆]虛擬機(jī), 只有薄薄的一層調(diào)度層. 因此性能是非常高的, 用一點(diǎn)性能犧牲換開發(fā)效率, 妥妥的

1.6版后的GC優(yōu)化的已經(jīng)很好了, 如果你不是高性能,高并發(fā)Web應(yīng)用, 非要找出一堆的優(yōu)化技巧的話. 只用Golang寫點(diǎn)游戲服務(wù)器, 那點(diǎn)GC損耗可以忽略不計(jì)

和其他現(xiàn)代語言一樣, 崩潰捕捉是標(biāo)配功能, 我用Golang的服務(wù)器線上跑, 基本沒碰到過崩潰情況

熱更新: 官方已經(jīng)有plugin系統(tǒng)的提交, 跨平臺的. 估計(jì)很快就可以告別手動cgo做so熱更新

開發(fā), 調(diào)試, 部署, 優(yōu)化

LiteIDE是我首選的Golang的IDE, 雖然有童鞋說B格不高. 但這估計(jì)實(shí)在是找不到缺點(diǎn)說了, 別跟我說Visual Studio, 那是宇宙級的...

曾經(jīng)聽說有人不看好Golang, 我問為啥: 說這么新的語言, 不好招人,后面打聽到他是個(gè)策劃... 好吧

真實(shí)情況是這樣的: Golang對于有點(diǎn)編程基礎(chǔ)的新人來說, 1周左右可以開始貢獻(xiàn)代碼. 老司機(jī)2~3天.

開發(fā)效率還是不錯(cuò)的, 一般大的游戲功能, 2*2人一周3~4個(gè)整完. 這換C++時(shí)代, 大概也就1~2個(gè)還寫不完. 對接服務(wù)器sdk的話, 大概1天接個(gè)10多個(gè)沒問題

Golang自帶性能調(diào)優(yōu)工具, 從內(nèi)存, CPU, 阻塞點(diǎn)等幾個(gè)方面直接出圖進(jìn)行分析, 非常直觀, 可以參考我博客幾年前的分析: 使用Golang進(jìn)行性能分析(Profiling)

Golang支持交叉編譯, 跨平臺部署, 什么概念? linux是吧? 不問你什么版本, 直接windows上編譯輸出一個(gè)elf, 甩到服務(wù)器上開跑.不超過1分鐘時(shí)間..

Go語言HTTPServer開發(fā)的六種實(shí)現(xiàn)

學(xué)完了 net/http 和 fasthttp 兩個(gè)HTTP協(xié)議接口的客戶端實(shí)現(xiàn)，接下來就要開始Server的開發(fā)，不學(xué)不知道一學(xué)嚇一跳，居然這兩個(gè)庫還支持Server的開發(fā)，太方便了。

相比于Java的HTTPServer開發(fā)基本上都是使用Spring或者Springboot框架，總是要配置各種配置類，各種 handle 對象。Golang的Server開發(fā)顯得非常簡單，就是因?yàn)樘貏e簡單，或者說沒有形成特別統(tǒng)一的規(guī)范或者框架，我發(fā)現(xiàn)了很多實(shí)現(xiàn)方式，HTTP協(xié)議基于還是 net/http 和 fasthttp ，但是 handle 語法就多種多樣了。

先復(fù)習(xí)一下： Golang語言HTTP客戶端實(shí)踐 、 Golang fasthttp實(shí)踐 。

在Golang語言方面，實(shí)現(xiàn)某個(gè)功能的庫可能會比較多，有機(jī)會還是要多跟同行交流，指不定就發(fā)現(xiàn)了更好用的庫。下面我分享我學(xué)到的六種Server開發(fā)的實(shí)現(xiàn)Demo。

基于 net/http 實(shí)現(xiàn)，這是一種比較基礎(chǔ)的，對于接口和 handle 映射關(guān)系處理并不優(yōu)雅，不推薦使用。

第二種也是基于 net/http ，這種編寫語法可以很好地解決第一種的問題，handle和path有了類似配置的語法，可讀性提高了很多。

第三個(gè)基于 net/http 和 github.com/labstack/echo ，后者主要提供了 Echo 對象用來處理各類配置包括接口和handle映射，功能很豐富，可讀性最佳。

第四種依然基于 net/http 實(shí)現(xiàn)，引入了 github.com/gin-gonic/gin 的路由，看起來接口和 handle 映射關(guān)系比較明晰了。

第五種基于 fasthttp 開發(fā)，使用都是 fasthttp 提供的API，可讀性尚可，handle配置倒是更像Java了。

第六種依然基于 fasthttp ，用到了 github.com/buaazp/fasthttprouter ，有點(diǎn)奇怪兩個(gè)居然不在一個(gè)GitHub倉庫里。使用語法跟第三種方式有點(diǎn)類似，比較有條理，有利于閱讀。

分享標(biāo)題：go語言開發(fā)后臺接口,go 面向接口編程
標(biāo)題URL：http://aaarwkj.com/article46/dsspieg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、網(wǎng)站制作、靜態(tài)網(wǎng)站、App開發(fā)、電子商務(wù)、品牌網(wǎng)站制作

廣告

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