Go 開源說第四期（上）：?go-zero解讀與最佳實(shí)踐

本文有『Go開源說』第四期 go-zero 直播內(nèi)容修改整理而成，視頻內(nèi)容較長(zhǎng)，拆分成上下篇，本文內(nèi)容有所刪減和重構(gòu)。

大家好，很高興來到“GO開源說” 跟大家分享開源項(xiàng)目背后的一些故事、設(shè)計(jì)思想以及使用方法，今天分享的項(xiàng)目是 go-zero，一個(gè)集成了各種工程實(shí)踐的 web 和 rpc 框架。我是Kevin，go-zero 作者，我的 github id 是 kevwan。

go-zero 概覽

go-zero 雖然是20年8月7號(hào)才開源，但是已經(jīng)經(jīng)過線上大規(guī)模檢驗(yàn)了，也是我近20年工程經(jīng)驗(yàn)的積累，開源后得到社區(qū)的積極反饋，在5個(gè)多月的時(shí)間里，獲得了5.9k star。多次登頂github Go語言日榜、周榜、月榜榜首，并獲得了gitee最有價(jià)值項(xiàng)目（GVP），開源中國(guó)年度最佳人氣項(xiàng)目。同時(shí)微信社區(qū)極為活躍，3000+人的社區(qū)群，go-zero愛好者們一起交流go-zero使用心得和討論使用過程中的問題。

下圖中間三層是 go-zero 內(nèi)建支持的服務(wù)治理相關(guān)組件，基本涵蓋了微服務(wù)治理主要的能力，而且是基本不需要開發(fā)者自己配置的，默認(rèn)方案已經(jīng)是經(jīng)過大規(guī)模線上項(xiàng)目調(diào)優(yōu)的。

微服務(wù)系統(tǒng)設(shè)計(jì)中的痛點(diǎn)

1. 微服務(wù)系統(tǒng)如何拆分？

• 先粗后細(xì)，不要過細(xì)，切忌一個(gè)接口一個(gè)服務(wù)

• 橫向拆分，而非縱向，我們盡量不要超過三層調(diào)用

• 單向調(diào)用，嚴(yán)禁循環(huán)調(diào)用

• 禁止接口類型透?jìng)鳎诓煌膶又g不要共享同一個(gè)數(shù)據(jù)定義，避免一處修改，影響其它

• 沒有依賴關(guān)系的串行調(diào)用改為并行，可以通過 core/mr 包降低響應(yīng)延遲而不增加系統(tǒng)負(fù)載

  

2. 如何保障高并發(fā)高可用？

• 良好的數(shù)據(jù)邊界

  數(shù)據(jù)邊界是微服務(wù)拆分的核心，不同的服務(wù)之間不要顯示共享數(shù)據(jù)，而應(yīng)該通過 rpc 共享。

• 高效的緩存管理

  服務(wù)能否支撐高并發(fā)，緩存很關(guān)鍵。緩存機(jī)制不光要設(shè)計(jì)好，還需要通過工具盡可能讓業(yè)務(wù)開發(fā)人員避免出錯(cuò)，因?yàn)榫彺娲a的編寫有相當(dāng)?shù)碾y度，goctl 很好的生成了自動(dòng)管理緩存的代碼。

• 優(yōu)雅的熔斷降載保護(hù)

  微服務(wù)系統(tǒng)一般都是由大量服務(wù)共同組合而成的，服務(wù)多了自然會(huì)有某個(gè)服務(wù)出現(xiàn)故障的風(fēng)險(xiǎn)，我們不能讓某個(gè)服務(wù)的故障導(dǎo)致整個(gè)系統(tǒng)不可用，這就是服務(wù)雪崩，要避免雪崩，我們就需要有效隔離有故障的服務(wù)，從而降級(jí)可用。熔斷和降載是防止服務(wù)雪崩的最有效手段之一。

• 彈性伸縮能力

  對(duì)于高并發(fā)的系統(tǒng)來說，突發(fā)流量洪峰的情況下，系統(tǒng)需要能夠及時(shí)水平擴(kuò)容，go-zero 的自適應(yīng)降載可以很好的配合 kubernetes 集群的自動(dòng)水平伸縮能力。

• 清晰的資源使用定義

  要想讓系統(tǒng)保持穩(wěn)定，我們一定要對(duì)資源使用做清晰的定義，比如我們到底在什么時(shí)候考慮擴(kuò)充資源，是資源占用率達(dá)到了50%還是70%，必須對(duì)系統(tǒng)資源的使用狀況有足夠清晰的定義。

