技術文章 » 架構師修煉系列【微服務】

架構師修煉系列【微服務】

2020-09-19 12:04:33

微服務與SOA的關係

SOA和微服務的關係和區別，大概分為幾個典型的觀點：

  • 微服務是SOA的實現方式：這種觀點認為 SOA 是一種架構理念，而微服務是 SOA 理念的一種具體實現方法,例如，「微服務就是使用HTTP RESTful協定來實現ESB的SOA」、「使用SOA來構建單個系統就是微服務」、「微服務就是更細粒度的 SOA 」
    在這裡插入圖片描述
  • 微服務是去掉ESB後的SOA：這種觀點認為傳統SOA架構最廣為人詬病的就是龐大、複雜、低效的 ESB ,因此將ESB去掉，改為輕量級的HTTP實現，就是微服務
    在這裡插入圖片描述
  • 微服務是一種和SOA相似但本質上不同的架構理念：這種觀點認為微服務和SOA只是有點類似，但本質上是不同的架構設計理念。相似點在於下圖中交叉的地方，就是兩者都關注「服務」，都是通過服務的拆分來解決可延伸性問題。本質上不同的地方在於幾個核心理念的差異：是否有ESB 、服務的粒度、架構設計的目標等。
    在這裡插入圖片描述
    對比一下SOA和微服務的一些具體做法：
  • 服務粒度：整體上來說，SOA的服務粒度要粗一些，而微服務的服務粒度要細一些。
    例如，對一個大型企業來說，「員工管理系統」就是一個SOA架構中的服務；而如果採用微服務架構，則「員工管理系統」會被拆分為更多的服務，比如「員工資訊管理」「員工考勤管 理」「員工假期管理」「員工福利管理」等更多服務
  • 服務通訊：SOA採用了ESB作為服務間通訊的關鍵元件，負責服務定義、服務路由 、訊息轉換、訊息傳遞，總體上是重量級的實現。微服務推薦使用統一的協定和格式，例如，RESTful協定、RPC協定，無須 ESB 這樣的重量級實現
    Martin Flower將微服務架構的服務通訊理念稱為「 Smart endpoints and dumb pipes簡單翻譯為「聰明的終端，愚蠢的管道」。 之所以用「愚蠢」二字，其實就是與ESB對比的，因為ESB太強大了，既知道每個服務的協定型別（例如，是RMI還是HTTP），又知道每個服務的資料型別（例如，是XML還是JSON），還知道每個資料的格式（例如，是 2017-01-01還是01/01/2017），而微服務的「 dumb pipes 」僅僅做訊息傳遞，對訊息格式和內容一無所知
  • 服務交付：SOA對服務的交付並沒有特殊要求，因為SOA更多考慮的是相容己有的系統；微服務的架構理念要求「快速交付」相應地要求採取自動化測試、持續整合、自動化部署等敏捷開發相關的最佳實踐，如果沒有這些基礎能力支撐，微服務規模一旦變大（例如，超過20個微服務），整體就難以達到快速交付的要求，這也是很多企業在實行微服務時踩過的一個明顯的坑，就是系統拆分為微服務後，部署的成本呈指數上升
  • 應用場景：SOA更加適合於龐大、複雜、異構的企業級系統，這也是SOA誕生的背景 。這類系統的典型特徵就是很多系統已經發展多年，採用不同的企業級技術，有的是內部開發的， 有的是外部購買的，無法完全推倒重來或進行大規模的優化和重構。因為成本和影響太大，只能採用相容的方式進行處理，而承擔相容任務的就是ESB；微服務更加適合於快速、輕量級、基於 Web 的網際網路系統，這類系統業務變化快，需要快速嘗試、快速交付；同時基本都是基於Web ，雖然開發技術可能差異很大（例如， Java 、 C＋＋、 .NET 等），但對外介面基本都是提供HTTP RESTful風格的介面，無須考慮在介面層進行類似SOA的ESB那樣的處理
    綜合上述分析 ，我們將 SOA 和微服務對 比如下表所示。
    在這裡插入圖片描述
    SOA 和微服務是兩種不同理念的架構模式，並不存在孰優孰劣，而只是應用場景不同而己

