go-zero解讀與最佳實踐(上)

kevwan發表於2021-02-03

本文有『Go開源說』第三期 go-zero 直播內容修改整理而成,視訊內容較長,拆分成上下篇,本文內容有所刪減和重構。

大家好,很高興來到“GO開源說” 跟大家分享開源專案背後的一些故事、設計思想以及使用方法,今天分享的專案是 go-zero,一個整合了各種工程實踐的 web 和 rpc 框架。我是Kevin,go-zero 作者,我的 github id 是 kevwan

go-zero 概覽

go-zero 雖然是20年8月7號才開源,但是已經經過線上大規模檢驗了,也是我近20年工程經驗的積累,開源後得到社群的積極反饋,在5個多月的時間裡,獲得了5.9k star。多次登頂github Go語言日榜、周榜、月榜榜首,並獲得了gitee最有價值專案(GVP),開源中國年度最佳人氣專案。同時微信社群極為活躍,3000+人的社群群,go-zero愛好者們一起交流go-zero使用心得和討論使用過程中的問題。

star

下圖中間三層是 go-zero 內建支援的服務治理相關元件,基本涵蓋了微服務治理主要的能力,而且是基本不需要開發者自己配置的,預設方案已經是經過大規模線上專案調優的。

arch

微服務系統設計中的痛點

1. 微服務系統如何拆分?

  • 先粗後細,不要過細,切忌一個介面一個服務

  • 橫向拆分,而非縱向,我們儘量不要超過三層呼叫

  • 單向呼叫,嚴禁迴圈呼叫

  • 禁止介面型別透傳,在不同的層之間不要共享同一個資料定義,避免一處修改,影響其它

  • 沒有依賴關係的序列呼叫改為並行,可以通過 core/mr 包降低響應延遲而不增加系統負載

    mr

2. 如何保障高併發高可用?

  • 良好的資料邊界

    資料邊界是微服務拆分的核心,不同的服務之間不要顯示共享資料,而應該通過 rpc 共享。

  • 高效的快取管理

    服務能否支撐高併發,快取很關鍵。快取機制不光要設計好,還需要通過工具儘可能讓業務開發人員避免出錯,因為快取程式碼的編寫有相當的難度,goctl 很好的生成了自動管理快取的程式碼。

  • 優雅的熔斷降載保護

    微服務系統一般都是由大量服務共同組合而成的,服務多了自然會有某個服務出現故障的風險,我們不能讓某個服務的故障導致整個系統不可用,這就是服務雪崩,要避免雪崩,我們就需要有效隔離有故障的服務,從而降級可用。熔斷和降載是防止服務雪崩的最有效手段之一。

  • 彈性伸縮能力

    對於高併發的系統來說,突發流量洪峰的情況下,系統需要能夠及時水平擴容,go-zero 的自適應降載可以很好的配合 kubernetes 叢集的自動水平伸縮能力。

  • 清晰的資源使用定義

    要想讓系統保持穩定,我們一定要對資源使用做清晰的定義,比如我們到底在什麼時候考慮擴充資源,是資源佔用率達到了50%還是70%,必須對系統資源的使用狀況有足夠清晰的定義。

  • 高效的監控報警

    我在團隊內部一直強調:沒有度量就沒有優化。我們必須對系統有高效的監控和及時的報警機制。這樣才能讓我們對整個系統的執行狀態有足夠的瞭解。

大型微服務專案從何下手?

overview

微服務系統大體上看起來如上圖,但是我們並不是一定要業務一開始就上微服務,我們看看一個典型的微服務系統是怎麼進化而來的,下面粗略的講解一下大型微服務系統的進化過程。

  • 從單體服務開始

    專案剛開始,我們不要一味的追求技術的先進性,因為大部分專案是走不到高併發的那一天的,我們需要的是第一時間滿足業務。

  • 業務優先,技術支撐

    我在團隊裡講:架構是從業務中來,到業務中去。任何脫離了業務的技術都是自嗨,我們需要把滿足業務需要作為第一優先順序,技術需要支撐業務現在和可預期發展的需要即可。當然,有滿足自身業務的現成的框架和最佳實踐那是最好了,但不要讓技術棧過於複雜,避免重心從業務轉移到技術本身來。

  • 服務指標監控

    隨著業務的發展,我們可能需要對技術做一定的升級和改造了,但是我們一直強調:沒有度量就沒有優化。所以我們需要及時加上對整個服務的關鍵指標的監控,從而讓我們在瞭解系統的前提下進行必要的改造。

  • 資料拆分+快取管理

    當業務發展到一定程度之後,基於監控,我們發現服務必須要做拆分了。那麼我們第一步要做的是先把資料拆分清楚,資料拆分後,我們就可以加上對應的快取管理,從而保障資料層面的穩定性。

  • 服務拆分

    相對於資料拆分,服務的拆分相對是比較容易的,基於拆分好的資料,對應出上層的服務,因為服務是無狀態的,所以這個拆分就比較容易。

  • 支撐系統建設

    隨著業務的發展,日常的系統維護工作就顯得比較繁瑣和容易出錯了。此時,我們需要建設支撐系統,如何部署新服務,如何更新老服務,是不是要上 kubernetes,等等。

  • 自動化+工程建設

    當業務發展到一定程度,工程效率就是一個很大的問題了。goctl 就是為了解決自動化和工程效率問題而生,其中內建的 api, rpc, model, Dockerfile, k8s部署檔案等的自動生成節省了我們大量時間,也避免了業務開發中的錯誤。

go-zero 元件剖析 + go-zero 最佳實踐(待續)

如果你想要更好的瞭解 go-zero 專案,歡迎前往官方網站上學習具體的示例。

視訊回放地址

https://www.bilibili.com/video/BV1Jy4y127Xu

專案地址

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

歡迎使用 go-zero 並 star 支援我們!

go-zero 系列文章見『微服務實踐』公眾號

相關文章