這可能是你看過最好的微服務架構詳解文章

本文將介紹微服務架構和相關的元件，介紹他們是什麼以及為什麼要使用微服務架構和這些元件。本文著重於簡潔地表達微服務架構的全局圖景，因此不會涉及具體如何使用元件等細節。

要理解微服務，首先要先理解不是微服務的那些。通常跟微服務相對的是單體應用，即將所有功能都打包成在一個獨立單元的應用程式。從單體應用到微服務並不是一蹴可幾的，這是一個逐漸演變的過程。本文將以一個網路超市應用為例來說明這個過程。

最初的需求

幾年前，小明和小皮一起創業做網路超市。小明負責程式開發，小皮負責其他事宜。當時網路還不發達，網路超市還是藍海。只要功能實現了就能隨便賺錢。所以他們的需求很簡單，只需要一個網站掛在公網，使用者能夠在這個網站上瀏覽商品、購買商品；另外還需一個管理後台，可以管理商品、使用者、以及訂單資料。

我們整理一下功能清單：

• 網站
• #使用者註冊、登入功能
• ##商品展示
• 下單
管理後台

###使用者管理############商品管理#############訂單管理###############由於需求簡單，小明左手右手一個慢動作，網站就完成了。管理後台出於安全考慮，不和網站做在一起，小明右手左手慢動作重播，管理網站也做好了。總體架構圖如下：###

小明揮一揮手，找了家雲服務部署上去，網站就上線了。上線後好評如潮，深受各類肥宅喜愛。小明小皮美滋滋地開始躺著收錢。

隨著業務發展……

好景不長，沒過幾天，各類網上超市緊跟著拔地而起，對小明小皮造成了強烈的衝擊。

在競爭的壓力下，小明小皮決定進行一些行銷手段：

• 進行促銷活動。例如元旦全場打折，春節買二送一，情人節狗糧優惠券等等。
• 拓展管道，新增行動端行銷。除了網站外，還需要開發行動端APP，微信小程式等。
• 精準行銷。利用歷史資料對使用者進行分析，提供個人化服務。
• ……

這些活動都需要程式開發的支援。小明拉了同學小紅加入團隊。小紅負責數據分析以及行動端相關開發。小明負責促銷活動相關功能的開發。

因為開發任務比較緊迫，小明小紅沒有好好規劃整個系統的架構，隨便拍了拍腦袋，決定把促銷管理和數據分析放在管理後台裡，微信和行動端APP另外搭建。通宵了幾天后，新功能和新應用基本上完成。這時架構圖如下：

這階段存在著許多不合理的地方：

• 網站和行動裝置應用程式有很多相同業務邏輯的重複程式碼。
• 資料有時候透過資料庫共享，有時候透過介面呼叫傳輸。介面呼叫關係雜亂。
• 單一應用程式為了給其他應用程式提供接口，漸漸地越改越大，包含了很多本來就不屬於它的邏輯。應用邊界模糊，功能歸屬混亂。
• 管理後台在一開始的設計中保障等級較低。加入數據分析和促銷管理相關功能後出現效能瓶頸，影響了其他應用。
• 資料庫表結構被多個應用程式依賴，無法重構和最佳化。
• 所有應用程式都在一個資料庫上操作，資料庫出現效能瓶頸。特別是數據分析跑起來的時候，資料庫效能急劇下降。
• 開發、測試、部署、維護愈發困難。即使只改動一個小功能，也需要整個應用程式一起發布。有時候發表會不小心帶了一些未經測試的程式碼，或是修改了一個功能後，另一個意想不到的地方出錯了。為了減輕發布可能產生的問題的影響和線上業務停頓的影響，所有應用程式都要在凌晨三到四點執行發布。發布後為了驗證應用程式正常運行，還得盯到第二天白天的用戶高峰期…
• #團隊出現推諉扯皮現象。關於一些公用的功能應該建設在哪個應用上的問題常常要爭論很久，最後要么乾脆各做各的，或者隨便放個地方但是都不維護。

