系統服務化

服務拆分

根據業務或組織架構進行基本服務拆分，每一個服務實例會擁有專屬的網絡地址、獨立的計算資源，而且獨立部署。客戶端經過訪問服務實例的地址來調用服務 API。不一樣服務也能夠相互調用。

統一配置管理

一個服務可能會跑多個實例，每一個服務實例都會須要作配置。爲了方便統一調整配置，咱們能夠把配置中心化，每一個服務實例都去找配置管理器（Configuration Manager）拿配置。當配置更新的時候，咱們也可讓服務實例再去拿新的配置。

命名服務

多服務實例帶來的問題：網絡地址（好比 IP）很容易由於擴容、維護而變更，調用者難以實時獲知可用的地址。

鑑於此，咱們能夠把網絡地址抽象成不容易變更的概念，好比給每一個服務一個固定的名字。互聯網使用 DNS 來解決這個問題，對應到微服務基建裏面就是服務名冊（Service Registry）。

每一個服務實例在運行期間，都會以心跳的形式向服務名冊發送註冊信息，包括服務的 ID 、訪問地址以及健康情況。

這樣，須要訪問服務的時候，客戶端就能夠先問服務名冊拿可用的實例地址，而後再訪問實例來調用服務。除了更好地定位實例地址，服務名冊還能夠在某些實例下線、維護或升級的時候把其臨時從名冊中去掉，讓服務不斷線。

服務之間的調用也是如此，先找名冊拿網絡地址，再進行調用。

網關

找名冊要地址，而後調用服務 API，這些是每一個客戶端都會去作的雜事，咱們徹底能夠把這些事情抽象、集中，把服務的 API 整合到一個大的中心點，而後把要地址和調用服務 API 這樣的細節封裝起來，全部客戶端都只跟這個中心點對話，再也不直接訪問單個服務。

從結構上看，這個中心點把整個架構劃分紅了內外兩部分，內部是全部的服務，客戶端則在外部，中心點站在中間。它做爲內外的惟一通道，被瓜熟蒂落地命名做「API 網關」（API Gateway），有時候也被稱作「邊緣服務」（Edge Service）。

API 網關做爲惟一出入口，又佔據了最前沿的有利位置，因此有時還會承載別的公共功能，好比咱們立刻會提到的鑑權。

鑑權和身份認證

鑑權（Auth）包括了兩個部分：

• 身份認證（Authentication）和權限驗證（Authorization）。
• 身份認證關心的是「你是誰」，權限驗證關心的是「你能不能作某件事」。

身份和權限都是高度中心化的概念。

對於一個系統來講，用戶的身份必須是統一的。

權限稍微複雜一點。和身份不一樣，權限一般分紅兩種類別：

• 功能權限和數據權限。

這樣的劃分對應了現實世界中常見的權限模式：

• 你的角色決定了你的職能，而職能範圍一般由附加條件來限制。

明確鑑權中心化以後，咱們就能夠開發一個公用的鑑權服務，執行身份認證和權限驗證。下一個問題是：誰來發起鑑權？

全部服務的調用都要求調用者明確本身的身份，因此天然身份認證越靠前越好。做爲出入口的 API 網關天然是發起身份認證的不二之選。

權限驗證則稍微複雜，徹底值得另起一文詳述。此處咱們暫時假定權限驗證也由 API 網關來發起。

消息隊列

開發繼續進行，一切風平浪靜，技術上暫時沒有什麼問題。不過，業務上有一個問題須要解決。

好比，咱們作一個在線商城，要求在訂單成功建立的一刻，倉庫就要啓動備貨和發貨的流程。

問題是，訂單和倉儲是兩個服務，不一樣團隊在負責，並且從關注點來講，訂單服務並不關心倉儲相關的問題，因此訂單服務不可能在建立訂單的時候去主動通知倉儲服務。倉儲服務只能定時輪詢訂單服務，看看有沒有新的訂單。這不只麻煩，並且實時性不夠。

這就意味着咱們須要再引入一箇中心化的公共服務：

• 消息中介（Message Broker）。

當某個事件發生的時候（好比用戶激活成功、訂單建立成功），服務能夠朝消息隊列發一條消息。而其餘服務能夠訂閱這些消息，並針對這些消息作出反應。

