微服務架構核心基礎講解

一.什麼是微服務架構?

為了友善了解，我先講一個小故事：

Martin（微服務提出者也叫 Martin）剛來到公司時是一個基層員工，它上面有經理、老闆，那個時候所有人都聽老闆的指揮。但是過了兩年，公司的人越來越多，原來的模式下整個公司的運作效率太低，管理也很混亂。

于是已經踏上中層崗位的 Martin 建議老闆進行部門劃分（服務化），專門的部門隻做專門的事情（單一職責）。例如研發部門隻做研發，人事部門隻做招聘。老闆聽取了 Martin 的意見，對公司的組織架構進行了調整。

有一天，Martin 發現公司的部門越來越多，各個部門并不能完全知道對方所做的事情，這對跨部門協作（服務調用）帶來了困難。

行政部門會（注冊中心）來記錄所有的部門，每當有新的部門行政都會記錄下來（服務注冊），然後公布出來讓所有部門知道（服務發現）。

在新的組織架構下，公司的效率逐漸提高。老闆也給 Martin 發了大量獎金作為獎勵，Martin 從此赢取白富美走向了人生巅峰。

這是一個公司組織架構演變的故事，主要講的是随着公司規模的擴大，組織從集中化管理到分布化管理的過程。

映射到我們的資訊系統裡來也是一樣的，随着我們的系統越來越複雜，變得難以管理，也有人想到去拆分然後治理。在解決複雜問題上，分治可以說是一個屢試不爽的辦法。

二.網關

2.1 為什麼需要網關?

當我們的項目曾經還是單體應用的時候，雖然沒有

網關

的概念，但是一般在項目中都會用到

filter/過濾器

之類的東西，filter的作用就是把項目中的一些非業務邏輯的功能抽離出來獨立處理，避免與業務邏輯混在一起增加代碼複雜度。比如

鑒權認證功能、Session處理、安全檢查、日志處理

等等。

現在我們采用微服務架構了，在一個項目中微服務節點很多，如果讓每一個節點都去處理上面這些 “鑒權認證功能、Session處理、安全檢查、日志處理等” 會多出很多備援的代碼，也會給增加業務代碼的複雜度，是以我們就需要有一個網關把這些公共的功能獨立出來成為一個服務來統一的處理這些事情。

​

上圖是微服務架構網關示意圖

2.2 網關的功能

• 路由轉發

  網關

  是内部微服務的對外唯一入口，是以外面全部的請求都會先發到這個網關上，然後由網關來根據不同的請求轉發到不同的微服務節點上。例如可以 根據路徑 來轉發、也可以 根據參數 來轉發。

  由于内部微服務執行個體也會随着業務調整不停的變更，增加或者删除節點，

  網關

  可以與

  服務注冊

  子產品進行協同工作，保證将外部請求轉發到最合适的微服務節點上面去。

• 負載均衡

  既然

  網關

  是内部微服務的單一入口，是以網關在收到外部請求之後，還可以根據内部微服務每個執行個體的負荷情況進行動态的負載均衡調節。一旦内部的某個微服務執行個體負載很高，甚至是不能及時響應，則網關就通過負載均衡政策減少或停止向這個執行個體轉發請求。當所有的内部微服務執行個體都處理不過來的時候，網關還可以采用

  限流

  或

  熔斷

  的形式阻止外部請求，以保障整個系統的可用性。
• 安全認證

  網關

  就像是微服務的大門守衛，每一個請求進來之後，都必須先在網關上進行身份驗證，身份驗證通過後才轉發給後面的服務，轉發的時候一般也會帶上身份資訊。同時網關也需要對每一個請求進行安全性檢查，例如參數的安全性、傳輸的安全性等等。

• 日志記錄

  既然所有的請求都需要走網關，那麼我們就可以在網關上統一集中的記錄下這些行為日志。這些日志既可以作為我們後續事件查詢使用，也可以作為系統的性能監控使用。

• 資料轉換

  因為網關對外是面向多種不同的用戶端，不同的用戶端所傳輸的資料類型可能是不一樣的。是以網關還需要具備資料轉換的功能，将不同用戶端傳輸進來的資料轉換成同一種類型再轉發給内部微服務上，這樣，相容了這些請求的多樣性，保證了微服務的靈活性。

三.服務注冊和發現

3.1 為什麼需要服務注冊和發現?

現在我們通過一個小案例來簡要闡述微服務的服務注冊和發現,加入我們公司有一款産品已經線上上運作，在情人節這天想搞一場促銷活動，為了應對此次促銷活動我們可能需要新上線三個微服務執行個體來支撐這場促銷活動。那麼我們如何讓網關知道我們新上線的微服務?進而進行正常的轉發。作為苦逼程式員的你就隻有手動去

網關API gateway

中添加新增的這三個微服務執行個體的 ip 與port ，一個真正線上的微服務系統可能有成百上千微服務，難道也要一個一個去手動添加嗎？有沒有讓系統自動去實作這些操作的方法呢？如下圖所示