微服務具體有哪些坑

服務劃分過細，服務間關係複雜

服務劃分過細，單個服務的複雜度確實下降了，但整個系統的複雜度卻上升了，因為微服務將系統內的複雜度轉移為系統間的複雜度了，理論上，n個服務的複雜度是n*(n-1)/2整個系統的複雜度是隨著微服務數量的增加呈指數級增加的
在這裡插入圖片描述

服務數量太多，團隊效率急劇下降

微服務的「微」字，本身就是一個陷阱，很多團隊看到「微」字後，就想到必須將服務拆分得很細，有的團隊人員規模是5~6個人，然而卻拆分出30多個微服務，平均每個人要維護 5 個以上的微服務，這樣做給工作效率帶來了明顯的影響，一個簡單的需求開發就需要涉及多個微服務，光是微服務之間的介面就有6～7個，無論設計、開發，還是測試、部署，都需要工程師不停地在不同的服務間切換

  • 開發工程師要設計多個介面，開啟多個工程，偵錯時要部署多個程式，提測時打多個包
  • 測試工程師要部署多個環境，準備多個微服務的資料，測試多個介面
  • 運維工程師每次上線都要操作多個微服務，並且微服務之間可能還有依賴關係

呼叫鏈太長，效能下降

由於微服務之間都是通過HTTP或RPC呼叫的，每次呼叫必須經過網路。 一般線上的業務介面之間的呼叫，平均響應時間大約為50ms ，如果使用者的一起請求需要經過6次微服務呼叫，則效能消耗就是300ms ，這在很多高效能業務場景下是難以滿足需求的。 為了支撐業務請求，可能需要大幅增加硬體，這就導致了硬體成本的大幅上升

呼叫鏈太長，問題定位困難

系統拆分為微服務後，一次使用者請求需要多個微服務協同處理，任意微服務的故障都將導致整個業務失敗。然而由於微服務數量較多，且故障存在擴散現象，快速定位到底是哪個微服務故障是一件複雜的事情。樣例如下圖所示：
在這裡插入圖片描述
如果多個微服務同時發生不同型別的故障，則定位故障更加複雜，如下圖所示：
在這裡插入圖片描述

沒有自動化支撐，無法快速交付

如果沒有相應的自動化系統進行支撐，都是靠人工去操作，那麼微服務不但達不到快速交付的目的，甚至還不如一個大而全的系統效率高，例如：

  • 沒有自動化測試支撐，每次測試時需要測試大量介面
  • 沒有自動化部署支撐，每次部署6～7個服務，幾十臺機器，運維人員敲shell命令逐臺部署，手都要敲麻
  • 沒有自動化監控，每次故障定位都需要人工查幾十臺機器幾百個微服務的各種狀態和各種紀錄檔檔案

沒有服務治理，微服務數量多了後管理混亂

信奉微服務理念的設計人員總是強調微服務的lightweight特性，並舉出ESB的反例來證明微服務的優越之處 。但具體實踐後就會發現，隨著微服務種類和數量越來越多，如果沒有服務治理系統進行支撐，微服務提倡的lightweight就會變成問題

  • 服務路由：假設某個微服務有60個節點，部署在20臺機器上，那麼其他依賴的微服務如何知道這個部署情況？
  • 服務故障隔離：假設上述例子中的60個節點有5個節點發生故障了，依賴的微服務如何處理這種情況？
  • 服務註冊和發現：同樣是上述的例子，現在我們決定從60個節點擴容到80個節點， 或者將60個節點縮減為40個節點，新增或減少的節點如何讓依賴的服務知道？

微服務最佳實踐

服務粒度

