宣告：
本系列 【技術日誌】 為記錄博主（我）學習微服務架構總結的一些內容，部分來自學習&參考書籍，本宣告僅在第一章有，此後不再出現，參考書籍為: 《架構探險 輕量級微服務架構》。 最後，讓我們一起來愉快地學習微服務架構吧！
是啊，為什麼呢？ 其實是因為傳統架構的一些問題， 比如：
有一個
WEBAPP，裡面有WEBUI部分以及若干業務模組，比如Module A、Module B、Module C等，這幾個業務模組佔用系統資源都不同，（以下進行簡稱，MA=Module A,MB,MC同理）。
MA佔用資源為10%,MB佔用資源為10%,MC佔用資源為80%。那麼，這樣執行一段時間，佔用資源最大的MC就會成為系統的瓶頸，怎麼辦呢？
聰明的人們想出一個簡單地辦法, 就是對應用程式進行水平擴充(即增加計算機的數量提升效能),同時在兩臺伺服器上方架設一臺Load Balancer(負載均衡器,簡稱LB)。
請求首先會傳送到LB上，通過LB上的路由演算法(例如輪詢或雜湊)，將請求轉發到後面具體的Web Server上，這類請求轉發技術被稱為Reverse Proxy(反向代理)。
由於進入LB的流量被均衡到下方各臺Web Server中了，流量得到了分攤，負載得到了均衡，因此這項技術也被稱為Load Balance(負載均衡)
如果流量加大，我們還可以繼續水平擴充，改架構理論上可以無限擴充， 只要LB扛得住巨大的流量就OK。
通過以上方案，輕鬆地將負載進行了均衡，在一定程度上緩解了流量對Web Server的壓力，但此時卻造成了大量的系統資源浪費，比如對系統資源佔用率不高的MA與MB也進行了水平擴充，其實我們只想對MC進行水平擴充而已。
傳統應用架構實際上是一個單塊應用，我們在部署它的時候，同樣會遇到許多麻煩，比如：
- 修改了一個 Module(可能只是修改了一行程式碼)，就需要部署整個應用
- 部署整個應用所消耗的時間對系統帶來的效能開銷都是非常多的
而且對於Java Web應用而言，打包在war包裡的程式碼一般都是class檔案，這也就意味著，我們的單塊應用只是基於Java語言開發的，無法將該應用中某個Module通過其他更合適的開發語言來實現(假如我們不考慮在JVM上執行動態語言的情況下)，這樣就會產生技術選型單一的問題。
綜上所述，傳統應用架構存在以下問題：
- 系統資源浪費
- 部署效率太低
- 技術選型單一
當然，傳統應用架構的問題還遠遠不止這些。當業務變的越來越複雜時，應用會變得越來越臃腫，“身材”越來越“胖”，而且無法瘦身。於是，人們找到了新的思路來解決傳統應用架構的問題，這就是微服務架構
本作品採用《CC 協議》，轉載必須註明作者和本文連結