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哥,感謝您的分享,明天再來采訪您~
注:文中公司、人物均為虛構,只為故事更加精彩~
小記:服務治理還在學習階段,經驗有限,不對的地方請多多指教。
后續:服務治理理論篇(二)、實踐篇會相繼出爐~