億級流量架構第二彈:你的系統真的無懈可擊嗎?【石杉的架構筆記】

石杉的架構筆記發表於2019-01-04

歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)

週一至週五早8點半!精品技術文章準時送上!


在《億級流量系統架構》系列第一階段中,我們從零開始,講述了一個大型資料平臺的幾個方面的構建,包括:


  • 如何承載百億級資料的儲存挑戰
  • 如何承載設計高容錯的分散式架構
  • 如何設計高效能架構,使之能承載百億級流量
  • 如何設計高併發架構,能夠支撐住每秒數十萬的併發查詢
  • 如何設計全鏈路99.99%的高可用架構


好!架構演進到這個時候,系統是否無懈可擊了呢?


當然不是!


自古以來,能夠瓦解一個軍隊戰鬥力的,不僅有外力衝擊,還有內部因素。

同樣,對於我們們的億級流量系統,外部的衝擊我們抗住了,現在的考驗,來自於系統自身。而首當其衝的,就是系統的可擴充套件性帶來的嚴重挑戰。。。


因此在第二階段,我們們用了大量的篇幅,分為上中下三篇,詳細的討論了該架構在可擴充套件性方面的痛點和改進。


跨過了2018年,你是否還記得這些痛點以及針對的技術方案呢?

如果忘了,沒關係,跟著本文,溫故知新。筆者希望各位在重拾記憶的同時,能有新的收穫,並且能把文中的某些技術方案在自己公司中實際落地實踐。


同樣,對於可擴充套件性方案的複習,也是為後面系統在其他方面的改進打下基礎,這樣大夥兒讀後面的文章時,不至於因為中間知識的斷層而一臉懵逼。。。


對億級流量架構可擴充套件性的討論,我們們分成了上中下三篇。其中上篇,開門見山,發現問題:實時計算平臺與資料查詢平臺之間耦合嚴重,並造成了諸多痛點:


  • 資料查詢團隊被動承擔了本不該他們承擔的高併發寫入壓力


  • 資料庫運維操作導致的線上系統效能劇烈抖動


  • 實時計算平臺團隊因為自身寫入機制的bug導致資料丟失,結果讓資料查詢團隊來進行排查,典型的甩鍋!


  • 實時計算平臺團隊,竟然需要自己來實現雙寫一致性的保障機制,直接導致程式碼裡混合了大量不屬於自己團隊業務邏輯的程式碼


  • 資料查詢平臺做了分庫分表的操作,需要實時計算平臺team一起修改配置,一起測試部署上線



總之,這些痛點,導致的結果是兩個團隊的同學天天膩在一起,而且是被迫的。。。


對於上面這些系統痛點的成因,你還有印象嗎?如果忘了,猛戳下面連結,先趕緊去複習一波吧,知道了病症,才好對症下藥!


猛戳下方連結:

億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?



好,通過了上篇文章,我們已經知道了系統耦合造成的各種痛點,真的很痛!


那麼現在,就該針對這些痛點,對症下藥。看看下面的內容,你還能記起嗎?


  • 類似於中醫的“望聞問切”,解決問題的第一步,就是找到病因。而到我們們這裡,解決耦合的第一步,則是清晰的劃分出系統邊界。


  • 劃分出邊界之後,第二件事,當然就是解耦。如何解耦:利用訊息中介軟體


  • 好!現在我們引入了訊息中介軟體解耦,你是否還記得上篇文章中的一個痛點:實時計算平臺高併發寫入時,資料查詢平臺要無辜承受高併發的寫入壓力


  • 那我們引入了中介軟體之後,通過訊息中介軟體進行削峰填谷,就能解決這個問題了,關於什麼是削峰填谷,以及如何實行,還記得嗎?


  • 解耦過後,我們通過手動流量開關來配合資料庫運維,直接自己團隊的同學在某個低鋒時段關閉流量開關,迅速完成資料庫運維操作。這不又解決了一大痛點嗎!


  • 好處還不止這些,比如,我們引入中介軟體解耦之後,其他系統不也可以按需去MQ裡,訂閱實時計算平臺計算好的資料嗎!再不用看其他平臺的臉色了



總體來講,解耦之後,各個團隊各司其職,不用天天被迫膩在一起。而沒有了人為的各種干預,系統也運轉的更加流暢高效。


關於這些針對性的解決方案,筆者建議大家再仔細看看,這都是真實線上生產總結出的經驗,也許裡面的某些方案能夠幫到你!


猛戳下方連結:

億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?



講完了實際的落地方案,我們來到了億級流量架構可擴充套件性的下篇。


在可擴充套件性中篇的討論中,我們提到了解耦的好處之一,是可以實現訊息的“Pub/Sub”模型,即不同平臺都可以根據自身需要去訂閱同一份資料。


那麼下篇,我們討論的主題就是基於訊息中介軟體的“Pub/Sub”模型,並以RabbitMQ為例,詳細闡述了其在程式碼層面的落地實踐。


什麼是exchange?預設的exchange是啥?如何繫結自己的佇列到exchange上去消費?這些還記得嗎?如果忘了,猛戳下面的連結,趕緊的回顧一下!



總體來講,解耦之後,各個團隊各司其職,不用天天被迫膩在一起。而沒有了人為的各種干預,系統也運轉的更加流暢高效。


關於這些針對性的解決方案,筆者建議大家再仔細看看,這都是真實線上生產總結出的經驗,也許裡面的某些方案能夠幫到你!


猛戳下方連結:

億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?


以上就是關於億級流量可擴充套件性做的一個階段性小結,重構之路漫無止境,且環環相扣。筆者希望通過這個總結,在我們們繼續上路之前,打牢基礎,加深理解,磨刀不誤砍柴工。




如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!


一大波微服務、分散式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼,持續關注:

億級流量架構第二彈:你的系統真的無懈可擊嗎?【石杉的架構筆記】

石杉的架構筆記(id:shishan100)

十餘年BAT架構經驗傾囊相授


推薦閱讀:

1、拜託!面試請不要再問我Spring Cloud底層原理

2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?

3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

4、微服務架構如何保障雙11狂歡下的99.99%高可用

5、兄弟,用大白話告訴你小白都能聽懂的Hadoop架構原理

6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、拜託,面試請不要再問我TCC分散式事務的實現原理坑爹呀!

9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?

10、拜託,面試請不要再問我Redis分散式鎖的實現原理!

11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?

12、億級流量系統架構之如何支撐百億級資料的儲存與計算

13、億級流量系統架構之如何設計高容錯分散式計算系統

14、億級流量系統架構之如何設計承載百億流量的高效能架構

15、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

16、億級流量系統架構之如何設計全鏈路99.99%高可用架構

17、七張圖徹底講清楚ZooKeeper分散式鎖的實現原理

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、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?

34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?

35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?



作者:石杉的架構筆記
連結:https://juejin.im/post/5c263a936fb9a049ec6b2688
來源:掘金
著作權歸作者所有,轉載請聯絡作者獲得授權!


相關文章