一個20年技術老兵的 2020 年度技術總結

kevinwan發表於2020-12-28

大家好！我是 go-zero 作者 Kevin。充滿驚嚇的 2020 快要過去了，看到掘金上的技術人年度徵文，忍不住文字記錄一下艱辛而又充滿收穫的 2020 ✍️

疫情開始

春節假期疫情突然升級，我們面臨著自身平臺的轉型升級。作為曉黑板CTO，有兩個重點工作：

  • 保證大規模使用場景下平臺的穩定性
  • 保證轉型所需的新業務能夠快速交付

團隊壓力巨大的同時也感受到了前所未有的戰鬥熱情，養兵千日用兵一時，不經歷戰與火的洗禮，怎麼知道團隊的技術能力是否能夠經受得住流量洪峰的考驗。

戰鬥開始，迅速落實業務團隊進行急需功能的開發，並行安排架構團隊進行技術隱患排查、演練、攻關。

在大概兩個月的時間裡，我們基本一日三餐都在電腦桌前，困了就睡覺，醒來寫程式碼（當然還有必要的開會），這真是人生一段非常難忘的特殊經歷。。。

開始踩坑

隨著所需功能的極速上線，我們馬上開始了大規模壓測，大坑如下：

  • 大量請求失敗，然而服務端壓力一切正常，一頓排查，發現原來是進到內網的請求被 nginx 轉發時又打到外網了，而外網我們是啟動了 WAF(Web Access Firewall)，WAF 會認為所有使用者都來自我們內網的那些 IP，這“明顯”是攻擊嘛，於是 drop 了大量請求，由此，我們指定了規則：進到內網的請求不允許轉發到外網。
  • 為了快速實現功能，有同學用 nodejs 實現了部分功能，部署到 k8s 叢集裡，流量一起來，nodejs pod 立馬扛不住，再加上難以控制的記憶體洩露，讓我們迅速決定不再允許使用 nodejs 做後端，使用 nodejs 純屬“意外”。
  • 某雲廠商 oss 儲存用的 LSM Tree 方式實現，在小檔案突發增加時無法及時分裂，導致我們訪問量大時出現兩次 oss 訪問故障。後來我們自己多申請了幾個 bucket 來從程式碼層分散檔案儲存請求。

實戰效果

經過前後一個月開發、壓測和開學前演練，我們的系統基本滿足開學需求了，接下來就是接受實戰檢驗了。

開學第一天，我們遇到的第一個問題部分服務供應商無法承載流量壓力，雖然我們之前盤算過，也充分交流過，但還是未能預料到洪峰流量的凶猛，服務商緊急增加資源得以解決。

然後我們訊息分類服務的 ElasticSearch 叢集壓力過大，擴容的同時，發現呼叫程式碼未加熔斷保護，直接把 ElasticSearch 叢集壓死了，裡面加上熔斷保護，幾行程式碼就好了，自適應熔斷保護工具包見 這裡。

經過第一週的密集爆發式流量的考驗，我們總體很穩定。為此還得到了有關部門的感謝信，相比友商，我們的服務穩定性還是相當不錯的。後續服務穩定性上基本可以用波瀾不驚來形容。至此，go-zero （雖然此時還不叫 go-zero）算是經受了充分的實戰檢驗 ?

走向開源

7月份在跟集團技術通道老師的交流過程中得到了充分的肯定，集團開源通道推動和幫助我把底層微服務支撐框架對外開源。

在8.7日深夜，我完成了 github 程式碼的第一次提交，此時文件僅有我臨時寫出來的一頁 readme，為啥只有一頁 readme 就選擇開源了呢？我覺得萬事開頭難，如果決定把文件都寫完再開源出來的話，可能這事就擱置了，所以還是先讓球滾起來吧！

一經開源，社群立馬給了我們比較熱烈的反饋，更推動了我們去快速完成文件。我們在一個週末就補充了大量的使用文件，提供了比較完整的示例 shorturl 和 bookstore。後面大部分開發者都通過這兩個例子感受到了 go-zero 的便捷和工程效率。感謝大家給了我們很多對示例的改進意見。

8月16日，go夜讀的分享 系統的講述了 go-zero 背後的故事和設計思考，獲得了很多觀眾的留言認可。至今依然有不少人針對這個視訊給我積極的反饋。感謝大家的認可！

8月24日，gocn 的 報導，讓 gopherchina 社群第一次大規模的瞭解了 go-zero。社群開始有大量gopher的加入，微信群人數迅速增長。

9月開始，go-zero 多次出現在 github Go 語言日榜月榜頂部，如圖：

日榜月榜
daymonth

同時不少家公司將 go-zero 用於生產，並跟我反饋上線後一直平穩執行，其中不乏日活過百萬的平臺。

10月獲得了 gitee 最有價值專案（GVP），並接著獲得了開源中國年度 最佳人氣專案獎項。

11月22日，我在 gopherchina 大會做了『雲原生go-zero微服務框架的設計思考』的主題分享，現場氣氛非常熱烈，據說門口堵滿了進不來了，獲得了很多資深開發者的認可，知乎評論見 這裡，其中提到的我的年齡不對哈?，部分現場圖如下：

分享觀眾
talkingaudience

12月20日，應邀參加騰訊雲開發者大會，做了『轉型之後 - 面對流量洪峰，微服務架構如何進行彈性設計？』的分享，如下：

開始大綱
talkingaudience

在掘金發了 20+ 篇 go-zero 系列文章，跟使用者詳細分享了微服務框架設計的原理和實現，詳見 這裡。

社群的認可

近 3000 人的微信社群，每天熱烈的技術討論和使用者之間的相互幫助，已經形成了良好的社群氛圍。我們也從中獲得很多的使用者反饋，為我們進一步加強 go-zero 指明瞭方向！?

github star 正常每月增長 1000 左右，平均每天 33+ stars，現在 4700+，增長曲線如下：

trends

再次覆盤

  1. 使用者到底想要什麼樣的框架？

    • 首先，能夠寫更少程式碼解決業務需求。更少的程式碼意味著更快的產出，更少的bug。
    • 其次，框架是否穩定，有沒經過實戰檢驗。畢竟很少人願意當小白鼠的。
    • 再次，社群是否活躍，遇到問題是否能夠快速得到解決。

  2. 使用者為什麼喜歡 go-zero?

    • 全面的微服務治理能力
    • 內建 goctl 工具幫助使用者儘可能只關注業務程式碼
    • go-zero 經過了我們線上海量併發實戰檢驗
    • 活躍的社群，使用者的互相解答，go-zero 團隊的及時跟進

2021年技術展望

  • 研發團隊工程效率帶上新臺階，期望讓大家產出更高的同時也能有更好的能力提升
  • 期望進一步加強 go-zero 的工程效率提升，讓開發者編寫更少的程式碼（業務程式碼）就能擁有穩定的微服務系統
  • 一個小目標：一年一萬星 ?

專案地址

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

歡迎大家使用 go-zero 並 star 支援我們！?

致謝

真心感謝一直支援我們的大佬們，以及眾多使用 go-zero 的 gopher 們，之所以不列名單，實在是幫助過我們的人太多了，生怕一不小心就遺漏了某位大佬 ?

專案地址：
https://github.com/tal-tech/go-zero

相關文章