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

大家好！我是 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 語言日榜月榜頂部，如圖：