這是Spring Cloud實現微服務系列文章的第一篇。打算先把相關概念、文章的後續內容及文章風格等介紹一下。

Spring Cloud

標題講到兩個概念， 第一個是Spring Cloud。那就先來說下它。

Spring Cloud是一個微服務框架， 或者說是一套微服務生態。總而言之， 它為微服務的開發提供了便利。

微服務

那Spring Cloud 是用來開發微服務工程的， 那什麼叫做微服務工程?

單體工程

和微服務相對的是單體應用， 通過對比來瞭解什麼是微服務。單體應用指的是， 整個應用只有一個服務。所有的功能模組、都放在一個專案裡面。隨著功能越來越來， 問題也慢慢的暴露出來， 微服務的出現就是為瞭解決單體開發產生的一些問題。微服務把不同的功能模組拆分成不同的服務。

單體有哪些問題

微服務解決了單體開發的一些問題， 那具體是哪些問題

• 效率低

開發都在同一個專案改程式碼，相互等待，衝突不斷

• 不靈活

構建時間長，任何小修改都要重構整個專案，耗時

• 穩定性差

一個微小的問題，都可能導致整個應用掛掉

• 擴充套件性不夠

無法滿足高併發下的業務需求

• 維護難

程式碼功功能耦合在一起，新人不知道何從下手

要應用微服務開發需要解決的問題

要使用微服務開發， 需要解決以下問題， 才能應用

1. 如此多的服務， 客戶端如何訪問?

後端功能模組都已經拆分成不同的服務， 對應的ip地址和埠都可能不一致， 現在客戶端要先登入，然後下單。這時候對應後端可能就是兩個不同服務，難道要客戶端去記住這兩個不同的地址來呼叫嗎， 如果客戶端的操作涉及到十幾個不同服務呢？

2. 服務之間如何通訊

功能模組拆分成不同服務後， 服務之間還需要互相呼叫， 比如， 下單時， 我要獲取到下單的使用者資訊一起儲存。這時下單服務就要去呼叫使用者服務。這就是服務間的通訊問題。

3. 如何管理這些服務

服務這麼多， 需要對每個服務的狀態進行監控。和服務間的呼叫鏈檢視等。

4. 服務掛了怎麼辦

單體開發方式一個很大的風險是，把所有雞蛋放在一個籃子裡，一榮俱榮，一損俱損。而分散式最大的特性就是網路是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。所以當我們的系統是由一系列的服務呼叫鏈組成的時候，我們必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地快取）

微服務開發還存在哪些問題

• 程式碼重複編寫

比如shiro攔截進行登入鑑權，在每個服務中都得單獨寫一份。

• 服務呼叫鏈路長

服務之間相互呼叫， 呼叫消耗大

• 部署工作量相對大

對於運維人員來說， 部署一個微服務開發的應用了， 需要部署和維護的服務多。

• 硬體需求高

一句話，在微服務開發的方式中， 記憶體是不值錢的。

微服務相關時間點

微服務這個概念是 2012 年出現的，作為加快 Web 和移動應用程式開發程式的一種方法，2014 年開始受到各方的關注，同年為微服務的元年。

後續文章內容

微服務需要解決上述提出的問題，才能得以應用。Spring Cloud 這套生態已經給我們提供瞭解決方案。接下來就是對Spring Cloud提供的微服務核心元件進行學習。感興趣的同學可以先關注一下。

文章合集地址

釋出的文章有些多， 整理出來一份目錄大綱及文章說明。點這裡檢視