儘管有著諸多問題，但也不能否認這一階段的成果：快速地根據業務變化建設了系統。不過緊迫且繁重的任務容易使人陷入局部、短淺的思維方式，從而做出妥協式的決策。在這種架構中，每個人都只專注在自己的一畝三分地，缺乏全局的、長遠的設計。長此以往，系統建置將會越來越困難，甚至陷入不斷推翻、重建的循環。

是時候做出改變了

幸好小明和小紅是有追求有理想的好青年。意識到問題後，小明和小紅從瑣碎的業務需求中騰出了一部分精力，開始梳理整體架構，針對問題準備著手改造。

要做改造，首先你需要有足夠的精力和資源。如果你的需求方（業務人員、專案經理、上司等）很強勢地一心追求需求進度，以致於你無法挪出額外的精力和資源的話，那麼你可能無法做任何事…

在程式設計的世界中，最重要的便是抽象能力。微服務改造的過程其實也是個抽象的過程。小明與小紅整理了網路超市的業務邏輯，抽像出公用的業務能力，做成幾個公共服務：

• 用戶服務
• 商品服務
• 促銷服務
• 訂單服務
• 資料分析服務

各個應用程式後台只需從這些服務獲取所需的數據，從而刪除了大量冗餘的程式碼，就剩個輕薄的控制層和前端。這階段的架構如下：

這個階段只是將服務分開了，資料庫依然是共用的，所以有些煙囪式系統的缺點仍然存在：

1. 資料庫成為效能瓶頸，並且有單點故障的風險。
2. 資料管理趨向混亂。即使一開始有良好的模組化設計，隨著時間推移，總會有一個服務直接從資料庫取另一個服務的資料的現象。
3. 資料庫表結構可能被多個服務依賴，牽一發而動全身，很難調整。

如果一直保持共用資料庫的模式，則整個架構會越來越僵化，失去了微服務架構的意義。因此小明和小紅一鼓作氣，把資料庫也拆分了。所有持久化層相互隔離，由各個服務自行負責。另外，為了提高系統的即時性，加入了訊息佇列機制。架構如下：

完全拆分後各個服務可以採用異質的技術。例如資料分析服務可以使用資料倉儲作為持久化層，以便於有效率地做一些統計計算；商品服務和促銷服務存取頻率比較大，因此加入了快取機制等。

還有一種抽像出公共邏輯的方法就是把這些公共邏輯做成公共的框架庫。這種方法可以減少服務呼叫的效能損耗。但是這種方法的管理成本非常高昂，很難保證所有應用程式版本的一致性。

資料庫拆分也有一些問題和挑戰：比如說跨庫級聯的需求，透過服務查詢資料顆粒度的粗細問題等。但是這些問題可以透過合理的設計來解決。整體來說，資料庫拆分是一個利大於弊的。

微服務架構還有一個技術外的好處，它使整個系統的分工更加明確，責任更加清晰，每個人專心負責為其他人提供更好的服務。在單體應用的時代，公共的業務功能經常沒有明確的歸屬。最後要麼各做各的，每個人都重新實現了一遍；要么是隨機一個人（一般是能力比較強或者比較熱心的人）做到他負責的應用裡面。在後者的情況下，這個人在負責自己應用之外，還要額外負責給別人提供這些公共的功能——而這個功能本來是無人負責的，僅僅因為他能力較強/比較熱心，就莫名地背鍋（這種情況仍被美其名曰能者多勞）。結果最後大家都不願意提供公共的功能。長此以往，團隊裡的人漸漸變得各自為政，不再關心全局的架構設計。關注公眾號Java旅途領取電子書。

從這個角度來看，使用微服務架構同時也需要組織結構做對應的調整。所以說做微服務改造需要管理者的支持。

改造完成後，小明和小紅分清楚各自的鍋子。兩人十分滿意，一切就像是麥克斯韋方程組一樣漂亮又完美。

然而…

沒有銀彈

