服務治理·理論篇(一)

0、故事主角

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

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

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

這不，C哥受邀參加2022年全球互聯網大會了。

我是技術主編王小五，讓咱們一塊兒來採訪下C哥吧，大家有什麼想問的，也能夠關注個人專欄留言吆~

一、呱呱樂系統初期

小五：C哥好，不少網友對呱呱樂公司的系統演進感興趣，您能給咱們講一講嗎？

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

呱呱樂初期實際上是一個名不見經傳的小公司，只有6名技術，主要作消費分期業務，系統是基於LNMP搭建的基礎架構，框架使用的是ThinkPhp。

剛開始流量比較小，業務也比較基礎，主要提供用戶登陸註冊、訂單、帳單、支付、風控、消息發送等功能。

功能剛開始都比較簡單，因此這樣的架構可以知足需求，全部的功能都在一個Git工程裏開發。

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

---

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

C哥：可是，隨着訪問量的增多、業務愈來愈複雜，這樣的架構就有點力不從心了...

---

二、宕機一小時

---

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

---

小五：哈哈，那C哥給咱們講講吧，你們都很想聽。

C哥：當咱們業務開展到了6個月左右的時候，註冊用戶比較多了。 一天下午，大量用戶反饋咱們的app打不開了，同時咱們也發現了這個問題。

因而咱們從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哥給咱們分享一下吧！

C哥：今天時間也不早了，要不明天再跟你們細講吧。 小五：好的C哥，感謝您的分享，明天再來採訪您~

---

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

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

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

---