如圖所示，當我們新添加一個微服務執行個體的時候，微服務就會将自己的 ip 與 port 發送到注冊中心，在注冊中心裡面記錄起來。當 API gateway 需要通路某些微服務的時候，就會去注冊中心取到相應的 ip 與 port。進而實作自動化操作。是以，服務的注冊中心就是維護調用和被調用方的資訊。

3.2 服務注冊的兩種方式

服務注冊方式有以下兩種：

• 用戶端注冊

  用戶端注冊即為：将服務注冊與服務登出的邏輯寫進代碼裡面，當一個微服務啟動的時候，将資訊寫入注冊中心，當一個微服務下線的時候，登出相應的資訊。且需要不同的程式設計語言實作相同的一套邏輯。對業務代碼有一定的入侵。期間，注冊中心與各個微服務之間還需要保持心跳。

• 第三方注冊

  第三方注冊由一個獨立的服務 Registrar 負責注冊與登出。當服務啟動後以某種方式通知Registrar，然後Registrar負責向注冊中心發起注冊工作。同時注冊中心要維護與服務之間的心跳，當服務不可用時，向注冊中心登出服務。

3.3 服務發現的兩種方式

• 用戶端發現

  用戶端負責向注冊中心擷取相應的 ip 與 port ，多種語言需要實作同一套邏輯，有點備援的感覺。

• 服務端發現

  由 API gateway 實作服務發現的功能，這樣一套語言便可輕松維護服務發現的功能。

四.配置中心

4.1 為什麼需要配置中心？

我們先來看看在沒有「配置中心」的傳統項目中，我們是怎麼處理各類配置參數問題的：

1. 一般是靜态化配置。大多數在項目中單獨寫一個配置檔案，例如 “config.conf”，然後将各類 參數配置、應用配置、環境配置、安全配置、業務配置 都寫到這個檔案裡。當項目代碼邏輯中需要使用配置的時候，就從這個配置檔案中讀取。這種做法雖然簡單，但如果參數需要修改，就非常的不靈活，甚至需要重新開機運作中的項目才能生效。相信大多數開發同學都深有體會。
2. 配置檔案無法區分環境。由于配置檔案是放在項目中的，但是我們項目可能會有多個環境，例如：測試環境、預釋出環境、生産環境。每一個環境所使用的配置參數理論上都是不同的，是以我們在配置檔案中根據不同環境配置不同的參數，這些都是手動維護，在項目釋出的時候，極其容易因開發人員的失誤導緻出錯。
3. 配置檔案過于分散。如果一個項目中存在多個邏輯子產品獨立部署，每個子產品所使用的配置内容又不相同，傳統的做法是會在每一個子產品中都放一個配置檔案，甚至不同子產品的配置檔案格式還不一樣。那麼長期的結果就是配置檔案過于分散混亂，難以管理。
4. 配置修改無法追溯。因為采用的靜态配置檔案方式，是以當配置進行修改之後，不容易形成記錄，更無法追溯是誰修改的、修改時間是什麼、修改前是什麼内容。既然無法追溯，那麼當配置出錯時，更沒辦法復原配置了。

上面隻是拿配置檔案的形式來舉例，有的項目會采用資料庫配置，雖然靈活一點，但是依舊不能完全解決上述問題。

4.2 配置中心特點

• 配置集中管理、統一标準
• 配置與應用分離
• 實時更新
• 高可用

具有上述特性的「配置中心」是如何解決上面傳統配置所面臨的問題的呢？

1. 采用“配置集中管理”，可以很好的解決傳統的“配置檔案過于分散”的問題。所有的配置都集中在配置中心這一個地方管理，不需要每一個項目都自帶一個，這樣極大的減輕了開發成本。
2. 采用“配置與應用分離”，可以很好的解決傳統的“配置檔案無法區分環境”的問題，配置并不跟着環境走，當不同環境有不同需求的時候，就到配置中心擷取即可，極大的減輕了運維部署成本。
3. 具備“實時更新”的功能，就是用來解決傳統的“靜态化配置”的問題。線上系統需要調整參數的時候，隻需要在配置中心動态修改即可。
4. 既然配置都統一管理了，那配置中心在整個系統中的地位就非常重要了，一旦配置中心不能正常提供服務，就可能會導緻項目整體故障，是以“高可用”就是配置中心又一個很關鍵的名額了。

五.鍊路追蹤

5.1 為什麼需要鍊路追蹤？

由于絕大部分項目隻是一味地增加服務，并沒有對其妥善管理，當接口出現問題時，很難從錯綜複雜的服務調用網絡中找到問題根源，進而錯失了止損的黃金時機。

而鍊路追蹤的出現正是為了解決這種問題，它可以在複雜的服務調用中定位問題，還可以在新人加入背景團隊之後，讓其清楚地知道自己所負責的服務在哪一環。

5.2 鍊路追蹤實作原理

關于微服務鍊路追蹤的實作原理,大家可以參考這篇文章微服務鍊路追蹤原理

六.負載均衡

關于負載均衡方面,不做太多描述

七.熔斷

在微服務架構中，每一個微服務都是一個獨立的業務功能單元，而一個應用一般由多個微服務組成，微服務之間的互動是通過RPC（遠端過程調用）完成。

八.小結