春天來了，萬物復甦，又到了一年一度的購物狂歡節。眼看著日訂單數量蹭蹭地上漲，小皮小明小紅喜笑顏開。可惜好景不長，樂極生悲，突然嘣的一下，系統掛了。

以往單體應用，排查問題通常是看一下日誌，研究錯誤訊息和呼叫堆疊。而微服務架構整個應用程式分散成多個服務，定位故障點非常困難。小明一個台機器一台機器地查看日誌，一個服務一個服務地手動呼叫。經過十幾分鐘的查找，小明終於定位到故障點：促銷服務因為接收的請求量太大而停止回應了。其他服務都直接或間接地會呼叫促銷服務，於是也跟著宕機了。 在微服務架構中，一個服務故障可能會產生雪崩效用，導致整個系統故障。其實在節前，小明和小紅是有做過請求量評估的。按照預計，伺服器資源是足以支援節日的請求量的，所以肯定是哪裡出了問題。不過情勢緊急，隨著每一分每一秒流逝的都是白花花的銀子，因此小明也沒時間排查問題，當機立斷在雲上新建了幾台虛擬機，然後一台一台地部署新的促銷服務節點。幾分鐘的操作後，系統總算是勉強恢復正常了。整個故障時間內估計損失了幾十個的銷售額，三人的心在滴血…

事後，小明簡單寫了個日誌分析工具（量太大了，文字編輯器幾乎打不開，打開了肉眼也看不過來），統計了促銷服務的訪問日誌，發現在故障期間，商品服務由於代碼問題，在某些場景下會對促銷服務發起大量請求。這個問題並不複雜，小明手指抖一抖，修復了這個價值幾十萬的Bug。

問題是解決了，但誰也無法保證不會再發生類似的其他問題。微服務架構雖然邏輯設計看起來是完美的，但就像積木搭建的華麗宮殿一樣，經不起風吹草動。微服務架構雖然解決了舊問題，也引入了新的問題：

• 微服務架構整個應用分散成多個服務，定位故障點非常困難。
• 穩定性下降。服務數量變多導致其中一個服務故障的機率增大，而一個服務故障可能導致整個系統掛掉。事實上，在大訪問量的生產場景下，故障總是會出現的。
• 服務數量非常多，部署、管理的工作量很大。
• 開發方面：如何確保各個服務在持續開發的情況下仍然保持協同合作。
• 測試方面：服務分割後，幾乎所有功能都會涉及多個服務。原本單一程式的測試變成服務間呼叫的測試。測試變得更加複雜。

小明小紅痛定思痛，決心好好解決這些問題。故障的處理一般從兩方面入手，一方面盡量減少故障發生的機率，另一方面降低故障造成的影響。

監控- 發現故障的徵兆

在高並發分散式的場景下，故障經常是突然間就雪崩式爆發。所以必須建立完善的監控體系，盡可能發現故障的徵兆。

微服務架構中組件繁多，各個組件所需監控的指標不同。例如Redis快取一般監控佔用記憶體值、網路流量，資料庫監控連線數、磁碟空間，業務服務監控並發數、回應延遲、錯誤率等。因此如果做一個大而全的監控系統來監控各個元件是不大現實的，而且擴充性會很差。一般的做法是讓各個元件提供報告自己目前狀態的介面（metrics介面），這個介面輸出的資料格式應該是一致的。然後部署一個指標擷取器元件，定時從這些介面取得並保持元件狀態，同時提供查詢服務。最後還需要一個UI，從指標採集器查詢各項指標，繪製監控介面或根據閾值發出警告。

大部分元件都不需要自己動手開發，網路上有開源元件。小明下載了RedisExporter和MySQLExporter，這兩個元件分別提供了Redis快取和MySQL資料庫的指標介面。微服務則根據各個服務的業務邏輯實作自訂的指標介面。接著小明採用Prometheus作為指標採集器，Grafana配置監控介面和郵件警報。這樣一套微服務監控系統就搭建起來了：

