授人以漁：

能概括一下你們系統的架構設計、業務流程以及負載情況嗎？

正文開始：

(資料圖片僅供參考)

大家在看完了第一篇文章之后不知道有何感想？

相信不少朋友會覺得用這種案例代入的方式很新鮮，通過分析一個系統案例的各種技術難點，反向驅動去學習一個新技術，然后把新技術代入到系統里去解決問題。

其實我以及其他幾個朋友一直有一個共同的觀點：技術的學習，一定要放在一個真實的環境中

首先你得知道現在你的系統，或者行業里其他普遍的一些系統，都有哪些技術難點和痛點，面臨哪些問題。

接著要針對這些問題，反過來去學習一個技術，學習完這個技術之后，一定要思考如何將技術代入到真實的環境中，去解決對應的問題。

這樣學習技術，才是最高效正確的一種方法。而不是用非常傳統的方式，按照一個技術的功能點去一個功能一個功能的學習。

那樣學完了跟實戰結合不起來，其實意義也不是非常大，也許過了一段時間你就忘記了。

因此我希望大家不光是學習我們的專欄的案例展示出來的系統技術難點，以及用MQ技術如何解決這些技術難點。

大家還應該同時認真學習我們的每個“授人以漁”的環節，去仔細思考自己負責的系統是否有一些技術難點，然后去思考學習到的MQ技術如何解決你的系統中的技術難點。

我知道這時很多朋友會說：可是我自己負責的系統很low，沒什么用戶量，根本沒什么技術難點。

但是這種想法就完全錯了。舉個例子，你做一個OA系統、CRM系統、財務系統或者其他任何看起來很普通的系統，也許總共就幾十個人用。

那你能不能思考一下，假設你的這個系統是一個SaaS云平臺，要提供給幾萬個公司的百萬用戶去使用呢？

如果是這樣，那你的系統必然會有很多的技術挑戰，你可以去預估一下，當達到那個數量級之后，你的系統會有多大的數據量？多大的訪問量？然后再去思考在這么大的數據量和訪問量之下，現有的系統會有哪些技術難題？

接著你就可以思考，應該學習一些什么樣的技術來解決這些問題？

所以今天第一個“授人以漁”的環節，我們希望大家可以跟第一篇文章的思路一樣，自己梳理出來自己負責的系統的核心業務流程，核心功能模塊，跟其他系統是如何額交互的，數據是如何存儲，當前已經使用了哪些中間件技術。

你應該把自己的系統的業務流程以及技術架構都畫出來，梳理出來。

然后你可以想一下，如果你的系統的用戶量級增長百倍、千倍、甚至萬倍呢？那么此時系統每天會增長多少數據量？每秒會有多少請求量？你的系統的生產負載會是一個什么樣子？

希望大家好好的梳理這些東西，在思考的過程中如果有什么疑問，不要藏著掖著，歡迎在評論區提出來與我互動！

End

專欄版權歸公眾號儒猿技術窩所有

未經許可不得傳播，如有侵權將追究法律責任

關鍵詞：