好比，倉儲服務能夠訂閱訂單建立成功的消息。這樣，訂單成功建立後，訂單服務將這個消息發到消息中介，消息中介通知倉儲服務，倉儲服務一看，就問訂單服務要新的訂單信息，最後，啓動出庫流程。

消息中介除了能廣播事件以外，還能作異步調用。把同步的調用轉化成異步的回調。針對調用時間長和不要求實時結果的調用，能夠增長性能，提高體驗。

先後端分離

支撐一個業務有先後兩端的研發工做，兩者是不一樣步的。
前端由業務流程和設計來驅動，但願按順序產出；後端則由業務資源和建模來驅動，但願按模塊來產出。

好比說，前端經常會由於設計的緣由調整本身須要的字段，然後端從建模的角度並無這個須要，也沒有動力頻繁地去跟隨前端的調整，使得前端不得不在不穩定的網絡條件下傳輸多餘的信息，佔用了寶貴的網絡帶寬。

此外，前端呈現某個業務步驟的時候，有兩種信息不屬於當前必備信息，但經常須要和必要信息一塊兒展現。一種是狀態信息，好比當前的登陸狀態和用戶名，短消息的數量等等。
一種是垂直相關的信息，好比在展現文章的時候順便展現一下相關的文章。

這就要求前端在調用主服務的同時還要再調用多個不一樣的服務。且不說這些服務有可能會有調用超時、出錯的可能，僅僅是多出來一堆異步請求，就已經足夠讓前端效率下降一大截了。

在微服務體系下，這些問題更加嚴重，由於如今不只僅是先後端的差異，不一樣服務還由不一樣團隊負責。這些團隊的訴求和日程不一，很難作到前端所須要的快速響應。

這些問題和麻煩可能會催生一個「緩衝帶」，好比後端出專人來負責對接前端的須要，或者前端派駐一我的到後端來談需求。按康威定律，這種溝通體系，長此以往，很容易以軟件的形式沉澱下來，造成一個專屬的中間層。

• 第一是解耦先後端的工做，下降相互的影響。前端須要的東西能夠寫在中間層裏，讓它頻繁變化也沒有關係。後端若是尚未準備好，前端也能夠在這一層模擬假的數據，不至於被阻塞。
• 第二則是提高前端的運行效率。前端能夠把所須要的多個服務的東西統一彙總，一次拿完，省得發多個請求。

放置的位置則在 API 網關以內，讓它能夠享有 API 網關所帶來的好處和保護。

最後是維護問題。按照「誰主張，誰舉證」的原則，既然有了這個中間層，好處讓前端得了，那麼，理論上應該由前端來維護。

這樣，一個主要爲前端服務的中間層就定義好了。不一樣類型的前端（桌面、移動）可能會有不一樣的須要，爲了不中間層的碎片化，咱們可讓各個中間層都特定的前端類型緊密耦合，好比桌面專用、移動專用。如此，每一箇中間層都像是某類型前端的專享後端，因此「前置後端」（Backend-for-Frontend，簡稱 BFF）也所以得名。

提升服務容錯

如今，調試也方便了，咱們又繼續開發。一開始沒有什麼問題，但部署到預生產環境的時候，又一個問題出現了：

• 整個體系的容錯度很低。一個小錯誤容易被層層傳遞和放大，致使整個體系的崩潰。

咱們都知道，編程最麻煩的就是遠程調用。本地調用大部分時候結果是「成功」或「失敗」，但遠程調用則極可能是「無響應」。「無響應」有多是正常的，對方可能稍後會給你結果，也多是由於對方已經死了，無法給你響應。最壞的結果，就是門口擠滿了人，你們都在等你給結果，而你也在等別人給結果，資源所有佔用來等，什麼也作不了。

不過，遠程調用是沒法避免的。在微服務體系中，這個問題被進一步放大。這是由於微服務的模塊化以服務爲單位，而每一個服務獨立部署和運維，使得服務之間的調用成了屢見不鮮。

在這種嚴峻的狀況下，咱們必須從架構上儘可能提升整個服務體系的容錯度，讓個別服務的問題不至於影響到全局。

