服务治理·理论篇(一)
0、故事主角
呱呱樂 是一家互聯網金融公司。主營現金貸、p2p理財、消費分期業務。
公司現有技術人員800名，系統極其龐雜，每日穩定處理25w左右的訂單量，有搶購活動時，系統的QPS(Query Per Second)峰值達到了3w。
系統雖然龐雜，但在技術老大C哥的帶領下，服務的可靠性高達99.99%，技術方面的成績聞名業內。
這不，C哥受邀參加2022年全球互聯網大會了。
我是技術主編王小五，讓我們一起來采訪下C哥吧，你們有什么想問的，也可以關注我的專欄留言吆~
1、呱呱樂系統初期
小五：C哥好，很多網友對呱呱樂公司的系統演進感興趣，您能給我們講一講嗎？
C哥得意的笑了笑：好的，那我簡單介紹下吧。
呱呱樂初期其實是一個名不見經傳的小公司，只有6名技術，主要做消費分期業務，系統是基于LNMP搭建的基礎架構，框架使用的是ThinkPhp。
剛開始流量比較小，業務也比較基礎，主要提供用戶登錄注冊、訂單、賬單、支付、風控、消息發送等功能。
功能剛開始都比較簡單，所以這樣的架構能夠滿足需求，所有的功能都在一個Git工程里開發。
這些功能抽象出來，可以用一張圖表示：
小五：是的，初創型公司基本都是這樣的技術架構，簡單而實用，滿足快速迭代、功能為主的需求。
C哥：但是，隨著訪問量的增多、業務越來越復雜，這樣的架構就有點力不從心了...
2、宕機一小時
小五：哦？怎么個力不從心法？ 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，這樣都會導致服務不可用，功能之間的耦合性太高了。
3、業務的繼續開展
小五：C哥，除了消費分期業務外，咱們公司后來又開展了現金貸、理財業務。這些業務的加入，對于系統有什么影響呢？
C哥：哎，說起來都是淚啊。因為消費分期、現金貸、理財等業務，很多東西都是相同的，比如用戶功能、訂單功能、賬單功能，前期為了業務的快速發展，我們直接從消費分期拷貝了兩套代碼出來，分別用來處理現金貸、理財的業務。
小五：的確是，這樣能最快的支撐業務的運轉。
C哥：但這樣給自己埋了很大的坑，以后還得慢慢的去填~
C哥：業務中存在很多Copy-Paste的代碼，比如用戶表改動了一個字段，三個系統都需要去改。又比如加了Redis緩存，三個系統也都需要改動。實在是太繁瑣了，如果忘記改動，還有可能造成服務掛掉，那時候真實天天改bug啊。
小五：心疼你們1秒鐘。。。
4、沒完沒了的加班
C哥：隨著業務的發展，系統越來越復雜，技術人員的體會也越來越“痛”，天天改不完的bug，夜以繼日的加班...... 小五：現在的系統沒有這問題了吧，C哥？
C哥：好在我們進行了微服務的改造，這種問題才得以解決。 小五：微服務？最近很火的概念，C哥給我們分享一下吧！
C哥：今天時間也不早了，要不明天再跟大家細講吧。 小五：好的C哥，感謝您的分享，明天再來采訪您~
注：文中公司、人物均為虛構，只為故事更加精彩~
小記：服務治理還在學習階段，經驗有限，不對的地方請多多指教。
后續：服務治理理論篇(二)、實踐篇會相繼出爐~
總結
以上是生活随笔為你收集整理的服务治理·理论篇(一)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自定义ant中table表格的展开图标
- 下一篇： 已经学过51单片机，如何进阶？我来教你