大家好！我是 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 叢集壓死了，裡面加上熔斷保護，幾行程式碼就好了，自適應熔斷保護工具包見 **[這裡](https://github.com/tal-tech/go-zero/blob/master/core/breaker/breakers.go)**。 經過第一週的密集爆發式流量的考驗，我們總體很穩定。為此還得到了有關部門的感謝信，相比友商，我們的服務穩定性還是相當不錯的。後續服務穩定性上基本可以用波瀾不驚來形容。至此，[go-zero](https://github.com/tal-tech/go-zero) （雖然此時還不叫 go-zero）算是經受了充分的實戰檢驗