#定位問題- 連結追蹤

##在微在服務架構下，一個使用者的請求往往涉及多個內部服務呼叫。為了方便定位問題，需要能夠記錄每個使用者請求時，微服務內部產生了多少服務調用，及其調用關係。這個叫做鏈路追蹤。

我們用一個Istio文件裡的連結追蹤範例來看看效果：

#圖片來自Istio文件

從圖中可以看到，這是一個使用者存取productpage頁面的請求。在請求過程中，productpage服務順序呼叫了details和reviews服務的介面。而reviews服務在回應過程中又呼叫了ratings的介面。整個連結追蹤的記錄是一棵樹：

要實現連結跟踪，每次服務呼叫都會在HTTP的HEADERS中記錄至少記錄四項資料：

• traceId：traceId標識一個使用者請求的呼叫連結。具有相同traceId的呼叫屬於同一條連結。
• spanId：標識一次服務呼叫的ID，即連結追蹤的節點ID。
• parentId：父節點的spanId。
• requestTime & responseTime：請求時間和回應時間。

另外，還需要呼叫日誌收集與儲存的元件，以及展示連結呼叫的UI元件。

以上只是一個極簡的說明，關於連結追蹤的理論基礎可詳見Google的Dapper

了解了理論基礎後，小明選用了Dapper的一個開源實作Zipkin。然後手指一抖，寫了個HTTP請求的攔截器，在每次HTTP請求時產生這些資料注入到HEADERS，同時非同步發送呼叫日誌到Zipkin的日誌收集器中。這裡額外提一下，HTTP請求的攔截器，可以在微服務的程式碼中實現，也可以使用一個網路代理元件來實現（不過這樣子每個微服務都需要加一層代理）。

連結追蹤只能定位到哪個服務出現問題，不能提供具體的錯誤訊息。尋找特定的錯誤訊息的能力則需要由日誌分析元件來提供。

分析問題 - 日誌分析

日誌分析元件應該在微服務興起之前就被廣泛使用了。即使單體應用架構，當訪問數變大、或伺服器規模增多時，日誌檔案的大小會膨脹到難以用文字編輯器進行訪問，更糟的是它們分散在多台伺服器上面。排查一個問題，需要登入各台伺服器去取得日誌文件，一個一個尋找（而且開啟、查找都很慢）想要的日誌資訊。

因此，在應用程式規模變大時，我們需要一個日誌的「搜尋引擎」。以便於能準確的找到想要的日誌。另外，資料來源一側還需要收集日誌的元件和展示結果的UI元件：

#小明調查了一下，使用了大名鼎鼎的ELK日誌分析元件。 ELK是Elasticsearch、Logstash和Kibana三個元件的縮寫。

• Elasticsearch：搜尋引擎，同時也是日誌的儲存。
• Logstash：日誌擷取器，它接收日誌輸入，對日誌進行一些預處理，然後輸出到Elasticsearch。
• Kibana：UI元件，透過Elasticsearch的API尋找資料並展示給使用者。

最後還有一個小問題是如何將日誌傳送到Logstash。一種方案是在日誌輸出的時候直接呼叫Logstash介面將日誌傳送過去。這樣一來又（咦，為啥要用「又」）要修改程式碼…於是小明選用了另一種方案：日誌仍然輸出到文件，每個服務裡再部署個Agent掃描日誌文件然後輸出給Logstash 。

廣告插播：追蹤公眾號碼：##Java學習指南#，取得更多技術乾貨好文。

網關- 權限控制，服務治理

拆分成微服務後，出現大量的服務，大量的接口，使得整個呼叫關係亂糟糟的。常在開發過程中，寫著寫著，忽然想不起某個資料該呼叫哪個服務。或者寫歪了，呼叫了不該呼叫的服務，本來一個唯讀的功能結果修改了資料…

為了回應這些情況，微服務的呼叫需要一個把關的東西，也就是網關。在呼叫者和被呼叫者中間加一層網關，每次呼叫時進行權限校驗。另外，網關也可以作為一個提供服務介面文件的平台。

