前言

為什麼要有微服務呢？

什麼是微服務？

SpringCloud 中為什麼會有那麼多的元件？

……

作為SpringCloud教程的第一篇，不講解具體的技術使用，透過一個通俗易懂的小故事，來解決這些疑惑。

本文分為三個部分：

架構的演變，即為什麼會出現微服務技術

什麼是微服務，即微服務的標準概念

微服務要解決什麼問題，即微服務中那麼多的元件都是幹嘛的

從單體到微服務「小故事講解架構演變」

新技術會站在老技術的基礎上，解決老技術出現的問題的同時，進行迭代和演化

這年，可能是十年前也可能是十五年前，小鹿入職了一家處於萌芽期的電商公司—並夕夕商城。

這個時候公司初創，人少，事兒少，使用者少，當然了老闆的錢也少，本著多快好省的信念，作為公司唯一開發工程師小鹿，跌跌撞撞的開發了一款能用的商城網站，架構如下：

網站整體非常的簡單，在沒什麼使用者的現階段也是非常的好用，而且還非常的省心，但是沒有想到的是，公司業務越來越好，使用者量是越來越大，隨著訪問量的不斷增大，專案經常卡死故障。

於是老闆大手一揮，指引商城技術改革，emmm，還加錢招人，又招了小羊，小馬數位同事，對並夕夕商城進行升級最佳化。

經過激烈的討論，最佳化方向為：增加應用負載能力，即負載均衡，應用伺服器叢集

於是，噔噔蹬蹬，新的架構出現了

負載均衡

增加負載均衡之後，應用伺服器不再是系統的瓶頸了，可以靈活的隨著訪問量增大的同時增加應用伺服器叢集的數量。

但是，時間長了，資料庫出問題了，由於資料量的不斷增加，再加上促銷，日誌等新業務模組的出現，資料庫存取出現了問題，

一個數據庫能夠承受的人生壓力畢竟是有限的。

於是老闆大手一揮，指引商城技術改革，emmm，又加錢招人，又招了小牛，小明等數位同事，對並夕夕商城進行升級最佳化。

經過激烈的討論，最佳化方向為：資料庫讀寫分離

於是，噔噔蹬蹬，新的架構出現了

讀寫分離

透過將資料庫進行叢集，讀寫分離，讓資料庫能夠承受的壓力得到大幅提升，但是隨著對業務的進一步深根細作，新的問題暴露了。

新增加的商品搜尋功能，使用資料庫的模糊查詢，效率低下，且查詢結果不準確

不同模組的資料訪問熱度不一樣，有部分資料，例如首頁資料，需要頻繁的進行查詢展示，每次都查詢資料庫效率太低 ……

於是老闆大手一揮，指引商城技術改革，emmm，又加錢招人，又招了數位同事，對並夕夕商城進行升級最佳化。

經過激烈的討論，最佳化方向為：引入全文搜尋，Redis等技術。

於是，噔噔蹬蹬，新的架構出現了

ES+Redis叢集

新的架構一切看上去都是這麼完美的亞子，團隊眾人終於可以過個好年了。

歲月靜好。

隨著並夕夕商城不斷壯大，公司迎來了風投，風投兩個億，於是商城發展的更快了，新的問題出現了。

什麼問題呢？

不同的業務模組之間程式碼耦合度太高，一個模組出問題，整個專案宕機

維護困難，每次程式碼更新都要對所有的伺服器進行重新的部署

有些業務模組的使用者訪問量實在太小，沒有必要部署在多臺伺服器上 ……

於是老闆大手一揮，指引商城技術改革，emmm，有錢了就要做一些符合土豪身份的枯燥事情，大手一揮，揮金如土直接買了一個大牛團隊來對商城進行技術最佳化。

最佳化方向：服務化。

服務化

所謂服務化，就是將公司的專案按照模組來進行分割，把每個模組都做成一個可以獨立執行，單獨部署的的應用程式，如圖所示：

訂單，商品，首頁，促銷等，每一個業務模組都是一個獨立的應用程式，我們把這樣按照模組劃分的應用程式稱之為服務。

可以根據需要獨立的部署在伺服器上，首頁模組被訪問的比較多，就可以多部署幾個

可以獨立的訪問資料庫，每個服務都可以有自己的資料庫 ……

等等等，好處不要太多。這樣情況我們實際上也稱之為

微服務

。

服務化要解決的問題？「更多問題到來」

當專案進行服務化改造的時候，這個過程並不是一蹴而就，一拍腦袋就成功了。要把專案服務化，需要解決很多的問題，例如：

服務之間怎麼呼叫？

訂單服務想要呼叫到商品服務的資料，怎麼呼叫？怎麼呼叫更加的穩定，更加高效？【服務呼叫技術】

服務之間怎麼負載均衡？

訂單服務要呼叫商品服務，商品服務可能有很多個，怎麼負載均衡【負載均衡技術】

服務怎麼被管理？

服務怎麼定位？有故障了怎麼處理？【服務註冊與發現技術】

故障怎麼監控

？微服務系統中業務模組很多，元件也很多，不同元件的指標不同，那麼這些元件怎麼進行監控【監控技術】

故障怎麼定位？

微服務架構中，一個使用者的請求會涉及到多個內部服務的呼叫，那麼如何定位問題呢？【鏈路追蹤技術】

日誌怎麼分析處理？

業務模組多了，日誌也就多了，直接檢視日誌檔案已經變的不顯示了，那麼如何對日誌進行分析查詢呢？【日誌分析技術】

許可權管理？

微服務拆分服務之後，會有很多服務對外暴露介面，這些介面如何進行統一的許可權處理呢？【閘道器技術】

服務調用出現問題怎麼處理？

當一個服務因為各種原因停止響應時，呼叫方通常會等待一段時間，然後超時或者收到錯誤返回。如果呼叫鏈路比較長，可能會導致請求堆積，整條鏈路佔用大量資源一直在等待下游響應。怎麼解決呢？【熔斷，降級，限流】

還有測試，自動化部署等等問題，都隨著微服務的出現到來了，

上面的每個問題要進行解決都需要在專案中引入一個或者多個新技術，而這些新技術我們一般稱之為元件，也是微服務學習的重點，一整套技術，一套解決上述所有問題的解決方案。

上面出現的問題，在此處我們暫時一筆帶過，在所有的教程中，再進行詳細的分析和講解。

什麼是微服務【重點】

the microservice architectural style ［1］ is an approach to developing a single application as a suite of small services， each running in its own process and communicating with lightweight mechanisms， often an HTTP resource API。 These services are built around business capabilities and independently deployable by fully automated deployment machinery。 There is a bare minimum of centralized management of these services， which may be written in different programming languages and use different data storage technologies。

每個服務可獨立執行在自己的程序裡

一系列獨立執行的微服務共同構建起整個系統

每個服務為獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理，使用者管理

微服務之間透過一些輕量的通訊機制進行通訊，例如Restful API進行呼叫

可以使用不同的程式語言與資料儲存技術開發

官網連結

：https：//www。martinfowler。com/articles/microservices。html

總結

新技術會站在老技術的基礎上，解決老技術出現的問題的同時，進行迭代和演化。

微服務技術是一整套技術，是一套解決多個問題的技術解決方案。

恭喜你完成了本章的學習，為你鼓掌！如果本文對你有幫助，請幫忙點贊，評論，轉發，這對作者很重要，謝謝。

要掌握SpringCloud更多的用法，請持續關注本系列教程。

求關注，求點贊，求轉發