微服務拆分應基於團隊規模進行拆分，通常一個微服務三個人負責開發（三個火槍手原則）,當微服務穩定後一人維護即可

拆分方法

基於業務邏輯拆分

這是最常見的一種拆分方式，將系統中的業務模組按照職責範圍識別出來，每個單獨的業務模組拆分為一個獨立的服務。具體拆分的時候，首先根據「 三個火槍手」的原則計算一下大概的服務數量範圍，然後確定合適的「職責範圍」，否則就可能出現劃分過細的情況

基於可延伸拆分

將系統中的業務模組按照穩定性進行排序，將己經成熟和改動不大的服務拆分為穩定服務，將經常變化和法代的服務拆分為變動服務。穩定的服務粒度可以粗一些，即使邏輯上沒有強關聯的服務，也可以放在同一個子系統中，例如，將「紀錄檔服務」和「升級服務」放在同一個子系統中；不穩定的服務粒度可以細一些，但也不要太細，始終記住要控制服務的總數量，這樣拆分主要是為了提升專案快速迭代的效率，避免在開發的時候，不小心影響己有的成熟功能導致線上問題

基於可靠性拆分

將系統中的業務模組按照優先順序排序，將可靠性要求高的核心服務和可靠性要求低的非核心服務拆分開來，然後重點保證核心服務的高可用。具體拆分的時候，核心服務可以是一個， 也可以是多個，只要最終的服務數量滿足「三個火搶手」的原則就可以

這樣拆分帶來如下幾個好處：

  • 避免非核心服務故障影響核心服務，例如，紀錄檔上報一般都屬於非核心服務，但是在某些場景下可能有大量的紀錄檔上報，如 果系統沒有拆分，那麼紀錄檔上報可能導致核心服務故障，拆分後即使紀錄檔上報有問題， 也不會影響核心服務
  • 核心服務高可用方案可以更簡單，核心服務的功能邏輯更加簡單，儲存的資料可能更少，用到的元件也會更少，設計高可 用方案大部分情況下要比不還分簡單得多
  • 能夠降低高可用成本 ，將核心服務拆分出來後，核心服務佔用的機器、頻寬等資源比不拆分要少得多，因此， 只針對核心服務做高可用方案，機器、頻寬等成本比不拆分要節省較多

基於效能拆分

基於效能拆分和基於可靠性拆分類似，將效能要求高或效能壓力大的模組拆分出來，避免效能壓力大的服務影響其他服務，常見的拆分方式和具體的效能瓶頸有關，可以拆分 Web 服務、資料庫、快取等，例如，電商的搶購，效能壓力最大的是入口的排隊功能，可以將排隊功能獨 立為一個服務

以上幾種拆分方式不是隻能選一個 ，而是可以根據實際情況自由排列組合。例如，可以基於可靠性拆分出服務A，基於效能拆分出服務B，基於可延伸拆分出C/D/F三個服務，加上原有的服務X，總共最後拆分出6個服務（A/B/C/D/F/X）

基礎設施

大部分人主要關注的是微服務的「 small 」和 「 lightweight 」特性， 但實際上真正決定微服務成敗的，恰恰是「 automated 」，因為服務粒度即使劃分不合理，實際落地後如果團隊遇到麻煩，自然會想到拆服務或合服務。如果「 automated 」 相關的基礎設施不健全，那補起來可就不是一天兩天的事情

微服務基礎設施如下圖所示：
在這裡插入圖片描述
感覺比ESB還要複雜，確實如此，微服務並不是很多人認為的那樣又簡單又輕量級。要做好微服務，這些基礎設施都是必不可少的，微服務並沒有減少複雜度，而只是將複雜度從ESB轉移到了基礎設施，例如「服務發現」「服務路由」等其實都是ESB的功能，只是在微服務中剝離出來成 了獨立的基礎系統

每項微服務基礎設施都是一個平臺、一個系統、一個解決方案，如果要自己實現， 其過程和做業務系統類似，都需要經過需求分析、架構設計、開發、測試、部署上線等步驟