使用網關有一個問題就是要決定在多大粒度上使用：最粗粒度的方案是整個微服務一個網關，微服務外部透過網關存取微服務，微服務內部則直接呼叫；最細粒度則是所有調用，不管是微服務內部調用或來自外部的調用，都必須通過網關。折中的方案是依照業務領域將微服務分成幾個區，區內直接調用，區間透過網關調用。

由於整個網路超市的服務數量還不算特別多，小明採用的最粗粒度的方案：

##服務註冊與發現- 動態擴容
前面的元件，都是旨在降低故障發生的可能性。然而故障總是會發生的，所以另一個需要研究的是如何降低故障所產生的影響。

最粗暴的（也是最常用的）故障處理策略就是冗餘。一般來說，一個服務都會部署多個實例，這樣一來能夠分擔壓力提高效能，二來即使一個實例掛了其他實例還能回應。

冗餘的一個問題是使用幾個冗餘？這個問題在時間軸上並沒有一個確切切的答案。根據服務功能、時間段的不同，需要不同數量的實例。例如在平日裡，可能4個實例已經夠用；而在促銷活動時，流量大增，可能需要40個實例。因此冗餘數量並不是固定的值，而是根據需要即時調整的。

一般來說新增實例的操作為：

1. 部署新執行個體
2. 將新執行個體註冊到負載平衡或DNS上

操作只有兩步，但如果註冊到負載平衡或DNS的操作為人工操作的話，那事情就不簡單了。想想新增40個實例後，要手動輸入40個IP的感覺…

#解決這個問題的方案是服務自動註冊與發現。首先，需要部署一個服務發現服務，它提供所有已註冊服務的地址資訊的服務。 DNS也算是一種服務發現服務。然後各個應用服務在啟動時自動將自己註冊到服務發現服務。且應用程式服務啟動後會即時（定期）從服務發現服務同步各個應用程式服務的位址清單到本機。服務發現服務也會定期檢查應用程式服務的健康狀態，去除不健康的實例位址。這樣新增實例時只需要部署新實例，實例下線時直接關停服務即可，服務發現會自動檢查服務實例的增減。

服務發現也會跟著客戶端負載平衡搭配使用。由於應用程式服務已經同步服務位址清單在本地了，所以造訪微服務時，可以自己決定負載策略。甚至可以在服務註冊時加入一些元資料（服務版本等資訊），客戶端負載則根據這些元資料進行流量控制，實現A/B測試、藍綠發布等功能。

服務發現有很多元件可以選擇，比如說Zookeeper 、Eureka、Consul、Etcd等。不過小明覺得自己水準不錯，想炫技，於是基於Redis自己寫了一個…

熔斷、服務降級、限流

熔斷

當一個服務因為各種原因停止回應時，呼叫方通常會等待一段時間，然後逾時或收到錯誤返回。如果呼叫鏈路比較長，可能會導致請求堆積，整個鏈路佔用大量資源一直在等待下游回應。所以當多次訪問一個服務失敗時，應熔斷，標記該服務已停止工作，直接返回錯誤。直至該服務恢復正常後再重新建立連線。

圖片來自《微服務設計》

服務降級

當下游服務停止工作後，如果該服務並非核心業務，則上游服務應該降級，以確保核心業務不會中斷。例如網路超市下單介面有推薦商品湊單的功能，當推薦模組掛了後，下單功能不能一起掛掉，只需要暫時關閉推薦功能即可。

限流

一個服務掛掉後，上游服務或使用者一般會習慣性地重試存取。這導致一旦服務恢復正常，很可能因為瞬間網路流量過大又立刻掛掉，在棺材裡重複仰臥起坐。因此服務需要能夠自我保護－限流。限流策略很多，最簡單的例如當單位時間內請求數過多時，丟棄多餘的請求。另外，也可以考慮分區限流。僅拒絕來自產生大量請求的服務的請求。例如商品服務和訂單服務都需要存取促銷服務，商品服務由於代碼問題發起了大量請求，促銷服務則只限制來自商品服務的請求，來自訂單服務的請求則正常響應。

