大家好！我是 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 來從程式碼層分散檔案儲存請求。實戰效果

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

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

走向開源

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

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

分享	觀眾

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

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