自動化測試

微服務將原本大一統的系統拆分為多個獨立執行的「微」服務，微服務之間的介面數量大大增加， 並且微服務提倡快速交付，版本週期短，版本更新頻繁，如果每次更新都靠人工迴歸整個系統，則工作量大，效率低下，達不到「快速交付」的目的，因此必須通過自動化測試系 統來完成絕大部分測試迴歸的工作

自動化測試涵蓋的範圍包括程式碼級的單元測試、單個系統級的整合測試、系統間的介面測 試，理想情況是每類測試都自動化，如果因為團隊規模和人力的原因無法全面覆蓋，至少要做到介面測試自動化

自動化部署

相比大一統的系統，微服務需要部署的節點增加了幾倍甚至十幾倍，微服務部署的頻率也會大幅提升，綜合計算下來，微服務部署的次數是大一統系統部署次數的幾十倍。這麼大量的部署操作，如果繼續採用 人工手工處理，需要投入大量的人力，且容易出錯，因此需要自動化部署的系統來完成部署操作

自動化部署系統包括版本管理、資源管理（例如，機器管理、虛擬機器器管理）、部署操作、回退操作等功能

設定中心

微服務的節點數量非常多，通過人工登入每臺機器手工修改，效率低，容易出錯。特別是在部署或排障時，需要快速增刪改查設定，人工操作的方式顯然是不行的。除此以外， 有的執行期設定需要動態修改並且所有節點即時生效，人工操作是無法做到的 。綜合上述的分析，微服務需要一個統一的設定中心來管理所有微服務節點的設定

設定中心包括設定版本管理（例如，同樣的微服務，有10個節點是給移動使用者服務的，有20個節點給聯通使用者服務的，設定項都一樣， 設定值不一樣）、增刪改查設定 、節點管理、設定同步、設定推播等功能 。

介面框架

微服務提倡輕量級的通訊方式， 一般採用 HTTP/REST 或 RPC 方式統一介面協定。但在實踐過程中 ，光統一介面協定還不夠，還需要統一介面傳遞的資料格式
例如，我們需要指定介面協定為HTTP/REST，但這還不夠，我們還需要指定HTTP/REST的資料格式採用JSON ，並且JSON的資料都遵循如下規範

{
	"requestId":10086,
	"time":"2017-01-01 00:00:00",
	"caller":"tencent",
	"api":"get_money",
	"param":{
		"userId":15901281919	
	},
	"sign":"314159265358979323846aefaegh"
}

如果我們只是簡單指定了HTTP/REST協定，而不指定JSON和JSON的資料規範，那麼就會出現這樣混亂的情況：有的微服務採用XML，有的採用JSON， 有的採用鍵值對，即使同樣都是JSON, JSON 資料格式也不一樣。這樣每個微服務都要適配幾套甚至幾十套介面協定，相當於把曾經由 ESB 做的事情轉交給微服務自己做了，這樣做的效率顯然是無法接受的。因此我們需要統一介面框架

介面框架不是一個可執行的系統，一般以庫或包的形式提供給所有微服務呼叫。例如，針對上面的JSON樣例，可以由某個基礎技術團隊提供多種不同語言的解析包(Java包、 Python包、 C庫等)

API 閘道器

系統拆分為微服務後，內部的微服務之間是互聯互通的，相互之間的存取都是對等的,如果外部系統想呼叫系統的某個功能，也採取對等的方式，則外部系統會非常「頭大,因為在外部系統看來， 它不需要也沒辦法理解這麼多微服務的職責分工和邊界 ，它只會關注它需要的能力，而不會關注這個能力應該由哪個微服務提供
除此之外，外部系統存取系統還涉及安全和許可權相關的限制，如果外部系統直接存取某個微服務， 則意味著每個微服務都要自己實現安全和許可權的功能，這樣做不但工作量大，而且都是重複工作

