授人以漁：

能概括一下你們系統(tǒng)的架構(gòu)設(shè)計、業(yè)務(wù)流程以及負載情況嗎？

正文開始：

(資料圖片僅供參考)

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

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

其實我以及其他幾個朋友一直有一個共同的觀點：技術(shù)的學(xué)習(xí)，一定要放在一個真實的環(huán)境中

首先你得知道現(xiàn)在你的系統(tǒng)，或者行業(yè)里其他普遍的一些系統(tǒng)，都有哪些技術(shù)難點和痛點，面臨哪些問題。

接著要針對這些問題，反過來去學(xué)習(xí)一個技術(shù)，學(xué)習(xí)完這個技術(shù)之后，一定要思考如何將技術(shù)代入到真實的環(huán)境中，去解決對應(yīng)的問題。

這樣學(xué)習(xí)技術(shù)，才是最高效正確的一種方法。而不是用非常傳統(tǒng)的方式，按照一個技術(shù)的功能點去一個功能一個功能的學(xué)習(xí)。

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

因此我希望大家不光是學(xué)習(xí)我們的專欄的案例展示出來的系統(tǒng)技術(shù)難點，以及用MQ技術(shù)如何解決這些技術(shù)難點。

大家還應(yīng)該同時認真學(xué)習(xí)我們的每個“授人以漁”的環(huán)節(jié)，去仔細思考自己負責的系統(tǒng)是否有一些技術(shù)難點，然后去思考學(xué)習(xí)到的MQ技術(shù)如何解決你的系統(tǒng)中的技術(shù)難點。

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

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

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

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

接著你就可以思考，應(yīng)該學(xué)習(xí)一些什么樣的技術(shù)來解決這些問題？

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

你應(yīng)該把自己的系統(tǒng)的業(yè)務(wù)流程以及技術(shù)架構(gòu)都畫出來，梳理出來。

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

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

End

專欄版權(quán)歸公眾號儒猿技術(shù)窩所有

未經(jīng)許可不得傳播，如有侵權(quán)將追究法律責任

關(guān)鍵詞：