具體的作法，則是給遠程調用加一個熔斷閾值檢查，當調用超時次數超過閾值時，就再也不調用，直接返回錯誤。過一段時間以後，再把閾值恢復，嘗試繼續調用，重複前面的過程。這個機制就是迴路熔斷，而這個工具則是迴路熔斷器（Circuit Breaker）。

除了隔離已經出錯的服務實例，熔斷器還有一個重要的功能是提供備用方案。雖然咱們把全部業務都拆成了服務，但服務有高低貴賤之分。有一些服務屬於關鍵服務，一旦出問題，則整個流程沒法繼續，有一些則屬於分支服務，即使錯了，也不會影響大局。

好比說，購買商品的時候，經常會根據用戶的習慣和當前正在購買的東西作一些推薦。負責推薦的服務出問題的話，大不了就不推薦了，不該該影響用戶正常的購買流程。

同理，若是是在線點餐的地址定位服務出問題了，咱們也應該容許用戶手動選擇餐廳進行點餐——體驗雖然不佳，但至少正常的流程仍然能夠走完。基於這個考慮，熔斷器應該爲非必要的服務調用提供備用方案，儘可能保證核心流程的順暢。

提高服務彈力

要正式上線，咱們還必須作好負載均衡（Load Balancing，下簡稱 LB），提高整個服務的彈性。要作負載均衡，從理論上有兩種方式：

• 客戶端負載均衡（Client-Side LB）：由客戶端來決定如何分散請求。
• 中間方負載均衡（Mid-Tier LB）：由 DNS、網關等中間方來決定如何分散請求。

如今，服務名冊中已經有了服務及其對應的實例地址列表，因此客戶端的負載均衡最簡便的方式就是把地址拉下來，而後依次或者隨機選擇可用的地址。

中間方的負載均衡則選擇面較多，從最外層的 DNS 到網關均可以不一樣程度地去按須要去作。

基礎設施

在作擴展時，架構師應該注意區分哪些東西應該中心化，哪些東西應該由服務自行決定。 好比說，在本文提到的基建之中，（幾乎是）強制徹底中心化的模塊有：

• 配置管理
• 服務名冊
• 消息隊列

其中，配置管理和服務名冊是全部服務都須要的基礎設施，必然須要統一。消息隊列和日誌收集都是爲了跨服務的操做和追蹤，也必須中心化。

半中心化的模塊則有：

• 路由
• 鑑權

路由和鑑權都必須統一，咱們前面討論過。

不過，微服務可能會向外界暴露「自用」和「客用」等多套公共 API（好比快遞公司內部使用的物流 API 和開放給第三方使用的物流 API），因此可能會有兩個 API 網關，對應會有兩套 API 目錄和兩套鑑權體系，因此，它們是「半中心化」。

這些都是中心化、半中心化的選擇範例。每一次中心化的選擇均可能會讓整個架構變得死板，失去靈活性，因此，咱們在設計和擴展基建的時候應該特別注意這個問題。

除了中心化的選擇以外，架構發展的另外一個關注點，是讓業務保持「黑盒」。

咱們把每一個服務之間的關聯抽取了出來，也把權限的定義和驗證抽取了出來，每一個服務變得簡單而純粹，成了「純業務式服務」，等同於一個僅包含了業務規則的黑盒。這樣，無論服務和模塊再多，也沒有影響。業務的重用性也很高。

總而言之，搭建好了微服務的必要設施以後，剩下的就要根據實際狀況和項目經驗來繼續調整了。好比，咱們可能會選擇把不少功能合併到一層，以免過分分層所帶來的沒必要要的性能損失，或者對整個基建進行一些細節微調。只要把控好「中心-自理」和「業務-非業務」之間的關係，這個基礎設施就能健康地發展。

總結

微服務組件（按請求流中的出場順序）：

• 配置管理：配置集中管理。
• API 網關：對外的 API 總目錄；API 依賴關係；發起鑑權。
• 服務名冊：服務的註冊和發現。
• 鑑權服務：提供鑑權服務：認證身份，驗證功能權限。
• 前置後端：按前端的需求拆解請求、調用服務，並彙總、轉換結果。
• 消息中介：全局通知機制；異步調用機制。
• 迴路熔斷：隔離出問題的服務並等待其恢復；提供備用方案。
• 負載均衡：避免服務過載。