綜合上述分析，微服務需要一個統一的 API 閘道器，負責外部系統的存取操作,API閘道器是外部系統存取的介面，所有的外部系統接入系統都需要通過API閘道器,主要包括接入鑑權（是否允許接入）、許可權控制（可以存取哪些功能）、傳輸加密、請求路由、流量控制等功能

服務發現

微服務種類和數量很多，如果這些資訊全部通過手工設定的方式寫入各個微服務節點，首先設定工作量很大，組態檔可能要配幾百上千行，幾十個節點加起來後設定項就是幾萬幾十萬行了，人工維護這麼大數量的設定項是一項災難。其次是微服務節點經常變化，可能是由於擴容導致節點增加，也可能是故障處理時隔離掉一部分節點， 還可能是採用灰度升級，先將一部分節點升級到新版本，然後讓新老版本同時執行：不管哪種情況，我們都希望節點的變化能夠及時同步到所有其他依賴的微服務 。如果採用手工設定，是不可能做到實時更改生效的 。因此，我們需要一套服務發現的系統來支撐微服務的自動註冊和發現

服務發現主要有兩種實現方式： 自理式和代理式。

【自理式】

自理式結構如下圖
在這裡插入圖片描述
自理式結構就是指每個微服務自己完成服務發現。例如，圖中SERVICE INSTANCE A訪 問 SERVICE REGISTRY獲取服務註冊資訊，然後直接存取SERVICE INSTANCE B
自理式服務發現實現比較簡單，因為這部分的功能一般通過統一的程式庫或程式包提供給各個微服務呼叫，而不會每個微服務都自己來重複實現一遍;並且由於每個微服務都承擔了服務發現的功能，存取壓力分散到了各個微服務節點，效能和可用性上不存在明顯的壓力和風險

【代理式】

代理式結構如下圖所示 。
在這裡插入圖片描述
代理式結構就是指微服務之間有一個負載均衡系統（圖中的LOAD BALANCER節點），由負載均衡系統來完成微服務之間的服務發現

代理式的方式看起來更加清晰，微服務本身的實現也簡單了很多，但實際上這個方案風險較大

  • 第一個風險是可用性風險，一旦LOAD BALANCER系統故障，就會影響所有微服務之間的呼叫
  • 第二個風險是效能風險，所有的微服務之間的呼叫流量都要經過LOAD BALANCER系統，效能壓力會隨著微服務數量和流量增加而不斷增加，最後成為效能瓶頸,因此LOAD BALANCER系統需要設計成叢集的模式，但LOAD BALANCER叢集的實現本身又增加了複雜性

不管是自理式還是代理式，服務發現的核心功能就是服務登入檔，登入檔記錄了所有的服務節點的設定和狀態，每個微服務啟動後都需要將自己的資訊註冊到服務登入檔，然後由微服務或 LOAD BALANCER 系統到服務登入檔查詢可用服務

服務路由

有了服務發現後，微服務之間能夠方便地獲取相關設定資訊，但具體進行某次呼叫請求時，我們還需要從所有符合條件的可用微服務節點中挑選出一個具體的節點發起請求，這就是服務路由需要完成的能

服務路由和服務發現緊密相關，服務路由一般不會設計成一個獨立執行的系統，通常情況下是和服務發現放在一起實現的。對於自理式服務發現，服務路由是微服務內部實現的；對於代理式服務發現，服務路由是由LOAD BALANCER系統實現的

無論放在哪裡實現，服務路由核心的功能就是路由演演算法。常見的路由演演算法有 ： 隨機路由、輪詢路由、最小壓力路由、最小 連線數路由等演演算法。

服務容錯

