微服務(wù)基礎(chǔ)建設(shè)所需要的各個模塊以及緣由
一衰齐、微服務(wù)
一個“服務(wù)”娘香，可以對應(yīng)多個服務(wù)實例。把每個服務(wù)實例都視作一個黑盒荤傲，這個盒子有著明確的輸入點和輸出點垮耳，并且（理想情況下）僅通過這些輸入和輸出點和外界產(chǎn)生關(guān)聯(lián)。每個服務(wù)實例會擁有專屬的網(wǎng)絡(luò)地址弃酌、獨立的計算資源氨菇，并且獨立部署儡炼〖讼妫客戶端通過訪問服務(wù)實例的地址來調(diào)用服務(wù)API（接口）。不同服務(wù)也可以相互調(diào)用乌询。
?1榜贴、微服務(wù)模塊
配置管理：配置集中管理。
?API 網(wǎng)關(guān)：對外的 API總目錄妹田；API 依賴關(guān)系唬党；發(fā)起鑒權(quán)。
?服務(wù)名冊：服務(wù)的注冊和發(fā)現(xiàn)鬼佣。
?鑒權(quán)服務(wù)：提供鑒權(quán)服務(wù)：認證身份驶拱，驗證功能權(quán)限。
前置后端：按前端的需求拆解請求晶衷、調(diào)用服務(wù)蓝纲，并匯總、轉(zhuǎn)換結(jié)果晌纫。
消息中介：全局通知機制税迷；異步調(diào)用機制。
回路熔斷：隔離出問題的服務(wù)并等待其恢復(fù)锹漱；提供備用方案箭养。
負載均衡：避免服務(wù)過載。
二哥牍、詳細介紹
2.1配置管理器：統(tǒng)一管理配置
在微服務(wù)體系中毕泌，每個服務(wù)都獨立部署和運行，團隊可以根據(jù)需要自行選擇增加和減少計算資源嗅辣。一個服務(wù)可能會跑多個實例撼泛，每個服務(wù)實例都會需要做配置。為了方便統(tǒng)一調(diào)整配置辩诞，我們可以把配置中心化坎弯，每個服務(wù)實例都去找配置管理器（Configuration Manager）拿配置。當配置更新的時候，我們也可以讓服務(wù)實例再去拿新的配置抠忘。
2.2服務(wù)名冊：解耦主機地址
網(wǎng)絡(luò)地址（比如 IP）很容易因為擴容撩炊、維護而變動，調(diào)用者難以實時獲知可用的地址崎脉。鑒于此拧咳，我們可以把網(wǎng)絡(luò)地址抽象成不容易變動的概念，比如給每個服務(wù)一個固定的名字囚灼÷嫦ィ互聯(lián)網(wǎng)使用 DNS來解決這個問題，對應(yīng)到微服務(wù)基建里面就是服務(wù)名冊（Service Registry）灶体。每個服務(wù)實例在運行期間阅签，都會以心跳的形式向服務(wù)名冊發(fā)送注冊信息，包括服務(wù)的 ID蝎抽、訪問地址以及健康狀況政钟。這樣，需要訪問服務(wù)的時候樟结，客戶端就可以先問服務(wù)名冊拿可用的實例地址养交，然后再訪問實例來調(diào)用服務(wù)。除了更好地定位實例地址瓢宦，服務(wù)名冊還可以在某些實例下線碎连、維護或升級的時候把其臨時從名冊中去掉，讓服務(wù)不斷線驮履。服務(wù)之間的調(diào)用也是如此鱼辙，先找名冊拿網(wǎng)絡(luò)地址，再進行調(diào)用疲吸。
2.3API網(wǎng)關(guān)：入口和路由
找名冊要地址座每，然后調(diào)用服務(wù) API，這些是每個客戶端都會去做的瑣事摘悴，我們完全可以把這些事情抽象峭梳、集中，把服務(wù)的 API 整合到一個大的中心點蹂喻，然后把要地址和調(diào)用服務(wù) API 這樣的細節(jié)封裝起來葱椭，所有客戶端都只跟這個中心點對話，不再直接訪問單個服務(wù)口四。
從結(jié)構(gòu)上看孵运，這個中心點把整個架構(gòu)劃分成了內(nèi)外兩部分，內(nèi)部是所有的服務(wù)蔓彩，客戶端則在外部从媚，中心點站在中間。它作為內(nèi)外的唯一通道瞬沦，被順理成章地命名作“API網(wǎng)關(guān)”（API Gateway）芙委，有時候也被稱做“邊緣服務(wù)”（Edge Service）憔四。API 網(wǎng)關(guān)作為唯一出入口，又占據(jù)了最前沿的有利位置，所以有時還會承載別的公共功能，比如我們馬上會提到的鑒權(quán)稚照。
2.4 鑒權(quán)服務(wù)：身份和權(quán)限問題
順著這個架構(gòu)繼續(xù)開發(fā)，我們會遇到新的問題：不方便的鑒權(quán)
鑒權(quán)（Auth）包括了兩個部分：身份認證（Authentication）和權(quán)限驗證（Authorization）俯萌。
身份認證關(guān)心的是“你是誰”果录，權(quán)限驗證關(guān)心的是“你能不能做某件事”。
身份和權(quán)限都是高度中心化的概念咐熙。
對于一個系統(tǒng)來說弱恒，用戶的身份必須是統(tǒng)一的。不能說這個用戶在做這個事情的時候是張三糖声，做那個事情的時候是李四斤彼。
此外分瘦，用戶的認證狀態(tài)也應(yīng)該是統(tǒng)一的蘸泻。不能說用戶訪問這個服務(wù)的時候是已登錄認證，訪問另一個服務(wù)時又是未登錄狀態(tài)嘲玫。所以悦施，只能有一個身份認證方。
權(quán)限稍微復(fù)雜一點去团，和身份不同，權(quán)限通常分成兩種類別：
功能權(quán)限和數(shù)據(jù)權(quán)限土陪。
這樣的劃分對應(yīng)了現(xiàn)實世界中常見的權(quán)限模式：
你的角色決定了你的職能昼汗，而職能范圍通常由附加條件來限制。
比如鬼雀，你是一個法官顷窒，對案件有裁決權(quán)，但是你是 A?區(qū)的法官源哩，只能判 A 區(qū)的案子鞋吉。
再比如，某個快餐門店的經(jīng)理有權(quán)看員工的詳細資料励烦，但是只能看自己門店的員工資料谓着。兩種權(quán)限都由全局的規(guī)則來確定，而不掌握在執(zhí)行部門坛掠。
比如赊锚，誰來判案治筒，取決于法律，而不取決于法院舷蒲。誰能查看誰的資料矢炼，也不由資料保管部門決定，而由規(guī)章制度決定阿纤。
在現(xiàn)實的情況中句灌，組織可能會有專門的審核部門來驗證權(quán)限，但對那些不是特別敏感的權(quán)限欠拾，企業(yè)會讓各個部門自行驗證胰锌。不過不管誰來執(zhí)行驗證，都必須拿著同一份規(guī)章制度藐窄，不能各說各話资昧。這份制度必須由中心機構(gòu)來統(tǒng)一制定、維護荆忍。也就是說格带，權(quán)限的管理也應(yīng)該中心化。明確鑒權(quán)中心化之后刹枉，我們就可以開發(fā)一個公用的鑒權(quán)服務(wù)叽唱，執(zhí)行身份認證和權(quán)限驗證。下一個問題是：誰來發(fā)起鑒權(quán)微宝？
所有服務(wù)的調(diào)用都要求調(diào)用者明確自己的身份棺亭，所以自然身份認證越靠前越好。
作為出入口的 API網(wǎng)關(guān)自然是發(fā)起身份認證的不二之選蟋软。
權(quán)限驗證則稍微復(fù)雜镶摘，完全值得另起一文詳述。此處我們暫時假定權(quán)限驗證也由 API網(wǎng)關(guān)來發(fā)起岳守。
2.5 消息中介：異步和通知
開發(fā)繼續(xù)進行凄敢，一切風平浪靜，技術(shù)上暫時沒有什么問題湿痢。不過涝缝，業(yè)務(wù)上有一個問題需要解決。
比如蒙袍，我們做一個在線商城俊卤，要求在訂單成功創(chuàng)建的一刻，倉庫就要啟動備貨和發(fā)貨的流程害幅。問題是消恍，訂單和倉儲是兩個服務(wù)，不同團隊在負責以现，而且從關(guān)注點來說狠怨，訂單服務(wù)并不關(guān)心倉儲相關(guān)的問題约啊，所以訂單服務(wù)不可能在創(chuàng)建訂單的時候去主動通知倉儲服務(wù)。倉儲服務(wù)只能定時輪詢訂單服務(wù)佣赖，看看有沒有新的訂單恰矩。這不僅麻煩，而且實時性不夠憎蛤。仔細想想外傅，我們會發(fā)現(xiàn)這種需求很常見，
信息的產(chǎn)生者并不知道（也不關(guān)心）誰會對信息產(chǎn)生興趣俩檬。比如我們可能會有一個監(jiān)控服務(wù)需要實時展示產(chǎn)品銷量萎胰，有一個 BI?服務(wù)需要獲取客戶購買產(chǎn)品的信息來做分析，等等棚辽。既然這是一個常見需求技竟，我們不妨把它模式化，形成一個機制：信息產(chǎn)生者把通知發(fā)出來屈藐，收到通知的人再確定是否需要采取行動榔组。這就意味著我們需要再引入一個中心化的公共服務(wù)：消息中介（Message Broker）。當某個事件發(fā)生的時候（比如用戶激活成功联逻、訂單創(chuàng)建成功）搓扯，服務(wù)可以朝消息隊列發(fā)一條消息。而其他服務(wù)可以訂閱這些消息遣妥，并針對這些消息做出反應(yīng)擅编。
比如，倉儲服務(wù)可以訂閱訂單創(chuàng)建成功的消息箫踩。這樣，訂單成功創(chuàng)建后谭贪，訂單服務(wù)將這個消息發(fā)到消息中介境钟，消息中介通知倉儲服務(wù)，倉儲服務(wù)一看俭识，就問訂單服務(wù)要新的訂單信息慨削，最后，啟動出庫流程套媚。
消息中介除了能廣播事件之外缚态，還能做異步調(diào)用。把同步的調(diào)用轉(zhuǎn)化成異步的回調(diào)堤瘤。針對調(diào)用時間長和不要求實時結(jié)果的調(diào)用玫芦，可以增加性能，提升體驗本辐。
2.6 前置后端：優(yōu)化前段開發(fā)
走到這里桥帆，其實體系已經(jīng)比較完備∫皆觯現(xiàn)在的問題是，如何讓微服務(wù)基建結(jié)構(gòu)和研發(fā)團隊常見的結(jié)構(gòu)更好地對應(yīng)起來老虫。這要求我們從康威定律的角度來看待整個基建的設(shè)計叶骨。在圍繞用戶和價值的軟件研發(fā)流程中，我們常用用戶歷程和用戶故事來捕捉和跟蹤價值的實現(xiàn)祈匙。一個用戶故事通常會包含一個有明確邊界忽刽、明確驗收標準和明確價值的業(yè)務(wù)步驟。問題在于夺欲，支撐一個故事有前后兩端的研發(fā)工作缔恳，二者是不同步的。前端由業(yè)務(wù)流程和設(shè)計來驅(qū)動洁闰，希望按順序產(chǎn)出歉甚；后端則由業(yè)務(wù)資源和建模來驅(qū)動，希望按模塊來產(chǎn)出扑眉。比如說纸泄，前端常常會因為設(shè)計的原因調(diào)整自己需要的字段，而后端從建模的角度并沒有這個需要腰素，也沒有動力頻繁地去跟隨前端的調(diào)整聘裁，使得前端不得不在不穩(wěn)定的網(wǎng)絡(luò)條件下傳輸多余的信息，占用了寶貴的網(wǎng)絡(luò)帶寬弓千。此外衡便，前端呈現(xiàn)某個業(yè)務(wù)步驟的時候，有兩種信息不屬于當前必備信息洋访，但常常需要和必要信息一起展示镣陕。一種是狀態(tài)信息，比如當前的登錄狀態(tài)和用戶名姻政，短消息的數(shù)量等等呆抑。一種是垂直相關(guān)的信息，比如在展示文章的時候順便展示一下相關(guān)的文章汁展。這就要求前端在調(diào)用主服務(wù)的同時還要再調(diào)用多個不同的服務(wù)鹊碍。且不說這些服務(wù)有可能會有調(diào)用超時、出錯的可能食绿，僅僅是多出來一堆異步請求侈咕，就已經(jīng)足夠讓前端效率降低一大截了。在微服務(wù)體系下器紧，這些問題更加嚴重耀销，因為現(xiàn)在不僅僅是前后端的差別，不同服務(wù)還由不同團隊負責品洛。這些團隊的訴求和日程不一树姨，很難做到前端所需要的快速響應(yīng)摩桶。這些問題和麻煩可能會催生一個“緩沖帶”，比如后端出專人來負責對接前端的需要帽揪，或者前端派駐一個人到后端來談需求硝清。按康威定律，這種溝通體系转晰，久而久之芦拿，很容易以軟件的形式沉淀下來，形成一個專屬的中間層查邢。要調(diào)和前后端的不同步是不可能的蔗崎，而這種中間層是自然催生的解決方案，可以保留扰藕。新的問題是缓苛，它的職責是什么？應(yīng)該把它放在哪邓深？應(yīng)該由誰來維護未桥？
分析下來，其責任有二芥备。
第一是解耦前后端的工作冬耿，降低相互的影響。前端需要的東西可以寫在中間層里萌壳，讓它頻繁變化也沒有關(guān)系亦镶。后端如果還沒有準備好，前端也可以在這一層模擬假的數(shù)據(jù)袱瓮，不至于被阻塞缤骨。
第二則是提升前端的運行效率。前端可以把所需要的多個服務(wù)的東西統(tǒng)一匯總懂讯，一次拿完荷憋，免得發(fā)多個請求。
放置的位置則在 API?網(wǎng)關(guān)之內(nèi)褐望，讓它可以享有 API 網(wǎng)關(guān)所帶來的好處和保護。
按照“誰主張串前，誰舉證”的原則瘫里，既然有了這個中間層，好處讓前端得了荡碾，那么谨读，理論上應(yīng)該由前端來維護。這樣坛吁，一個主要為前端服務(wù)的中間層就定義好了劳殖。不同類型的前端（桌面铐尚、移動）可能會有不同的需要，為了避免中間層的碎片化哆姻，我們可以讓各個中間層都特定的前端類型緊密耦合宣增，比如桌面專用、移動專用矛缨。如此爹脾，每個中間層都像是某類型前端的專享后端，所以“前置后端”（Backend-for-Frontend箕昭，簡稱 BFF）也因此得名灵妨。
2.7?回路熔斷器：提高容錯度
現(xiàn)在，調(diào)試也方便了落竹，我們又繼續(xù)開發(fā)泌霍。一開始沒有什么問題，但部署到預(yù)生產(chǎn)環(huán)境的時候述召，又一個問題出現(xiàn)了：整個體系的容錯度很低朱转。一個小錯誤容易被層層傳遞和放大，導(dǎo)致整個體系的崩潰桨武。
我們都知道肋拔，編程最麻煩的就是遠程調(diào)用。本地調(diào)用大部分時候結(jié)果是“成功”或“失敗”呀酸，但遠程調(diào)用則很可能是“無響應(yīng)”凉蜂。“無響應(yīng)”有可能是正常的性誉，對方可能稍后會給你結(jié)果窿吩，也可能是因為對方已經(jīng)死了，沒法給你響應(yīng)错览。最壞的結(jié)果纫雁，就是門口擠滿了人，大家都在等你給結(jié)果倾哺，而你也在等別人給結(jié)果轧邪，資源全部占用來等，什么也做不了羞海。
不過忌愚，遠程調(diào)用是無法避免的。在微服務(wù)體系中却邓，這個問題被進一步放大硕糊。這是因為微服務(wù)的模塊化以服務(wù)為單位，而每個服務(wù)獨立部署和運維，使得服務(wù)之間的調(diào)用成了家常便飯简十。在這種嚴峻的情況下檬某，我們必須從架構(gòu)上盡量提高整個服務(wù)體系的容錯度，讓個別服務(wù)的問題不至于影響到全局螟蝙。具體的做法恢恼，則是給遠程調(diào)用加一個熔斷閾值檢查，當調(diào)用超時次數(shù)超過閾值時胶逢，就不再調(diào)用厅瞎，直接返回錯誤。過一段時間之后初坠，再把閾值恢復(fù)和簸，嘗試繼續(xù)調(diào)用，重復(fù)前面的過程碟刺。這個機制就是回路熔斷锁保，而這個工具則是回路熔斷器（Circuit Breaker）。
除了隔離已經(jīng)出錯的服務(wù)實例半沽，熔斷器還有一個重要的功能是提供備用方案爽柒。雖然我們把所有業(yè)務(wù)都拆成了服務(wù)，但服務(wù)有高低貴賤之分者填。有一些服務(wù)屬于關(guān)鍵服務(wù)浩村，一旦出問題，則整個流程無法繼續(xù)占哟，有一些則屬于分支服務(wù)心墅，即便錯了，也不會影響大局榨乎。比如說怎燥，購買商品的時候，常常會根據(jù)用戶的習慣和當前正在購買的東西做一些推薦蜜暑。負責推薦的服務(wù)出問題的話铐姚，大不了就不推薦了，不應(yīng)該影響用戶正常的購買流程肛捍。同理隐绵，如果是在線點餐的地址定位服務(wù)出問題了，我們也應(yīng)該允許用戶手動選擇餐廳進行點餐——體驗雖然不佳拙毫，但至少正常的流程仍然可以走完氢橙。基于這個考慮恬偷，熔斷器應(yīng)該為非必要的服務(wù)調(diào)用提供備用方案，盡量保證核心流程的順暢。
有了回路熔斷器袍患，遠程調(diào)用出錯的問題就從一定程度上緩解了坦康。結(jié)合回路熔斷器和對熔斷閾值變化的監(jiān)控，開發(fā)者可以更容易地發(fā)現(xiàn)問題诡延，并及時采取行動滞欠。
2.8?負載均衡器：提升服務(wù)彈性
要正式上線，我們還必須做好負載均衡（LoadBalancing肆良，下簡稱 LB）筛璧，提升整個服務(wù)的彈性。要做負載均衡惹恃，從理論上有兩種方式：
客戶端負載均衡（Client-Side LB）：由客戶端來決定如何分散請求夭谤。
現(xiàn)在，服務(wù)名冊中已經(jīng)有了服務(wù)及其對應(yīng)的實例地址列表巫糙，所以客戶端的負載均衡最簡便的方式就是把地址拉下來朗儒，然后依次或者隨機選擇可用的地址。
中間方負載均衡（Mid-Tier LB）：由 DNS参淹、網(wǎng)關(guān)等中間方來決定如何分散請求醉锄。
中間方的負載均衡則選擇面較多，從最外層的DNS?到網(wǎng)關(guān)都可以不同程度地去按需要去做浙值。
2.9?擴展基建
現(xiàn)在恳不，微服務(wù)基建基本完成了。如果有需要开呐，我們可以對這個基建進行擴展烟勋。在做擴展時，架構(gòu)師應(yīng)該注意區(qū)分哪些東西應(yīng)該中心化负蚊，哪些東西應(yīng)該由服務(wù)自行決定神妹。比如說，在本文提到的基建之中家妆，（幾乎是）強制完全中心化的模塊有：
·配置管理
·服務(wù)名冊
·消息隊列
其中鸵荠，配置管理和服務(wù)名冊是所有服務(wù)都需要的基礎(chǔ)設(shè)施，必然需要統(tǒng)一伤极。消息隊列和日志收集都是為了跨服務(wù)的操作和追蹤蛹找，也必須中心化。
半中心化的模塊則有：
·路由
·鑒權(quán)
路由和鑒權(quán)都必須統(tǒng)一哨坪，我們前面討論過庸疾。不過，微服務(wù)可能會向外界暴露“自用”和“客用”等多套公共 API（比如快遞公司內(nèi)部使用的物流 API 和開放給第三方使用的物流 API）当编，所以可能會有兩個 API 網(wǎng)關(guān)届慈，對應(yīng)會有兩套 API 目錄和兩套鑒權(quán)體系，所以，它們是“半中心化”金顿。
這些都是中心化臊泌、半中心化的選擇范例。每一次中心化的選擇都可能會讓整個架構(gòu)變得死板揍拆，失去靈活性渠概，所以，我們在設(shè)計和擴展基建的時候應(yīng)該特別注意這個問題嫂拴。
除了中心化的選擇之外播揪，架構(gòu)發(fā)展的另一個關(guān)注點，是讓業(yè)務(wù)保持“黑盒”筒狠。
我們把每個服務(wù)之間的關(guān)聯(lián)抽取了出來猪狈，也把權(quán)限的定義和驗證抽取了出來，每個服務(wù)變得簡單而純粹窟蓝，成了“純業(yè)務(wù)式服務(wù)”罪裹，等同于一個僅包含了業(yè)務(wù)規(guī)則的黑盒。這樣运挫，不管服務(wù)和模塊再多状共，也沒有影響。業(yè)務(wù)的重用性也很高谁帕。
總而言之峡继，搭建好了微服務(wù)的必要設(shè)施之后，剩下的就要根據(jù)實際情況和項目經(jīng)驗來繼續(xù)調(diào)整了匈挖。比如碾牌，我們可能會選擇把很多功能合并到一層，以避免過度分層所帶來的不必要的性能損失儡循，或者對整個基建進行一些細節(jié)微調(diào)舶吗。只要把控好“中心-自理”和“業(yè)務(wù)-非業(yè)務(wù)”之間的關(guān)系，這個基礎(chǔ)設(shè)施就能健康地發(fā)展择膝。
