我們在做乙個訪問量不大的專案的時候, 一台伺服器上面部署乙個應用+資料庫就夠用了…
那麼訪問量稍微大一點的話,使用者就會說卡頓,反應慢 等等各種情況,這個時候呢我們就用集群 架設nginx 部署多個服務 由nginx(負載均衡)負責把請求**到其他伺服器上,這樣就解決了使用者說的反應慢的問題…
過了一段時間之後呢 我們會發現資料庫扛不住了,然後各種優化 emmmmmm 最後發現還是很不行, 應用服務好,資料庫宕機 ,這個時候就上資料庫讀寫分離,多架設幾台資料庫伺服器,做資料庫分庫分表,然後你就會發現服務變得很流暢,資料庫也不宕機了…
又過了一段時間,公司的業務越做越大,伺服器的訪問量也變得越來越高,而且都是查詢, 吸取之前宕機的教訓而且保證資料庫的健壯性,我們會加上快取,把客戶頻繁訪問的資料存入快取裡面,這樣就會縮短查詢的時間,減少伺服器的訪問…
在後來,專案越做越大,加了很多的功能,變得很龐大 ,修改乙個類就需要全盤上傳,切換nginx重啟 發布,這樣的結果就是發布的流程越來越長,越來越頻繁,於是我們把專案拆分, 使用者資訊是乙個模組,裝置資訊是乙個模組,這樣就達到了修改使用者資訊的時候只需要修改使用者模組,修改裝置資訊的時候只修改裝置資訊的模組就好了,但是還是需要切換頂層的nginx,把要重啟的服務的流量切到可用的服務上,於是我們就想到了rpc…
那麼rpc解決了什麼呢? 所有的服務在啟動的時候註冊到乙個序號產生器裡面,然後頂層處理在接收到nginx的請求時,去序號產生器找乙個可用的服務,並呼叫介面. 這樣子呢,在不加新功能的時候,頂層處理服務我們就不需要動了? 那修改了使用者資訊專案的時候,我們只需要乙個個更新使用者資訊專案的服務群就好了…
這樣的話,無論是擴充套件還是服務的健壯性都妥妥的了…
為什麼要用分布式架構，又為什麼要用微服務？
上次面試時經常被問到乙個問題，你為什麼要用dubbo？由於經驗尚淺，實在是沒說得明明白白。我用了dubbo後，我就可以這樣調介面，巴拉巴拉，說到底還是爭不過面試官問 那照你這麼說，我不用分布式架構也可以完成啊，你只是說了用了分布式架構後業務處理的方法，並沒有弄懂裡面的原因。結果自然是。給了offer...
為什麼要微服務架構服務化？
微服務架構，這 5 年左右一直被認可，是軟體架構的未來方向。需要大家理解的是，為什麼需要服務化。比如微服務架構對企業來說，帶來什麼價值？有啥弊端？這裡 一下微服務架構，主要還是在理解 why 為什麼需要服務化？微服務架構，主要是多了個 微 亞馬遜有個粗粗的定義 乙個微服務應用工程的所有開發 測試 運...
有http了，為什麼還要用rpc？
http 和 rpc 並不是乙個並行概念。http是超文字傳輸協議，應用層網路協議。rpc不是協議，是指遠端過程呼叫，對不同應用間相互呼叫的一種描述。其呼叫協議通常包含傳輸協議和編碼協議 支援http和tcp rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少...