代碼改變世界

系統服務化

2018-06-28 12:57 春哥大魔王 閱讀(...) 評論(...) 編輯 收藏

服務拆分

根據業務或組織架構進行基本服務拆分,每個服務實例會擁有專屬的網絡地址、獨立的計算資源,并且獨立部署。客戶端通過訪問服務實例的地址來調用服務 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 依賴關系;發起鑒權。
  • 服務名冊:服務的注冊和發現。
  • 鑒權服務:提供鑒權服務:認證身份,驗證功能權限。
  • 前置后端:按前端的需求拆解請求、調用服務,并匯總、轉換結果。
  • 消息中介:全局通知機制;異步調用機制。
  • 回路熔斷:隔離出問題的服務并等待其恢復;提供備用方案。
  • 負載均衡:避免服務過載。
四川金7乐历史开奖号码查询