服務治理理論篇一

呱呱樂是一家網際網路金融公司。主營現金貸、p2p理財、消費分期業務。

公司現有技術人員800名，系統極其龐雜，每日穩定處理25w左右的訂單量，有搶購活動時，系統的qps(query per second)峰值達到了3w。

系統雖然龐雜，但在技術老大c哥的帶領下，服務的可靠性高達99.99%，技術方面的成績聞名業內。

這不，c哥受邀參加2023年全球網際網路大會了。

小五：c哥好，很多網友對呱呱樂公司的系統演進感興趣，您能給我們講一講嗎？

c哥得意的笑了笑：好的，那我簡單介紹下吧。

呱呱樂初期其實是乙個名不見經傳的小公司，只有6名技術，主要做消費分期業務，系統是基於lnmp搭建的基礎架構，框架使用的是thinkphp。

剛開始流量比較小，業務也比較基礎，主要提供使用者登入註冊、訂單、賬單、支付、風控、訊息傳送等功能。

功能剛開始都比較簡單，所以這樣的架構能夠滿足需求，所有的功能都在乙個git工程裡開發。

這些功能抽象出來，可以用一張圖表示：

小五：是的，初創型公司基本都是這樣的技術架構，簡單而實用，滿足快速迭代、功能為主的需求。

c哥：但是，隨著訪問量的增多、業務越來越複雜，這樣的架構就有點力不從心了...

小五：哦？怎麼個力不從心法？ c哥微笑一下：宕機的時候，你就知道了，哈哈。

於是我們從nginx開始排查，發現流量正常，沒有被ddos攻擊，nginx配置也正常，沒有任何問題。

接下來，我們又排查了php，php程序也一切正常，沒有出現記憶體洩漏等問題。

剩下的，就排查mysql了，一看不要緊，原來真是 mysql 在搞鬼，cpu使用率近乎100%...

於是，我們趕緊暫停了mysql服務。

通過查詢慢sql日誌發現，原來是張二胖寫的一條sql導致了風控日誌表進行了全表掃瞄，而風控日誌表中的資料高達800萬條...

小五：哈哈，這樣的場景似曾相識，好多公司應該都經歷過。 c哥：是啊，好多攻城獅都對資料庫進行直接操作，而他們寫出的sql的質量又不能保證。

小五：那你們最終怎麼解決的呢？ c哥：首先我們對服務進行了降級，先保證核心功能可用。而後，我們又對該資料表加索引，對sql進行優化，最終解決了這個問題。

c哥：從發現問題到解決問題，大約用了乙個小時的時間，這一小時內，所有服務都不能用了，真是驚心動魄的一小時。從這時起，我就想有什麼辦法能夠規避這類問題。小五：是啊，這次可能是張二胖寫出了全表掃瞄的sql，下次可能是張三胖寫出全表掃瞄的sql，這樣都會導致服務不可用，功能之間的耦合性太高了。

小五：c哥，除了消費分期業務外，咱們公司後來又開展了現金貸、理財業務。這些業務的加入，對於系統有什麼影響呢？

c哥：哎，說起來都是淚啊。因為消費分期、現金貸、理財等業務，很多東西都是相同的，比如使用者功能、訂單功能、賬單功能，前期為了業務的快速發展，我們直接從消費分期拷貝了兩套**出來，分別用來處理現金貸、理財的業務。

小五：的確是，這樣能最快的支撐業務的運轉。

c哥：但這樣給自己埋了很大的坑，以後還得慢慢的去填~

c哥：業務中存在很多copy-paste的**，比如使用者表改動了乙個字段，三個系統都需要去改。又比如加了redis快取，三個系統也都需要改動。實在是太繁瑣了，如果忘記改動，還有可能造成服務掛掉，那時候真實天天改bug啊。

小五：心疼你們1秒鐘。。。

c哥：隨著業務的發展，系統越來越複雜，技術人員的體會也越來越「痛」，天天改不完的bug，夜以繼日的加班...... 小五：現在的系統沒有這問題了吧，c哥？

c哥：好在我們進行了微服務的改造，這種問題才得以解決。小五：微服務？最近很火的概念，c哥給我們分享一下吧！

注：文中公司、人物均為虛構，只為故事更加精彩~

小記：服務治理還在學習階段，經驗有限，不對的地方請多多指教。

後續：服務治理理論篇(二)、實踐篇會相繼出爐~

服務治理 理論篇 一