系統拆分為微服務後，單個微服務故障的概率變小，故障影響範圍也減少，但是微服務的節點數量大大增加。從整體上來看，系統中某個微服務出故障的概率會大大增加。前面我們分析微服務陷阱時提到微服務具有故障擴散的特點，如果不及時處理故障，故障擴散開來就會導 致看起來系統中很多服務節點都故障了
因此需要微服務能夠自動應對這種出錯場景，及時進行處理。否則如果節點一故障就需要人工處理，投入人力大，處理速度慢。而一旦處理速度慢，則故障就很快擴散，所以我們需要服務容錯的能力

常見的服務容錯包括請求重試、流控和服務隔離

【請求重試】

請求重放和請求重試類似，不同點在於：請求重試是向同一個微服務節點重新傳送請求；請求重放是向不同的微服務節點重新傳送請求，通常情況下，請求重試由微服務節點或代理節點實現

【流控】

當出現異常情況，導致某個或某類微服務的請求數量突增或爆發，由於系統容量限制 ，無法快速應對突發容量，導致整個微服務響應都變慢甚至完全癱瘓，此時需要將一部分流量拒絕，從而保證大部分流量的請求正常。這就是流控需要實現的功能 。
通常情況下，流控由各個微服務節點自己實現，可以將流控策略包裝成公共庫提供給各個 微服務使用，減少重複實現。
【服務隔離】
由於微服務幾乎都是叢集部署，因此當某個微服務節點故障時，最快最簡單的處理方式就是直接將當前故障節點下線隔離，避免故障進行擴散。這就是服務隔離需要實現的功能。 通常情況下，服務隔離分為主動隔離、被動隔離和手動隔離

  • 主動隔離指微服務節點自己判斷自己異常後，主動從服務發現系統中登出
  • 被動隔離指服務發現系統根據設定的規則（連線狀態、響應時間、錯誤率等）判斷微服務節點故障後，將其從服務發現系統中登出
  • 手動隔離指人工判斷系統故障後，通過手工操作將其從服務發現系統中登出

主動隔離和被動隔離響應及時，能夠快速隔離故障，缺點就是實現起來比較複雜，需要根據線上的各種複雜情況制定規則；手動隔離雖然響應沒有那麼及時，但實現起來很簡單。實際應用場景中，一般都是結合起來使用：實現基於簡單策略的主動隔離和被動隔離，更復雜的情況由人工去隔離

服務監控

系統拆分為微服務後，節點數量大大增加，導致需要監控的機器、網路、程序、介面呼叫數等監控物件的數量大大增加；同時，一旦發生故障，我們需要快速根據各類資訊來定位故障 。

服務監控作用
  • 實時蒐集資訊並進行分析，避免故障後再來分析，減少了處理時間
  • 服務監控可以在實時分析的基礎上進行預瞥 ，在問題萌芽的階段發覺並預警 ，降低了問題影響的範圍和時間

通常情況下，服務監控需要蒐集並分析大量的資料，因此建議做成獨立的系統，而不要整合到服務發現、 API 閘道器等系統中

服務跟蹤

服務監控可以做到微服務節點級的監控和資訊收集，但如果我們需要跟蹤某一個請求在微服務中的完整路徑，服務監控是難以實現的。因為如果每個服務的完整請求鏈資訊都實時傳送給服務監控系統，資料量會大到無法處理

服務監控和服務跟蹤的區別可以簡單概括為宏觀和微觀的區別 。 例如，A服務通過HTTP協定請求B服務 10次，B通過HTTP返回JSON物件，服務監控會記錄請求次數、響應時間平均值、響應時間最高值、錯誤碼分佈這些資訊；而服務跟蹤會記錄其中某次請求的發起時間、響應時間、響應錯誤碼、請求引數、返回的 JSON 物件等資訊

目前無論分散式跟蹤，還是微服務的服務跟蹤，絕大部分請求跟蹤的實現技術都基於 Google的 Dapper 論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 》

