這篇文章主要目的是面向初接觸微服務的朋友簡單介紹微服務基礎建設所需要的各個模塊以及緣由。
起點
首先广匙，我們得有一個“服務”。根據(jù)定義恼策，我們可以把每個服務實例都視作一個黑盒鸦致。這個盒子有著明確的輸入點和輸出點潮剪，并且（理想情況下）僅通過這些輸入和輸出點和外界產生關聯(lián)。每個服務實例會擁有專屬的網絡地址分唾、獨立的計算資源抗碰，并且獨立部署≌狼牵客戶端通過訪問服務實例的地址來調用服務 API弧蝇。不同服務也可以相互調用。
配置管理器：統(tǒng)一管理配置
在微服務體系中折砸，每個服務都獨立部署和運行看疗，團隊可以根據(jù)需要自行選擇增加和減少計算資源。一個服務可能會跑多個實例睦授，每個服務實例都會需要做配置两芳。為了方便統(tǒng)一調整配置，我們可以把配置中心化去枷，每個服務實例都去找配置管理器（Configuration Manager）拿配置怖辆。當配置更新的時候，我們也可以讓服務實例再去拿新的配置删顶。
服務名冊：解耦主機地址
這也引出了一個問題：網絡地址（比如 IP）很容易因為擴容竖螃、維護而變動，調用者難以實時獲知可用的地址逗余。
鑒于此特咆，我們可以把網絡地址抽象成不容易變動的概念，比如給每個服務一個固定的名字猎荠〖崛酰互聯(lián)網使用 DNS 來解決這個問題，對應到微服務基建里面就是服務名冊（Service Registry）关摇。
每個服務實例在運行期間荒叶，都會以心跳的形式向服務名冊發(fā)送注冊信息，包括服務的 ID 输虱、訪問地址以及健康狀況些楣。這樣，需要訪問服務的時候宪睹，客戶端就可以先問服務名冊拿可用的實例地址愁茁，然后再訪問實例來調用服務。除了更好地定位實例地址亭病，服務名冊還可以在某些實例下線鹅很、維護或升級的時候把其臨時從名冊中去掉，讓服務不斷線罪帖。
服務之間的調用也是如此促煮，先找名冊拿網絡地址邮屁，再進行調用。
API 網關：入口和路由
找名冊要地址菠齿，然后調用服務 API佑吝，這些是每個客戶端都會去做的瑣事，我們完全可以把這些事情抽象绳匀、集中芋忿，把服務的 API 整合到一個大的中心點，然后把要地址和調用服務 API 這樣的細節(jié)封裝起來疾棵，所有客戶端都只跟這個中心點對話戈钢，不再直接訪問單個服務。
從結構上看陋桂，這個中心點把整個架構劃分成了內外兩部分逆趣，內部是所有的服務，客戶端則在外部嗜历，中心點站在中間宣渗。它作為內外的唯一通道，被順理成章地命名作“API 網關”（API Gateway）梨州，有時候也被稱做“邊緣服務”（Edge Service）痕囱。
API 網關作為唯一出入口，又占據(jù)了最前沿的有利位置暴匠，所以有時還會承載別的公共功能鞍恢，比如我們馬上會提到的鑒權。
鑒權服務：身份和權限問題
順著這個架構繼續(xù)開發(fā)每窖，我們會遇到新的問題：不方便的鑒權帮掉。
鑒權（Auth）包括了兩個部分：身份認證（Authentication）和權限驗證（Authorization）。身份認證關心的是“你是誰”窒典，權限驗證關心的是“你能不能做某件事”蟆炊。
身份和權限都是高度中心化的概念。
對于一個系統(tǒng)來說瀑志，用戶的身份必須是統(tǒng)一的涩搓。不能說這個用戶在做這個事情的時候是張三，做那個事情的時候是李四劈猪。此外昧甘，用戶的認證狀態(tài)也應該是統(tǒng)一的。不能說用戶訪問這個服務的時候是已登錄認證战得，訪問另一個服務時又是未登錄狀態(tài)充边。所以，只能有一個身份認證方常侦。
權限稍微復雜一點痛黎。和身份不同予弧，權限通常分成兩種類別：功能權限和數(shù)據(jù)權限刮吧。這樣的劃分對應了現(xiàn)實世界中常見的權限模式：你的角色決定了你的職能湖饱，而職能范圍通常由附加條件來限制。比如杀捻，你是一個法官井厌，對案件有裁決權，但是你是 A 區(qū)的法官致讥，只能判 A 區(qū)的案子仅仆。再比如，某個快餐門店的經理有權看員工的詳細資料垢袱，但是只能看自己門店的員工資料墓拜。
兩種權限都由全局的規(guī)則來確定，而不掌握在執(zhí)行部門请契。比如咳榜，誰來判案，取決于法律爽锥，而不取決于法院涌韩。誰能查看誰的資料，也不由資料保管部門決定氯夷，而由規(guī)章制度決定臣樱。
在現(xiàn)實的情況中，組織可能會有專門的審核部門來驗證權限腮考，但對那些不是特別敏感的權限雇毫，企業(yè)會讓各個部門自行驗證。不過不管誰來執(zhí)行驗證踩蔚，都必須拿著同一份規(guī)章制度棚放，不能各說各話。這份制度必須由中心機構來統(tǒng)一制定寂纪、維護席吴。也就是說，權限的管理也應該中心化捞蛋。
明確鑒權中心化之后孝冒，我們就可以開發(fā)一個公用的鑒權服務，執(zhí)行身份認證和權限驗證拟杉。下一個問題是：誰來發(fā)起鑒權庄涡？
所有服務的調用都要求調用者明確自己的身份，所以自然身份認證越靠前越好搬设。作為出入口的 API 網關自然是發(fā)起身份認證的不二之選穴店。權限驗證則稍微復雜撕捍，完全值得另起一文詳述。此處我們暫時假定權限驗證也由 API 網關來發(fā)起泣洞。
消息中介：異步和通知
開發(fā)繼續(xù)進行忧风，一切風平浪靜，技術上暫時沒有什么問題球凰。不過狮腿，業(yè)務上有一個問題需要解決。
比如呕诉，我們做一個在線商城缘厢，要求在訂單成功創(chuàng)建的一刻，倉庫就要啟動備貨和發(fā)貨的流程甩挫。問題是贴硫，訂單和倉儲是兩個服務，不同團隊在負責伊者，而且從關注點來說英遭，訂單服務并不關心倉儲相關的問題，所以訂單服務不可能在創(chuàng)建訂單的時候去主動通知倉儲服務删壮。倉儲服務只能定時輪詢訂單服務贪绘，看看有沒有新的訂單。這不僅麻煩央碟，而且實時性不夠税灌。
仔細想想，我們會發(fā)現(xiàn)這種需求很常見亿虽，信息的產生者并不知道（也不關心）誰會對信息產生興趣菱涤。比如我們可能會有一個監(jiān)控服務需要實時展示產品銷量，有一個 BI 服務需要獲取客戶購買產品的信息來做分析洛勉，等等粘秆。既然這是一個常見需求，我們不妨把它模式化收毫，形成一個機制：信息產生者把通知發(fā)出來攻走，收到通知的人再確定是否需要采取行動。
這就意味著我們需要再引入一個中心化的公共服務：消息中介（Message Broker）此再。當某個事件發(fā)生的時候（比如用戶激活成功昔搂、訂單創(chuàng)建成功），服務可以朝消息隊列發(fā)一條消息输拇。而其他服務可以訂閱這些消息摘符，并針對這些消息做出反應。
比如，倉儲服務可以訂閱訂單創(chuàng)建成功的消息逛裤。這樣瘩绒，訂單成功創(chuàng)建后，訂單服務將這個消息發(fā)到消息中介带族，消息中介通知倉儲服務锁荔，倉儲服務一看，就問訂單服務要新的訂單信息炉菲，最后堕战，啟動出庫流程。
消息中介除了能廣播事件之外拍霜，還能做異步調用。把同步的調用轉化成異步的回調薪介。針對調用時間長和不要求實時結果的調用祠饺，可以增加性能，提升體驗汁政。
前置后端：優(yōu)化前端開發(fā)
走到這里道偷，其實體系已經比較完備。現(xiàn)在的問題是记劈，如何讓微服務基建結構和研發(fā)團隊常見的結構更好地對應起來勺鸦。這要求我們從康威定律的角度來看待整個基建的設計。
在圍繞用戶和價值的軟件研發(fā)流程中目木，我們常用用戶歷程和用戶故事來捕捉和跟蹤價值的實現(xiàn)换途。一個用戶故事通常會包含一個有明確邊界、明確驗收標準和明確價值的業(yè)務步驟刽射。
問題在于军拟，支撐一個故事有前后兩端的研發(fā)工作，二者是不同步的誓禁。前端由業(yè)務流程和設計來驅動懈息，希望按順序產出；后端則由業(yè)務資源和建模來驅動摹恰，希望按模塊來產出辫继。
比如說，前端常常會因為設計的原因調整自己需要的字段俗慈，而后端從建模的角度并沒有這個需要姑宽，也沒有動力頻繁地去跟隨前端的調整，使得前端不得不在不穩(wěn)定的網絡條件下傳輸多余的信息姜盈，占用了寶貴的網絡帶寬低千。
此外，前端呈現(xiàn)某個業(yè)務步驟的時候，有兩種信息不屬于當前必備信息示血，但常常需要和必要信息一起展示棋傍。一種是狀態(tài)信息，比如當前的登錄狀態(tài)和用戶名难审，短消息的數(shù)量等等瘫拣。一種是垂直相關的信息，比如在展示文章的時候順便展示一下相關的文章告喊。
這就要求前端在調用主服務的同時還要再調用多個不同的服務麸拄。且不說這些服務有可能會有調用超時、出錯的可能黔姜，僅僅是多出來一堆異步請求拢切，就已經足夠讓前端效率降低一大截了。
在微服務體系下秆吵，這些問題更加嚴重淮椰，因為現(xiàn)在不僅僅是前后端的差別，不同服務還由不同團隊負責纳寂。這些團隊的訴求和日程不一主穗，很難做到前端所需要的快速響應。
這些問題和麻煩可能會催生一個“緩沖帶”毙芜，比如后端出專人來負責對接前端的需要忽媒，或者前端派駐一個人到后端來談需求。按康威定律腋粥，這種溝通體系晦雨，久而久之，很容易以軟件的形式沉淀下來灯抛，形成一個專屬的中間層金赦。
要調和前后端的不同步是不可能的，而這種中間層是自然催生的解決方案对嚼，可以保留夹抗。新的問題是，它的職責是什么纵竖？應該把它放在哪漠烧？應該由誰來維護？
分析下來靡砌，其責任有二已脓。第一是解耦前后端的工作，降低相互的影響通殃。前端需要的東西可以寫在中間層里度液，讓它頻繁變化也沒有關系厕宗。后端如果還沒有準備好，前端也可以在這一層模擬假的數(shù)據(jù)堕担，不至于被阻塞已慢。第二則是提升前端的運行效率。前端可以把所需要的多個服務的東西統(tǒng)一匯總霹购，一次拿完佑惠，免得發(fā)多個請求。
放置的位置則在 API 網關之內齐疙，讓它可以享有 API 網關所帶來的好處和保護膜楷。
最后是維護問題。按照“誰主張贞奋，誰舉證”的原則赌厅，既然有了這個中間層，好處讓前端得了忆矛，那么察蹲，理論上應該由前端來維護。
這樣催训，一個主要為前端服務的中間層就定義好了。不同類型的前端（桌面宗收、移動）可能會有不同的需要漫拭，為了避免中間層的碎片化，我們可以讓各個中間層都特定的前端類型緊密耦合混稽，比如桌面專用采驻、移動專用。如此匈勋，每個中間層都像是某類型前端的專享后端礼旅，所以“前置后端”（Backend-for-Frontend，簡稱 BFF）也因此得名洽洁。
回路熔斷器：提高容錯度
現(xiàn)在痘系，調試也方便了，我們又繼續(xù)開發(fā)饿自。一開始沒有什么問題汰翠，但部署到預生產環(huán)境的時候，又一個問題出現(xiàn)了：整個體系的容錯度很低昭雌。一個小錯誤容易被層層傳遞和放大复唤，導致整個體系的崩潰。
我們都知道烛卧，編程最麻煩的就是遠程調用佛纫。本地調用大部分時候結果是“成功”或“失敗”，但遠程調用則很可能是“無響應”〕视睿“無響應”有可能是正常的好爬，對方可能稍后會給你結果，也可能是因為對方已經死了攒盈，沒法給你響應抵拘。最壞的結果，就是門口擠滿了人型豁，大家都在等你給結果僵蛛，而你也在等別人給結果，資源全部占用來等迎变，什么也做不了充尉。
不過，遠程調用是無法避免的衣形。在微服務體系中驼侠，這個問題被進一步放大。這是因為微服務的模塊化以服務為單位谆吴，而每個服務獨立部署和運維倒源，使得服務之間的調用成了家常便飯。
在這種嚴峻的情況下句狼，我們必須從架構上盡量提高整個服務體系的容錯度笋熬，讓個別服務的問題不至于影響到全局。
具體的做法腻菇，則是給遠程調用加一個熔斷閾值檢查胳螟，當調用超時次數(shù)超過閾值時，就不再調用筹吐，直接返回錯誤糖耸。過一段時間之后，再把閾值恢復丘薛，嘗試繼續(xù)調用嘉竟，重復前面的過程。這個機制就是回路熔斷榔袋，而這個工具則是回路熔斷器（Circuit Breaker）周拐。
除了隔離已經出錯的服務實例，熔斷器還有一個重要的功能是提供備用方案凰兑。雖然我們把所有業(yè)務都拆成了服務示惊，但服務有高低貴賤之分辩涝。有一些服務屬于關鍵服務誉裆，一旦出問題，則整個流程無法繼續(xù)滩报，有一些則屬于分支服務，即便錯了播急，也不會影響大局脓钾。
比如說，購買商品的時候桩警，常常會根據(jù)用戶的習慣和當前正在購買的東西做一些推薦可训。負責推薦的服務出問題的話，大不了就不推薦了捶枢，不應該影響用戶正常的購買流程握截。同理，如果是在線點餐的地址定位服務出問題了烂叔，我們也應該允許用戶手動選擇餐廳進行點餐——體驗雖然不佳谨胞，但至少正常的流程仍然可以走完∷饧Γ基于這個考慮胯努，熔斷器應該為非必要的服務調用提供備用方案，盡量保證核心流程的順暢逢防。
有了回路熔斷器叶沛，遠程調用出錯的問題就從一定程度上緩解了。結合回路熔斷器和對熔斷閾值變化的監(jiān)控忘朝，開發(fā)者可以更容易地發(fā)現(xiàn)問題恬汁，并及時采取行動。
負載均衡器：提升服務彈性
要正式上線辜伟，我們還必須做好負載均衡（Load Balancing，下簡稱 LB）脊另，提升整個服務的彈性导狡。要做負載均衡，從理論上有兩種方式：
客戶端負載均衡（Client-Side LB）：由客戶端來決定如何分散請求偎痛。 中間方負載均衡（Mid-Tier LB）：由 DNS旱捧、網關等中間方來決定如何分散請求。
現(xiàn)在踩麦，服務名冊中已經有了服務及其對應的實例地址列表枚赡，所以客戶端的負載均衡最簡便的方式就是把地址拉下來，然后依次或者隨機選擇可用的地址谓谦。中間方的負載均衡則選擇面較多贫橙，從最外層的 DNS 到網關都可以不同程度地去按需要去做。
擴展基建
現(xiàn)在反粥，微服務基建基本完成了卢肃。如果有需要疲迂，我們可以對這個基建進行擴展。在做擴展時莫湘，架構師應該注意區(qū)分哪些東西應該中心化尤蒿，哪些東西應該由服務自行決定。 比如說幅垮，在本文提到的基建之中腰池，（幾乎是）強制完全中心化的模塊有：
- 配置管理
- 服務名冊
- 消息隊列
其中，配置管理和服務名冊是所有服務都需要的基礎設施忙芒，必然需要統(tǒng)一示弓。消息隊列和日志收集都是為了跨服務的操作和追蹤，也必須中心化匕争。
半中心化的模塊則有：
- 路由
- 鑒權
路由和鑒權都必須統(tǒng)一避乏，我們前面討論過。不過甘桑，微服務可能會向外界暴露“自用”和“客用”等多套公共 API（比如快遞公司內部使用的物流 API 和開放給第三方使用的物流 API）拍皮，所以可能會有兩個 API 網關，對應會有兩套 API 目錄和兩套鑒權體系跑杭，所以铆帽，它們是“半中心化”。
這些都是中心化德谅、半中心化的選擇范例爹橱。每一次中心化的選擇都可能會讓整個架構變得死板，失去靈活性窄做，所以愧驱，我們在設計和擴展基建的時候應該特別注意這個問題。
除了中心化的選擇之外椭盏，架構發(fā)展的另一個關注點组砚，是讓業(yè)務保持“黑盒”。
我們把每個服務之間的關聯(lián)抽取了出來掏颊，也把權限的定義和驗證抽取了出來糟红，每個服務變得簡單而純粹，成了“純業(yè)務式服務”乌叶，等同于一個僅包含了業(yè)務規(guī)則的黑盒盆偿。這樣，不管服務和模塊再多准浴，也沒有影響事扭。業(yè)務的重用性也很高。
總而言之兄裂，搭建好了微服務的必要設施之后句旱，剩下的就要根據(jù)實際情況和項目經驗來繼續(xù)調整了阳藻。比如，我們可能會選擇把很多功能合并到一層谈撒，以避免過度分層所帶來的不必要的性能損失腥泥，或者對整個基建進行一些細節(jié)微調。只要把控好“中心-自理”和“業(yè)務-非業(yè)務”之間的關系啃匿，這個基礎設施就能健康地發(fā)展蛔外。
微服務基建總結
總結此文，微服務的基建應該包括如下一些組件（按請求流中的出場順序）：
- 配置管理：配置集中管理溯乒。
- API 網關：對外的 API 總目錄夹厌；API 依賴關系；發(fā)起鑒權裆悄。
- 服務名冊：服務的注冊和發(fā)現(xiàn)矛纹。
- 鑒權服務：提供鑒權服務：認證身份，驗證功能權限光稼。
- 前置后端：按前端的需求拆解請求或南、調用服務，并匯總艾君、轉換結果采够。
- 消息中介：全局通知機制；異步調用機制冰垄。
- 回路熔斷：隔離出問題的服務并等待其恢復蹬癌；提供備用方案。
- 負載均衡：避免服務過載虹茶。
需要說明的是逝薪，這些組件的組合形式，具體拆分形式蝴罪，是否需要翼闽，都需要結合實際項目和團隊的情況來調整。本文權作拋磚引玉洲炊，請讀者知悉。
文／ThoughtWorks張玳
