歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)
週一至週五早8點半!精品技術文章準時送上!
在《億級流量系統架構》系列第一階段中,我們從零開始,講述了一個大型資料平臺的幾個方面的構建,包括:
- 如何承載百億級資料的儲存挑戰
- 如何承載設計高容錯的分散式架構
- 如何設計高效能架構,使之能承載百億級流量
- 如何設計高併發架構,能夠支撐住每秒數十萬的併發查詢
- 如何設計全鏈路99.99%的高可用架構
好!架構演進到這個時候,系統是否無懈可擊了呢?
當然不是!
自古以來,能夠瓦解一個軍隊戰鬥力的,不僅有外力衝擊,還有內部因素。
同樣,對於我們們的億級流量系統,外部的衝擊我們抗住了,現在的考驗,來自於系統自身。而首當其衝的,就是系統的可擴充套件性帶來的嚴重挑戰。。。
因此在第二階段,我們們用了大量的篇幅,分為上中下三篇,詳細的討論了該架構在可擴充套件性方面的痛點和改進。
跨過了2018年,你是否還記得這些痛點以及針對的技術方案呢?
如果忘了,沒關係,跟著本文,溫故知新。筆者希望各位在重拾記憶的同時,能有新的收穫,並且能把文中的某些技術方案在自己公司中實際落地實踐。
同樣,對於可擴充套件性方案的複習,也是為後面系統在其他方面的改進打下基礎,這樣大夥兒讀後面的文章時,不至於因為中間知識的斷層而一臉懵逼。。。
一
對億級流量架構可擴充套件性的討論,我們們分成了上中下三篇。其中上篇,開門見山,發現問題:實時計算平臺與資料查詢平臺之間耦合嚴重,並造成了諸多痛點:
- 資料查詢團隊被動承擔了本不該他們承擔的高併發寫入壓力
- 資料庫運維操作導致的線上系統效能劇烈抖動
- 實時計算平臺團隊因為自身寫入機制的bug導致資料丟失,結果讓資料查詢團隊來進行排查,典型的甩鍋!
- 實時計算平臺團隊,竟然需要自己來實現雙寫一致性的保障機制,直接導致程式碼裡混合了大量不屬於自己團隊業務邏輯的程式碼
- 資料查詢平臺做了分庫分表的操作,需要實時計算平臺team一起修改配置,一起測試部署上線
總之,這些痛點,導致的結果是兩個團隊的同學天天膩在一起,而且是被迫的。。。
對於上面這些系統痛點的成因,你還有印象嗎?如果忘了,猛戳下面連結,先趕緊去複習一波吧,知道了病症,才好對症下藥!
猛戳下方連結:
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?
二
好,通過了上篇文章,我們已經知道了系統耦合造成的各種痛點,真的很痛!
那麼現在,就該針對這些痛點,對症下藥。看看下面的內容,你還能記起嗎?
- 類似於中醫的“望聞問切”,解決問題的第一步,就是找到病因。而到我們們這裡,解決耦合的第一步,則是清晰的劃分出系統邊界。
- 劃分出邊界之後,第二件事,當然就是解耦。如何解耦:利用訊息中介軟體
- 好!現在我們引入了訊息中介軟體解耦,你是否還記得上篇文章中的一個痛點:實時計算平臺高併發寫入時,資料查詢平臺要無辜承受高併發的寫入壓力
- 那我們引入了中介軟體之後,通過訊息中介軟體進行削峰填谷,就能解決這個問題了,關於什麼是削峰填谷,以及如何實行,還記得嗎?
- 解耦過後,我們通過手動流量開關來配合資料庫運維,直接自己團隊的同學在某個低鋒時段關閉流量開關,迅速完成資料庫運維操作。這不又解決了一大痛點嗎!
- 好處還不止這些,比如,我們引入中介軟體解耦之後,其他系統不也可以按需去MQ裡,訂閱實時計算平臺計算好的資料嗎!再不用看其他平臺的臉色了
總體來講,解耦之後,各個團隊各司其職,不用天天被迫膩在一起。而沒有了人為的各種干預,系統也運轉的更加流暢高效。
關於這些針對性的解決方案,筆者建議大家再仔細看看,這都是真實線上生產總結出的經驗,也許裡面的某些方案能夠幫到你!
猛戳下方連結:
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?
三
講完了實際的落地方案,我們來到了億級流量架構可擴充套件性的下篇。
在可擴充套件性中篇的討論中,我們提到了解耦的好處之一,是可以實現訊息的“Pub/Sub”模型,即不同平臺都可以根據自身需要去訂閱同一份資料。
那麼下篇,我們討論的主題就是基於訊息中介軟體的“Pub/Sub”模型,並以RabbitMQ為例,詳細闡述了其在程式碼層面的落地實踐。
什麼是exchange?預設的exchange是啥?如何繫結自己的佇列到exchange上去消費?這些還記得嗎?如果忘了,猛戳下面的連結,趕緊的回顧一下!
總體來講,解耦之後,各個團隊各司其職,不用天天被迫膩在一起。而沒有了人為的各種干預,系統也運轉的更加流暢高效。
關於這些針對性的解決方案,筆者建議大家再仔細看看,這都是真實線上生產總結出的經驗,也許裡面的某些方案能夠幫到你!
猛戳下方連結:
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?
以上就是關於億級流量可擴充套件性做的一個階段性小結,重構之路漫無止境,且環環相扣。筆者希望通過這個總結,在我們們繼續上路之前,打牢基礎,加深理解,磨刀不誤砍柴工。
如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼,持續關注:
石杉的架構筆記(id:shishan100)
十餘年BAT架構經驗傾囊相授
推薦閱讀:2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託,面試請不要再問我TCC分散式事務的實現原理坑爹呀!
9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?
11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼?
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能?
20、大白話聊聊Java併發面試問題之談談你對AQS的理解?
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥?
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的?(上篇)
24、網際網路公司面試官是如何360°無死角考察候選人的?(下篇)
25、Java進階面試系列之一:哥們,你們的系統架構中為什麼要引入訊息中介軟體?
26、【Java進階面試系列之二】:哥們,那你說說系統架構引入訊息中介軟體有什麼缺點?
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們,訊息中介軟體在你們專案裡是如何落地的?
29、【Java進階面試系列之四】扎心!線上服務當機時,如何保證資料100%不丟失?
30、一次JVM FullGC的背後,竟隱藏著驚心動魄的線上生產事故!
31、【高併發優化實踐】10倍請求壓力來襲,你的系統會被擊垮嗎?
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰,如何保證百萬生產資料不丟失?
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?
作者:石杉的架構筆記
連結:https://juejin.im/post/5c263a936fb9a049ec6b2688
來源:掘金
著作權歸作者所有,轉載請聯絡作者獲得授權!