知識星球4月10日，某日頭條下的低俗試聽產品「XX段子」被勒令永久關停。
該訊息傳出後，該APP大量使用者湧入抖音，以統一頭像以及統一的評論迅速佔領抖音熱門影片評論區。
而就在該某段子APP被封當晚 23 點 40 左右，抖音關閉了評論的所有功能。雖然頁面顯示有幾千條評論，但是當點開評論的時候卻發現沒有評論內容。
次日抖音釋出官方宣告，表示伺服器維護停止直播和評論功能，等待升級完成之後再重新開放。某條官方公眾號也發表了一篇致歉信，表示要將正確的價值觀融入技術和產品，並要整改社群秩序，最佳化社群氛圍。
作為技術人員，我不禁在想：從使用者刷屏到最後關閉整個評論功能，今日頭條在技術上如何能夠如此快速地關閉所有評論功能？
我們可以猜想，以抖音這種數量級的使用者，抖音後臺早已實現了各個功能模組的服務化拆分，並且進行了服務治理。而從今日頭條對外的技術分享來看，今日頭條確實是這麼做的。
我們使用 Go 語言研發了內部的微服務框架 kite，協議上完全相容 Thrift。以五元組為基礎單元，我們在 kite 框架上集成了服務註冊和發現，分散式負載均衡，超時和熔斷管理，服務降級，Method 級別的指標監控，分散式呼叫鏈追蹤等功能。目前統一使用 kite 框架開發內部 Go 語言的服務，整體架構支援無限制水平擴充套件。
從上面的技術分享片段，我們可以知道今日頭條內部使用了 Go 語言開發的 Kite 微服務框架，並且實現了服務監控、服務熔斷、服務降級、服務指標監控等功能。
所以我們可以猜想：當 4 月 10 日，廣電總局宣佈勒令關閉XX段子，大量使用者湧入抖音評論區的時候，抖音評論介面呼叫數暴增，相應的服務監控報警，相關的技術人員收到資訊進行緊急處理。此時技術人員便會排查評論介面呼叫暴增的原因，並且商量對應的對策。
到了 4 月 10 日 23 點 40 分左右，或許因為擔心事態進一步發酵，所以抖音選擇將評論介面進行服務熔斷。所有請求評論串列的請求，全部傳回空的評論資料。
其實所謂的「服務熔斷」指的就是當某個指標達到一定程度時，服務介面自動熔斷，對所有請求該介面的消費者都傳回一個預設值。例如抖音一定時間內評論介面呼叫數達到100萬次，自動傳回空的評論資料。當然了，服務熔斷也可以手動觸發。
現在回頭想一想，抖音之所以能快速地處理好這件事情，很大一部分是服務治理的功勞。試想一下，如果沒有服務監控，那麼技術人員就無法第一時間獲取異常資訊。那使用者就會在抖音評論區一直刷屏，這時時態很可能得不到平息，反而會越演越烈，抖音很可能會成為下一個XX段子，這對今日頭條的打擊將是巨大的。
正是因為服務治理對於突發情況的處理效果出眾，所以當一個公司產品達到一定數量級之後，服務治理一定是繞不過的一個話題。
而服務治理不僅僅在處理突發事件效果出眾，對於線上問題處理，服務監控也能發揮很大的作用。筆者之前的公司有一個完善的服務監控系統，它能統計各個介面的異常率，並且能針對每個異常請求顯示出完整的分散式呼叫鏈，這對於開發人員排查線上問題非常有用。
服務監控、服務熔斷其實只是服務治理很小的一部分，本文也只是簡略地提了一下。希望這篇文章，能讓更多的技術人瞭解到熱點背後的技術，提煉出對於技術更深刻的理解。
歡迎加入我的知識星球，一起交流、探討原始碼：