服務跟蹤關鍵技術

  • 標註點
    標註點又叫植入點或埋點，通過在應用程式或中介軟體中明確定義一個全域性的標註(annotation），它可以是一個特殊的ID ，通過這個ID連線每一條記錄和發起者的請求，然後跟蹤系統再根據這個ID將整個業務請求鏈串聯起來
    由於全域性標註點需要在所有經過的服務節點中進行處理，因此需要程式碼植入。在生產環境中，如果所有的應用程式都使用相同的執行緒模型、控制流和 RPC 系統，則可以把程式碼植入限制在一個很小的通用元件庫中，從而達到監測系統應用對開發人員的透明

  • 跟蹤樹和span
    在這裡插入圖片描述
    分散式跟蹤通過跟蹤樹來表示一個完整的跟蹤流程，其中某個服務從接到請求到返回響應這個時間跨度範圍被稱為span，一個span內，服務本身又會發起多次到其他服務的呼叫
    跟蹤樹結構中，樹節點是整個架構的基本單元，而每一個節點又是對span的參照。節點之間的連線表示的span和它的父span的直接關係。通過簡單的parentld和spanId就可以有序地把所有的關係串聯起來達到記錄業務流的作用

服務跟蹤目的
  • 取樣跟蹤
    根據一定的概率對請求進行取樣跟蹤，然後基於取樣資料進行分析（例如，谷歌的 Dapper 系統），可以被用於發現系統問題，但它更通常用於探查效能不足，以及提高全面大規模的工作負載下的系統行為的理解。這種方式主要的優勢是無須跟蹤所有的請求，效能消耗和對系統的壓力會小得多
  • 染色跟蹤
    線上環境有時會出比較詭異的問題，即同樣功能或業務，大多數使用者都沒有問題，很少一部分使用者會出錯。單純從程式碼邏輯或系統紀錄檔來看是找不到問題原因的，此時需要針對單個使用者的特定請求進行全鏈路跟蹤，這就是通常所說的染色跟蹤
    微服務中的染色跟蹤原理，我 們將想要跟蹤的使用者「染色」（其實就是在請求入口處打上標記），每個微服務看到有標記的請求就進行跟蹤，最後彙總跟蹤資訊就可以看出整個業務請求的所有細節

服務安全

系統拆分為微服務後，資料分散在各個微服務節點上。從系統連線的角度來說，任意微服務都可以存取所有其他微服務節點；但從業務的角度來說 ，部分敏感資料或操作只能部分微服務可以存取，而不是所有的微服務都可以存取。因此需要設計服務安全機制來保證業務和資料的安全性

例如，假設我們有一個「使用者資訊管理」微服務，其中包含所有使用者的基本資訊（姓名、 性別、職位、身份證、手機號碼等〉 ， 「使用者資訊管理」對外提供「增刪改查」使用者資訊的介面。 針對「使用者資訊管理」微服務，我們需要設計如下安全相關的策略：

  • 所有其他微服務都可以讀取使用者的姓名、性別、職位資訊；
  • 部分微服務可以讀取使用者的身份證和手機號碼資訊 ；
  • 只有「人力資源管理」微服務可以修改和刪除使用者資訊。
服務安全主要分為三部分
  • 接入安全:接入安全指只有經過允許，某個微服務才能存取另外一個微服務，否則被存取的微服務 會直接拒絕服務
  • 資料安全:資料安全指某些資料相關的操作只 允許授權的微服務進行存取， 否則被存取的微服務會 拒絕資料操作
  • 傳輸安全:傳輸安全指某些敏感資料在傳輸過程中需要進行防竊取 、防篡改處理 ，以保證資料的真 實性和有效性

通常情況下，服務安全可以整合到設定中心繫統中進行實現，即設定中心設定微服務的接入安全策略和資料安全策略，微服務節點從設定中心獲取這些設定資訊，然後在處理具體的微服務呼叫請求時根據安全策略進行處理 。 由於這些策略是通用的， 一般會把策略封裝成通用的庫提供給各個微服務呼叫。

基本架構如下圖所示:
在這裡插入圖片描述