• 高效的監(jiān)控報(bào)警

  我在團(tuán)隊(duì)內(nèi)部一直強(qiáng)調(diào)：沒有度量就沒有優(yōu)化。我們必須對(duì)系統(tǒng)有高效的監(jiān)控和及時(shí)的報(bào)警機(jī)制。這樣才能讓我們對(duì)整個(gè)系統(tǒng)的運(yùn)行狀態(tài)有足夠的了解。

大型微服務(wù)項(xiàng)目從何下手？

微服務(wù)系統(tǒng)大體上看起來如上圖，但是我們并不是一定要業(yè)務(wù)一開始就上微服務(wù)，我們看看一個(gè)典型的微服務(wù)系統(tǒng)是怎么進(jìn)化而來的，下面粗略的講解一下大型微服務(wù)系統(tǒng)的進(jìn)化過程。

• 從單體服務(wù)開始

  項(xiàng)目剛開始，我們不要一味的追求技術(shù)的先進(jìn)性，因?yàn)榇蟛糠猪?xiàng)目是走不到高并發(fā)的那一天的，我們需要的是第一時(shí)間滿足業(yè)務(wù)。

• 業(yè)務(wù)優(yōu)先，技術(shù)支撐

  我在團(tuán)隊(duì)里講：架構(gòu)是從業(yè)務(wù)中來，到業(yè)務(wù)中去。任何脫離了業(yè)務(wù)的技術(shù)都是自嗨，我們需要把滿足業(yè)務(wù)需要作為第一優(yōu)先級(jí)，技術(shù)需要支撐業(yè)務(wù)現(xiàn)在和可預(yù)期發(fā)展的需要即可。當(dāng)然，有滿足自身業(yè)務(wù)的現(xiàn)成的框架和最佳實(shí)踐那是最好了，但不要讓技術(shù)棧過于復(fù)雜，避免重心從業(yè)務(wù)轉(zhuǎn)移到技術(shù)本身來。

• 服務(wù)指標(biāo)監(jiān)控

  隨著業(yè)務(wù)的發(fā)展，我們可能需要對(duì)技術(shù)做一定的升級(jí)和改造了，但是我們一直強(qiáng)調(diào)：沒有度量就沒有優(yōu)化。所以我們需要及時(shí)加上對(duì)整個(gè)服務(wù)的關(guān)鍵指標(biāo)的監(jiān)控，從而讓我們?cè)诹私庀到y(tǒng)的前提下進(jìn)行必要的改造。

• 數(shù)據(jù)拆分+緩存管理

  當(dāng)業(yè)務(wù)發(fā)展到一定程度之后，基于監(jiān)控，我們發(fā)現(xiàn)服務(wù)必須要做拆分了。那么我們第一步要做的是先把數(shù)據(jù)拆分清楚，數(shù)據(jù)拆分后，我們就可以加上對(duì)應(yīng)的緩存管理，從而保障數(shù)據(jù)層面的穩(wěn)定性。

• 服務(wù)拆分

  相對(duì)于數(shù)據(jù)拆分，服務(wù)的拆分相對(duì)是比較容易的，基于拆分好的數(shù)據(jù)，對(duì)應(yīng)出上層的服務(wù)，因?yàn)榉?wù)是無狀態(tài)的，所以這個(gè)拆分就比較容易。

• 支撐系統(tǒng)建設(shè)

  隨著業(yè)務(wù)的發(fā)展，日常的系統(tǒng)維護(hù)工作就顯得比較繁瑣和容易出錯(cuò)了。此時(shí)，我們需要建設(shè)支撐系統(tǒng)，如何部署新服務(wù)，如何更新老服務(wù)，是不是要上 kubernetes，等等。

• 自動(dòng)化+工程建設(shè)

  當(dāng)業(yè)務(wù)發(fā)展到一定程度，工程效率就是一個(gè)很大的問題了。goctl 就是為了解決自動(dòng)化和工程效率問題而生，其中內(nèi)置的 api, rpc, model, Dockerfile, k8s部署文件等的自動(dòng)生成節(jié)省了我們大量時(shí)間，也避免了業(yè)務(wù)開發(fā)中的錯(cuò)誤。

go-zero 組件剖析 + go-zero 最佳實(shí)踐（待續(xù)）

如果你想要更好的了解 go-zero 項(xiàng)目，歡迎前往官方網(wǎng)站上學(xué)習(xí)具體的示例。

也可以掃碼加入微信群，我們有3000+人的活躍社區(qū)共同成長(zhǎng)！

項(xiàng)目地址

https://github.com/tal-tech/go-zero

演講PPT：