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段子，這對今日頭條的打擊將是巨大的。
正是因為服務治理對於突發情況的處理效果出眾，所以當一個公司產品達到一定數量級之後，服務治理一定是繞不過的一個話題。
而服務治理不僅僅在處理突發事件效果出眾，對於線上問題處理，服務監控也能發揮很大的作用。筆者之前的公司有一個完善的服務監控系統，它能統計各個接口的異常率，並且能針對每個異常請求顯示出完整的分佈式調用鏈，這對於開發人員排查線上問題非常有用。
服務監控、服務熔斷其實只是服務治理很小的一部分，本文也只是簡略地提了一下。希望這篇文章，能讓更多的技術人瞭解到熱點背後的技術，提煉出對於技術更深刻的理解。
閱讀更多 java進階架構師 的文章