測試

在微服務架構下，測試分為三個層次：

1. 端對端測試：覆蓋整個系統，一般在使用者介面機型測試。
2. 服務測試：針對服務介面進行測試。
3. 單元測試：針對程式碼單元進行測試。

三種測試從上到下實作的容易程度遞增，但是測試效果遞減。端到端測試最費時費力，但是通過測試後我們對系統最有信心。單元測試最容易實施，效率也最高，但測試後無法保證整個系統沒有問題。

由於端對端測試實作難度較大，一般只對核心功能做端對端測試。一旦端對端測試失敗，則需要將其分解到單元測試：則分析失敗原因，然後編寫單元測試來重現這個問題，這樣未來我們便可以更快地捕獲相同的錯誤。

服務測試的難度在於服務會經常依賴一些其他服務。這個問題可以透過Mock Server解決：

單元測試大家都很熟悉了。我們一般會寫大量的單元測試（包括回歸測試）盡量覆蓋所有程式碼。

微服務框架

指標介面、連結追蹤注入、日誌引流、服務註冊發現、路由規則等元件以及熔斷、限流等功能都需要在應用服務上添加一些對接代碼。如果讓每個應用程式服務自己實現是非常耗時且耗力的。基於DRY的原則，小明開發了一套微服務框架，將與各個元件對接的程式碼和另外一些公共程式碼抽離到框架中，所有的應用服務都統一使用這套框架進行開發。

使用微服務框架可以實現許多自訂的功能。甚至可以將程式呼叫堆疊資訊注入到鏈路跟踪，實現程式碼層級的鏈路追蹤。或是輸出線程池、連接池的狀態訊息，即時監控服務底層狀態。

使用統一的微服務框架有一個比較嚴重的問題：框架更新成本很高。每次框架升級，都需要所有應用服務配合升級。當然，一般會使用相容方案，留出一段並行時間等待所有應用服務升級。但是如果應用服務非常多時，升級時間可能會非常漫長。並且有一些很穩定幾乎不更新的應用服務，其負責人可能會拒絕升級…因此，使用統一微服務框架需要完善的版本管理方法和開發管理規範。

另一條路 - Service Mesh

另一種抽象公共程式碼的方法是直接將這些程式碼抽象化到一個反向代理程式元件。每個服務都額外部署這個代理元件，所有出站入站的流量都透過該元件處理和轉送。這個組件稱為Sidecar。

Sidecar不會產生額外網路成本。 Sidecar會和微服務節點部署在同一台主機上並且共用相同的虛擬網路卡。所以sidecar和微服務節點的通訊其實都只是透過記憶體拷貝來實現的。

圖片來自：Pattern: Service Mesh

Sidecar只負責網路通訊。還需要有個組件來統一管理所有sidecar的配置。在Service Mesh中，負責網路通訊的部分叫做資料平面（data plane），負責配置管理的部分叫做控制平面（control plane）。資料平面和控制平面構成了Service Mesh的基本架構。

圖片來自：Pattern: Service Mesh

Sevice Mesh比起於微服務框架的優點在於它不侵入代碼，升級和維護更方便。它常被詬病的則是性能問題。即使回環網路不會產生實際的網路請求，但仍有額外記憶體拷貝的成本。另外有一些集中式的流量處理也會影響效能。

結束、也是開始

微服務不是架構演進的終點。往細走還有Serverless、FaaS等方向。另一方面也有人在唱合久必分分久必合，重新發現單體架構…

不管怎樣，微服務架構的改造暫時告一段落了。小明滿足地摸了摸日益光滑的腦袋，打算這個週末休息一下約小紅喝杯咖啡。

以上是這可能是你看過最好的微服務架構詳解文章的詳細內容。更多資訊請關注PHP中文網其他相關文章！