一.什麼是微服務架構?
爲了方便理解，我先講一個小故事：（改編自一知乎答主）
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 爲什麼需要配置中心？
我們先來看看在沒有「配置中心」的傳統項目中，我們是怎麼處理各類配置參數問題的：
- 一般是靜態化配置。大多數在項目中單獨寫一個配置文件，例如 “config.conf”，然後將各類 參數配置、應用配置、環境配置、安全配置、業務配置 都寫到這個文件裏。當項目代碼邏輯中需要使用配置的時候，就從這個配置文件中讀取。這種做法雖然簡單，但如果參數需要修改，就非常的不靈活，甚至需要重啓運行中的項目才能生效。相信大多數開發同學都深有體會。
- 配置文件無法區分環境。由於配置文件是放在項目中的，但是我們項目可能會有多個環境，例如：測試環境、預發佈環境、生產環境。每一個環境所使用的配置參數理論上都是不同的，所以我們在配置文件中根據不同環境配置不同的參數，這些都是手動維護，在項目發佈的時候，極其容易因開發人員的失誤導致出錯。
- 配置文件過於分散。如果一個項目中存在多個邏輯模塊獨立部署，每個模塊所使用的配置內容又不相同，傳統的做法是會在每一個模塊中都放一個配置文件，甚至不同模塊的配置文件格式還不一樣。那麼長期的結果就是配置文件過於分散混亂，難以管理。
- 配置修改無法追溯。因爲採用的靜態配置文件方式，所以當配置進行修改之後，不容易形成記錄，更無法追溯是誰修改的、修改時間是什麼、修改前是什麼內容。既然無法追溯，那麼當配置出錯時，更沒辦法回滾配置了。
上面只是拿配置文件的形式來舉例，有的項目會採用數據庫配置，雖然靈活一點，但是依舊不能完全解決上述問題。
4.2 配置中心特點
- 配置集中管理、統一標準
- 配置與應用分離
- 實時更新
- 高可用
具有上述特性的「配置中心」是如何解決上面傳統配置所面臨的問題的呢？
- 採用“配置集中管理”，可以很好的解決傳統的“配置文件過於分散”的問題。所有的配置都集中在配置中心這一個地方管理，不需要每一個項目都自帶一個，這樣極大的減輕了開發成本。
- 採用“配置與應用分離”，可以很好的解決傳統的“配置文件無法區分環境”的問題，配置並不跟着環境走，當不同環境有不同需求的時候，就到配置中心獲取即可，極大的減輕了運維部署成本。
- 具備“實時更新”的功能，就是用來解決傳統的“靜態化配置”的問題。線上系統需要調整參數的時候，只需要在配置中心動態修改即可。
- 既然配置都統一管理了，那配置中心在整個系統中的地位就非常重要了，一旦配置中心不能正常提供服務，就可能會導致項目整體故障，因此“高可用”就是配置中心又一個很關鍵的指標了。
五.鏈路追蹤
5.1 爲什麼需要鏈路追蹤？
由於絕大部分項目只是一味地增加服務，並沒有對其妥善管理，當接口出現問題時，很難從錯綜複雜的服務調用網絡中找到問題根源，從而錯失了止損的黃金時機。
而鏈路追蹤的出現正是爲了解決這種問題，它可以在複雜的服務調用中定位問題，還可以在新人加入後臺團隊之後，讓其清楚地知道自己所負責的服務在哪一環。
5.2 鏈路追蹤實現原理
關於微服務鏈路追蹤的實現原理,大家可以參考這篇文章微服務鏈路追蹤原理
六.負載均衡
關於負載均衡方面,不做太多描述,相關概念大家平時接觸也比較多,可閱讀這篇文章什麼是負載均衡,爲什麼要做*負載均衡
七.熔斷
在微服務架構中，每一個微服務都是一個獨立的業務功能單元，而一個應用一般由多個微服務組成，微服務之間的交互是通過RPC（遠程過程調用）完成。
比如，我們的應用是微服務A調用微服務B和微服務C來完成的，而微服務B又需要調用微服務D，微服務D又需要調用微服務E。如果在調用的鏈路上對微服務E的調用，響應時間過長或者服務不可用，那麼對微服務D的調用就會佔用越來越多的系統資源，進而引起微服務D的系統崩潰，微服務D的不可用，又會連鎖反應的引起微服務B崩潰，進而微服務A崩潰，最終導致整個應用不可用。這也就是所謂的“雪崩效應”。
八.小結
本篇文章中,我們介紹了微服務架構核心,並做了一個基礎講解,方便大家瞭解各個部分的作用,不做深入展開講解.
參考文獻
