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

微服務與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 系統），可以被用于發現系統問題，但它更通常用于探查性能不足，以及提高全面大規模的作業負載下的系統行為的理解，這種方式主要的優勢是無須跟蹤所有的請求，性能消耗和對系統的壓力會小得多
• 染色跟蹤
  線上環境有時會出比較詭異的問題，即同樣功能或業務，大多數用戶都沒有問題，很少一部分用戶會出錯，單純從代碼邏輯或系統日志來看是找不到問題原因的，此時需要針對單個用戶的特定請求進行全鏈路跟蹤，這就是通常所說的染色跟蹤
  微服務中的染色跟蹤原理，我 們將想要跟蹤的用戶“染色”（其實就是在請求入口處打上標記），每個微服務看到有標記的請求就進行跟蹤，最后匯總跟蹤資訊就可以看出整個業務請求的所有細節

服務安全

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

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

• 所有其他微服務都可以讀取用戶的姓名、性別、職位資訊；
• 部分微服務可以讀取用戶的身份證和手機號碼資訊 ；
• 只有“人力資源管理”微服務可以修改和洗掉用戶資訊，

服務安全主要分為三部分

• 接入安全:接入安全指只有經過允許，某個微服務才能訪問另外一個微服務，否則被訪問的微服務 會直接拒絕服務
• 資料安全:資料安全指某些資料相關的操作只 允許授權的微服務進行訪問， 否則被訪問的微服務會 拒絕資料操作
• 傳輸安全:傳輸安全指某些敏感資料在傳輸程序中需要進行防竊取 、防篡改處理 ，以保證資料的真 實性和有效性

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

基本架構如下圖所示: