如今辐棒，微服務(wù)架構(gòu)已經(jīng)成為了現(xiàn)代應(yīng)用開(kāi)發(fā)的首選寡夹。雖然它能夠解決大部分的程序問(wèn)題，但是它并非一顆百試不爽的“銀彈”如贷。

在采用這種架構(gòu)之前陷虎，我們應(yīng)當(dāng)事先了解可能出現(xiàn)的各種問(wèn)題及其共性，預(yù)先為這些問(wèn)題準(zhǔn)備好可重用的解決方案杠袱。

那么尚猿，在開(kāi)始深入討論微服務(wù)的不同設(shè)計(jì)模式之前，讓我們先了解一下微服務(wù)架構(gòu)的一些構(gòu)建原則：

可擴(kuò)展性

可用性

彈性

獨(dú)立楣富、自主性

去中心化治理

故障隔離

自動(dòng)調(diào)配

通過(guò) DevOps 實(shí)現(xiàn)持續(xù)交付

在遵循上述各條原則的同時(shí)凿掂，我們難免會(huì)碰到一些挑戰(zhàn)。下面我們來(lái)具體討論可能出現(xiàn)的各種問(wèn)題纹蝴、及其解決方案庄萎。

分解模式

按照業(yè)務(wù)功能分解

問(wèn)題：微服務(wù)是有關(guān)松散耦合的服務(wù)，它采用的是單一職責(zé)原則塘安。雖然我們?cè)谶壿嬙砩隙贾酪獙蝹€(gè)應(yīng)用分成多個(gè)小塊糠涛，但是在實(shí)際操作中，我們又該如何將某個(gè)應(yīng)用程序成功分解成若干個(gè)小的服務(wù)呢兼犯？

解決方案：有一種策略是按照業(yè)務(wù)功能進(jìn)行分解脱羡。此處的業(yè)務(wù)功能是指能夠產(chǎn)生價(jià)值的某種業(yè)務(wù)的最小單位。那么一組給定業(yè)務(wù)的功能劃分則取決于企業(yè)本身的類型免都。

例如锉罐，一家保險(xiǎn)公司的功能通常會(huì)包括：銷售、營(yíng)銷绕娘、承保脓规、理賠處理、結(jié)算险领、合規(guī)等方面侨舆。每一個(gè)業(yè)務(wù)功能都可以被看作是一種面向業(yè)務(wù)、而非技術(shù)的服務(wù)绢陌。

按照子域分解

問(wèn)題：按照業(yè)務(wù)功能對(duì)應(yīng)用程序進(jìn)行分解只是一個(gè)良好的開(kāi)端挨下，之后您可能會(huì)碰那些不易分解的所謂“神類”（God Classes）。這些類往往會(huì)涉及到多種服務(wù)脐湾。

例如臭笆，訂單類就會(huì)被訂單管理、訂單接受、訂單交付等服務(wù)所使用到愁铺，那么我們又該如何分解呢鹰霍？

解決方案：對(duì)于“神類”的問(wèn)題，DDD（Domain Driven Design茵乱，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）能夠派上用場(chǎng)茂洒。

它使用子域（Subdomain）和邊界上下文（Bounded Context）的概念來(lái)著手解決。

DDD 會(huì)將企業(yè)的整個(gè)域模型進(jìn)行分解瓶竭，并創(chuàng)建出多個(gè)子域督勺。每個(gè)子域?qū)碛幸粋€(gè)模型，而該模型的范圍則被稱為邊界上下文斤贰。那么每個(gè)微服務(wù)就會(huì)圍繞著邊界上下文被開(kāi)發(fā)出來(lái)玷氏。

注意：識(shí)別子域并不是一件容易的事，我們需要通過(guò)分析業(yè)務(wù)與組織架構(gòu)腋舌，識(shí)別不同的專業(yè)領(lǐng)域盏触，來(lái)對(duì)企業(yè)加強(qiáng)了解。

刀砍模式（Strangler Pattern）

問(wèn)題：前面我們討論的設(shè)計(jì)模式一般適用于針對(duì)那些“白手起家”的 Greenfield 應(yīng)用進(jìn)行分解块饺。

但是我們真實(shí)接觸到的赞辩、約占 80％ 的是 Brownfield 應(yīng)用，即：一些大型的授艰、單體應(yīng)用（Monolithic Application）辨嗽。

由于它們已經(jīng)被投入使用、且正在運(yùn)行淮腾，如果我們簡(jiǎn)單按照上述方式糟需，同時(shí)對(duì)它們進(jìn)行小塊服務(wù)的分解，將會(huì)是一項(xiàng)艱巨的任務(wù)谷朝。

解決方案：此時(shí)洲押，刀砍模式（Strangler Pattern）就能派上用場(chǎng)了。我們可以把扼殺模式想象為用刀砍去纏在樹(shù)上的藤蔓圆凰。

該方案適用于那些反復(fù)進(jìn)行調(diào)用的 Web 應(yīng)用程序杈帐。對(duì)于每一個(gè) URI（統(tǒng)一資源標(biāo)識(shí)符）的調(diào)用來(lái)說(shuō)，單個(gè)服務(wù)可以被分解為不同的域和單獨(dú)的子服務(wù)专钉。其設(shè)計(jì)思想是一次僅處理一個(gè)域挑童。

這樣，我們就可以在同一個(gè) URI 空間內(nèi)并行地創(chuàng)建兩套獨(dú)立的應(yīng)用程序跃须。最終站叼，在新的應(yīng)用重構(gòu)完成后，我們就能“刀砍”或替換掉原來(lái)的應(yīng)用程序菇民，直到最后我們可以完全關(guān)閉掉原來(lái)的單體應(yīng)用尽楔。

集成模式

API 網(wǎng)關(guān)模式

問(wèn)題：當(dāng)一個(gè)應(yīng)用程序被分解成多個(gè)小的微服務(wù)時(shí)投储，我們需要關(guān)注如下方面。

具體如下：

如何通過(guò)調(diào)用多個(gè)微服務(wù)翔试，來(lái)抽象出 Producer（生產(chǎn)者）的信息轻要。

在不同的渠道上（如電腦桌面复旬、移動(dòng)設(shè)備和平板電腦）垦缅，應(yīng)用程序需要不同的數(shù)據(jù)來(lái)響應(yīng)相同的后端服務(wù)，比如：UI（用戶界面）就可能會(huì)有所不同驹碍。

不同的 Consumer（消費(fèi)者）可能需要來(lái)自可重用式微服務(wù)的不同響應(yīng)格式壁涎。誰(shuí)將去做數(shù)據(jù)轉(zhuǎn)換或現(xiàn)場(chǎng)操作？

如何處理不同類型的協(xié)議志秃？特別是一些可能不被 Producer 微服務(wù)所支持的協(xié)議怔球。

解決方案：API 網(wǎng)關(guān)將有助于解決在微服務(wù)實(shí)施過(guò)程中所涉及到的上述關(guān)注點(diǎn)。

具體如下：

API 網(wǎng)關(guān)是任何微服務(wù)調(diào)用的統(tǒng)一入口浮还。

它像代理服務(wù)一樣竟坛，能夠?qū)⒁粋€(gè)微服務(wù)請(qǐng)求路由到其相關(guān)的微服務(wù)處，并抽象出 Producer 的細(xì)節(jié)钧舌。

它既能將一個(gè)請(qǐng)求扇出（fan out担汤，輸出）到多個(gè)服務(wù)上，也能匯總多個(gè)結(jié)果洼冻，并發(fā)回給 Consumer崭歧。

鑒于通用 API 無(wú)法解決 Consumer 的所有請(qǐng)求，該方案能夠?yàn)槊恳环N特定類型的客戶端創(chuàng)建細(xì)粒度的 API撞牢。

它也可以將某種協(xié)議請(qǐng)求（如：AMQP）轉(zhuǎn)換為另一種協(xié)議（如：HTTP）率碾，反之亦然，從而方便了 Producer 和 Consumer 的處理屋彪。

它也可以將認(rèn)證與授權(quán)存儲(chǔ)庫(kù)從微服務(wù)中卸載出去所宰。

程序員面試社區(qū)：236283328

聚合器模式

問(wèn)題：雖然我們已經(jīng)在 API 網(wǎng)關(guān)模式中討論了如何解決聚合數(shù)據(jù)的問(wèn)題，不過(guò)我們?nèi)詫⒆鲞M(jìn)一步的討論畜挥。

當(dāng)我們將業(yè)務(wù)功能分解成多個(gè)較小的邏輯代碼塊時(shí)歧匈，有必要思考每個(gè)服務(wù)的返回?cái)?shù)據(jù)是如何進(jìn)行協(xié)作的。

顯然砰嘁，該責(zé)任不會(huì)留給 Consumer件炉，那么我們就需要理解 Producer 應(yīng)用的內(nèi)部實(shí)現(xiàn)。

解決方案：聚合器模式將有助于解決該問(wèn)題矮湘。它涉及到如何聚合來(lái)自不同服務(wù)的數(shù)據(jù)斟冕，然后向 Consumer 發(fā)送最終響應(yīng)。

具體說(shuō)來(lái)缅阳，我們有如下兩種實(shí)現(xiàn)方法：

復(fù)合微服務(wù)（Composite Microservice）將會(huì)去調(diào)用全部所需的微服務(wù)磕蛇，整合各種數(shù)據(jù)景描，并在回傳之前轉(zhuǎn)換數(shù)據(jù)。

API 網(wǎng)關(guān)（API Gateway）也能對(duì)多個(gè)微服務(wù)的請(qǐng)求進(jìn)行 Partition（分區(qū)）秀撇，并在發(fā)送給 Consumer 之前聚合數(shù)據(jù)超棺。

我們建議：如果您用到了任何業(yè)務(wù)邏輯的話，請(qǐng)選用復(fù)合微服務(wù)呵燕；否則請(qǐng)采用 API 網(wǎng)關(guān)方案棠绘。

客戶端 UI 合成模式

問(wèn)題：當(dāng)各種服務(wù)按照業(yè)務(wù)功能和子域被分解開(kāi)發(fā)時(shí)，它們需要根據(jù)用戶體驗(yàn)的預(yù)期效果再扭，從一些不同的微服務(wù)中提取數(shù)據(jù)氧苍。

在過(guò)去的單體應(yīng)用中，我們只要從 UI 到后端服務(wù)的唯一調(diào)用中獲取所有的數(shù)據(jù)泛范，并刷新和提交到 UI 頁(yè)面上便可让虐。如今，情況則不同了罢荡。

解決方案：對(duì)于微服務(wù)來(lái)說(shuō)赡突，UI 必須被設(shè)計(jì)成單屏、單頁(yè)面的多段区赵、多區(qū)域的結(jié)構(gòu)惭缰。

每一段都會(huì)去調(diào)用單獨(dú)的后端微服務(wù)，以提取數(shù)據(jù)惧笛。像 Angular JS 和 React JS 之類的框架都能夠?qū)崿F(xiàn)為特定的服務(wù)合成 UI 組件从媚。

通過(guò)被稱為單頁(yè)應(yīng)用（Single Page Applications，SPA）的方式患整，它們能夠使得應(yīng)用程序僅刷新屏幕的特定區(qū)域拜效，而不是整個(gè)頁(yè)面。

數(shù)據(jù)庫(kù)模式

按服務(wù)分配數(shù)據(jù)庫(kù)

問(wèn)題：您可能會(huì)碰到如何定義數(shù)據(jù)庫(kù)架構(gòu)的微服務(wù)問(wèn)題各谚。

下面是具體的關(guān)注點(diǎn)：

服務(wù)必須是松散耦合的紧憾，以便能夠被二次開(kāi)發(fā)、部署和獨(dú)立擴(kuò)容昌渤。

各個(gè)業(yè)務(wù)交易需要在橫跨多個(gè)服務(wù)時(shí)赴穗，仍保持不變。

某些業(yè)務(wù)交易需要從多個(gè)服務(wù)中查詢到數(shù)據(jù)膀息。

數(shù)據(jù)庫(kù)有時(shí)需要根據(jù)規(guī)模需求被復(fù)制與分片般眉。

不同的服務(wù)具有不同的數(shù)據(jù)存儲(chǔ)需求。

解決方案：為了解決上述需求潜支，我們需要通過(guò)設(shè)計(jì)為每個(gè)微服務(wù)配備一個(gè)獨(dú)享的數(shù)據(jù)庫(kù)模式甸赃。

即：該數(shù)據(jù)庫(kù)僅能被其對(duì)應(yīng)微服務(wù)的 API 單獨(dú)訪問(wèn)，而不能被其他服務(wù)直接訪問(wèn)到冗酿。

例如埠对，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)络断，我們可以使用：按服務(wù)分配私有表集（private-tables-per-service）、按服務(wù)分配表結(jié)構(gòu)（schema-per-service）项玛、或按服務(wù)分配數(shù)據(jù)庫(kù)服務(wù)器（database-server-per-service）貌笨。

每個(gè)微服務(wù)應(yīng)該擁有一個(gè)單獨(dú)的數(shù)據(jù)庫(kù) ID，以便它們?cè)讵?dú)享訪問(wèn)的同時(shí)襟沮，禁止再訪問(wèn)其他的服務(wù)表集锥惋。

按服務(wù)共享數(shù)據(jù)庫(kù)

問(wèn)題：上面討論的按服務(wù)分配數(shù)據(jù)庫(kù)是一種理想的微服務(wù)模式，它一般被前面提到的 Greenfield 應(yīng)用和 DDD 式的開(kāi)發(fā)臣嚣。但是净刮，如果我們面對(duì)的是需要采用微服務(wù)的單體應(yīng)用就沒(méi)那么容易了剥哑。

解決方案：按服務(wù)共享數(shù)據(jù)庫(kù)的模式雖然有些違背微服務(wù)的理念硅则，但是它對(duì)于將前面提到的 Brownfield 應(yīng)用（非新建應(yīng)用）分解成較小的邏輯塊是比較適用的。

在該模式下株婴，一個(gè)數(shù)據(jù)庫(kù)可以匹配不止一個(gè)的微服務(wù)怎虫，當(dāng)然也至多 2～3 個(gè)，否則會(huì)影響到擴(kuò)容困介、自治性和獨(dú)立性大审。

命令查詢職責(zé)隔離（CQRS）

問(wèn)題：對(duì)于按服務(wù)分配數(shù)據(jù)庫(kù)的模式而言，我們?nèi)绾卧谖⒎?wù)的架構(gòu)中座哩，實(shí)現(xiàn)對(duì)多個(gè)服務(wù)進(jìn)行聯(lián)合查詢數(shù)據(jù)的需求呢徒扶？

解決方案：CQRS 建議將應(yīng)用程序拆分成兩個(gè)部分：命令和查詢。命令部分主要處理創(chuàng)建根穷、更新和刪除之類的請(qǐng)求姜骡；查詢部分則利用物化視圖（Materialized Views）來(lái)處理各種查詢。

它通常配合事件溯源模式（Event Sourcing Pattern）一起創(chuàng)建針對(duì)任何數(shù)據(jù)的變更事件屿良。而物化視圖則通過(guò)訂閱事件流圈澈，來(lái)保持更新。

Saga 模式

問(wèn)題：當(dāng)每個(gè)服務(wù)都有自己的數(shù)據(jù)庫(kù)尘惧，而且業(yè)務(wù)交易橫跨多個(gè)服務(wù)時(shí)康栈，我們?cè)撊绾未_保整體業(yè)務(wù)數(shù)據(jù)的一致性呢？

例如：對(duì)于某個(gè)帶有客戶信用額度標(biāo)識(shí)的電商應(yīng)用而言喷橙，它需要確保新的訂單不會(huì)超出客戶的信用額度啥么。

但是，由于訂單和客戶分屬不同的數(shù)據(jù)庫(kù)贰逾，應(yīng)用程序無(wú)法簡(jiǎn)單地實(shí)現(xiàn)本地交易的 ACID（原子性悬荣、一致性、隔離性似踱、持久性）特性隅熙。

解決方案：Saga 代表了一個(gè)高層次的業(yè)務(wù)流程稽煤，它是由一個(gè)服務(wù)中的多個(gè)子請(qǐng)求，并伴隨著逐個(gè)更新的數(shù)據(jù)所組成囚戚。在某個(gè)請(qǐng)求失敗時(shí)酵熙，它的補(bǔ)償請(qǐng)求會(huì)被執(zhí)行。

實(shí)現(xiàn)方式有如下兩種：

編排（Choreography）：沒(méi)有中央?yún)f(xié)調(diào)器驰坊，每個(gè)服務(wù)都會(huì)產(chǎn)生并偵聽(tīng)其他服務(wù)的事件匾二，以決定是否應(yīng)采取行動(dòng)。

協(xié)調(diào)（Orchestrator）：由一個(gè)中央?yún)f(xié)調(diào)器（對(duì)象）負(fù)責(zé)集中處理某個(gè)事件（Saga）的決策拳芙，和業(yè)務(wù)邏輯的排序察藐。

觀測(cè)模式

日志聚合

問(wèn)題：我們來(lái)考慮這樣一個(gè)用例：某個(gè)應(yīng)用程序包括了那些在多臺(tái)機(jī)器上運(yùn)行的多個(gè)服務(wù)實(shí)例，各種請(qǐng)求橫跨在這些多個(gè)服務(wù)實(shí)例之中舟扎。同時(shí)分飞，每個(gè)服務(wù)實(shí)例都會(huì)生成一種標(biāo)準(zhǔn)格式的日志文件。

那么我們?nèi)绾吾槍?duì)某個(gè)特定的請(qǐng)求睹限，通過(guò)各種日志來(lái)理解該應(yīng)用程序的行為呢譬猫？

解決方案：顯然，我們需要一個(gè)集中化的日志服務(wù)羡疗，將各個(gè)服務(wù)實(shí)例的日志予以聚合染服，以便用戶對(duì)日志進(jìn)行搜索和分析。他們可以針對(duì)日志中可能出現(xiàn)的某些消息叨恨，配置相應(yīng)的警告柳刮。

例如：PCF（Pivotal Cloud Foundry）平臺(tái)擁有一個(gè)日志聚合器，它從每種元素（如：路由器痒钝、控制器等）中收集與應(yīng)用相關(guān)的日志秉颗。而 AWS Cloud Watch 也具有相似的功能。

性能指標(biāo)

問(wèn)題：當(dāng)各種服務(wù)組合隨著微服務(wù)架構(gòu)變得越來(lái)越復(fù)雜時(shí)午乓，監(jiān)控交易的完整性站宗，并能夠在出現(xiàn)問(wèn)題時(shí)及時(shí)發(fā)出警告，就顯得尤為重要了益愈。那么我們?cè)撊绾问占c應(yīng)用相關(guān)的性能指標(biāo)呢梢灭？

解決方案：為了收集不同操作的統(tǒng)計(jì)信息，并提供相應(yīng)的報(bào)告和警告蒸其。

我們一般會(huì)用兩種模式來(lái)聚集各項(xiàng)指標(biāo)：

推式：將各項(xiàng)指標(biāo)推給專門的指標(biāo)服務(wù)敏释，如：NewRelic 和 AppDynamics。

拉式：從指標(biāo)服務(wù)處拉取各項(xiàng)指標(biāo)摸袁，如：Prometheus钥顽。

分布式跟蹤

問(wèn)題：在微服務(wù)架構(gòu)中，橫跨多個(gè)服務(wù)的請(qǐng)求是比較常見(jiàn)的靠汁。某個(gè)服務(wù)需要通過(guò)橫跨多個(gè)服務(wù)去執(zhí)行一到多項(xiàng)操作蜂大，才能處理一些特定的請(qǐng)求闽铐。

那么，我們?cè)撊绾瓮ㄟ^(guò)跟蹤某個(gè)端到端的請(qǐng)求奶浦，以獲知出現(xiàn)的問(wèn)題呢兄墅？

解決方案：我們需要一種具有特性的服務(wù)。

具體特性服務(wù)如下：

為每個(gè)外部請(qǐng)求分配一個(gè)唯一的 ID澳叉。

將該外部請(qǐng)求 ID 傳給所有的服務(wù)隙咸。

在所有的日志消息中都包含該外部請(qǐng)求 ID。

在集中式服務(wù)中成洗，記錄處理外部請(qǐng)求的相關(guān)信息五督，包括：開(kāi)始時(shí)間、結(jié)束時(shí)間瓶殃、和執(zhí)行時(shí)間充包。

Spring Cloud Slueth + Zipkin Server，是一種常見(jiàn)的實(shí)現(xiàn)方式碌燕。

程序員面試社區(qū)：236283328

健康檢查

問(wèn)題：我們?cè)趯?shí)施微服務(wù)架構(gòu)的過(guò)程中误证，可能會(huì)碰到某個(gè)服務(wù)雖已啟動(dòng)继薛，但是無(wú)法處理交易的情況修壕。

那么，我們?cè)撊绾瓮ㄟ^(guò)負(fù)載均衡的模式遏考，來(lái)確保請(qǐng)求不會(huì)“落入”失敗的實(shí)例中呢慈鸠？

解決方案：每個(gè)服務(wù)都需要有一個(gè)端點(diǎn)，通過(guò)諸如 /health 的參數(shù)灌具，對(duì)應(yīng)用進(jìn)行健康檢查青团。

該 API 需要能夠檢查主機(jī)的狀態(tài)，其他服務(wù)與基礎(chǔ)設(shè)施的連接性咖楣，以及任何特定的邏輯關(guān)系督笆。

Spring Boot Actuator 不但能夠?qū)崿F(xiàn)端點(diǎn)的健康檢查，還能夠被定制實(shí)施诱贿。

橫切關(guān)注點(diǎn)模式（Cross-Cutting Concern Patterns）

外部配置

問(wèn)題：通常情況下娃肿，一個(gè)服務(wù)需要去調(diào)用其他的服務(wù)和數(shù)據(jù)庫(kù)。在諸如開(kāi)發(fā)珠十、QA（Quality Assurance料扰，質(zhì)量保證）、UAT（User Acceptance Test焙蹭，用戶驗(yàn)收測(cè)試）晒杈、和生產(chǎn)環(huán)境中，端點(diǎn)的 URL孔厉、或某些配置的屬性會(huì)有所不同拯钻。

因此帖努，有時(shí)候我們需要對(duì)這些服務(wù)的各種屬性進(jìn)行重構(gòu)、和重新部署粪般。那么我們?nèi)绾伪苊庠谂渲米兏行薷拇a呢然磷？

解決方案：外部化（externalize）所有的配置，包括各個(gè)端點(diǎn)的 URL 和信任憑據(jù)刊驴，以保證應(yīng)用程序在啟動(dòng)時(shí)姿搜、或運(yùn)行中能夠加載它們。

Spring Cloud 配置服務(wù)器提供了向 GitHub 進(jìn)行屬性外部化的選項(xiàng)捆憎，并將其作為環(huán)境屬性予以加載舅柜。

此法保證了應(yīng)用程序能夠在啟動(dòng)時(shí)就被訪問(wèn)到，或是在不重啟服務(wù)器的情況下實(shí)現(xiàn)刷新躲惰。

服務(wù)發(fā)現(xiàn)模式

問(wèn)題：當(dāng)微服務(wù)初具規(guī)模時(shí)致份，我們需要考慮如下兩個(gè)關(guān)于調(diào)用服務(wù)方面的問(wèn)題。

具體問(wèn)題如下：

由于采用了容器技術(shù)础拨，IP 地址往往被動(dòng)態(tài)地分配給不同的服務(wù)實(shí)例氮块。因此，每次當(dāng) IP 地址發(fā)生變化時(shí)诡宗，Consumer 服務(wù)可能會(huì)受到影響滔蝉，需要我們手動(dòng)更改。

?Consumer 需要記住每個(gè)服務(wù)的 URL塔沃，這就倒退成了緊耦合的狀態(tài)蝠引。

那么，Consumer 或路由器該如何獲知所有可用的服務(wù)實(shí)例與位置呢蛀柴？

解決方案：我們需要?jiǎng)?chuàng)建一個(gè)服務(wù)注冊(cè)表螃概，來(lái)保存每個(gè) Producer 服務(wù)的元數(shù)據(jù)（Meta Data）。

一個(gè)服務(wù)實(shí)例在啟動(dòng)時(shí)鸽疾，應(yīng)當(dāng)被注冊(cè)到表中吊洼；而在關(guān)閉時(shí)，需從表中被注銷制肮。

Consumer 或路由器通過(guò)查詢?cè)撟?cè)表冒窍，就能夠找到服務(wù)的位置。Producer 服務(wù)也需要對(duì)該注冊(cè)表進(jìn)行健康檢查弄企，以確保能夠消費(fèi)到那些可用的超燃、且正在運(yùn)行的服務(wù)實(shí)例。

我們一般有兩種服務(wù)發(fā)現(xiàn)的類型：客戶端和服務(wù)器端拘领。使用客戶端發(fā)現(xiàn)的例子是 Netflix Eureka意乓；而使用服務(wù)器端發(fā)現(xiàn)的例子是 AWS ALB。

斷路器模式

問(wèn)題：有時(shí)候，某個(gè)服務(wù)在調(diào)用其他服務(wù)届良，以獲取數(shù)據(jù)的時(shí)候笆凌，會(huì)出現(xiàn)下游服務(wù)（Downstream Service）“掉線”的情況。

它一般會(huì)帶來(lái)兩種結(jié)果：

該請(qǐng)求持續(xù)發(fā)往該掉線服務(wù)士葫，直至網(wǎng)絡(luò)資源耗盡和性能降低乞而。

用戶產(chǎn)生不可預(yù)料的、較差的使用體驗(yàn)慢显。

那么我們?cè)撊绾伪苊夥?wù)的連鎖故障爪模，并妥善處置呢？

解決方案：Consumer 應(yīng)該通過(guò)一個(gè)代理來(lái)調(diào)用某項(xiàng)遠(yuǎn)程服務(wù)荚藻，就像電路中的斷路器一樣屋灌。

當(dāng)出現(xiàn)持續(xù)失敗的數(shù)量超過(guò)設(shè)定閾值時(shí)，斷路器就會(huì)“跳閘”一段時(shí)間应狱，從而導(dǎo)致所有調(diào)用遠(yuǎn)程服務(wù)的嘗試被立即切斷共郭。

在超過(guò)設(shè)定時(shí)間之后哗戈，斷路器只允許有限數(shù)量的測(cè)試請(qǐng)求通過(guò)翘瓮。而如果這些請(qǐng)求成功了耙厚，那么斷路器將恢復(fù)正常運(yùn)行瓤湘；否則判定為故障依舊，并重新開(kāi)始新的定時(shí)周期拗小。

Netflix Hystrix 就很好地使用了該斷路器模式莹弊。它可以在斷路器“跳閘”的時(shí)候赠橙，幫助您定義一種回退機(jī)制散吵，以提供更好的用戶體驗(yàn)龙考。

藍(lán)綠部署模式

問(wèn)題：在微服務(wù)架構(gòu)中，一個(gè)應(yīng)用程序可以有多個(gè)微服務(wù)矾睦。如果我們?yōu)榱瞬渴鹨粋€(gè)增強(qiáng)版，而停止所有的服務(wù)炎功，那么停機(jī)時(shí)間一旦過(guò)長(zhǎng)枚冗，就會(huì)對(duì)業(yè)務(wù)造成影響。

況且蛇损，這對(duì)于回退來(lái)說(shuō)也將會(huì)是一場(chǎng)噩夢(mèng)赁温。那么我們?cè)撊绾伪苊狻⒒驕p少部署過(guò)程中服務(wù)的停機(jī)時(shí)間呢淤齐？

解決方案：我們可以采用藍(lán)綠部署的策略股囊，以減少或消除停機(jī)時(shí)間。在藍(lán)更啄、綠兩個(gè)相同的生產(chǎn)環(huán)境中稚疹，我們假設(shè)綠色環(huán)境有著當(dāng)前真實(shí)的實(shí)例，而藍(lán)色環(huán)境具有應(yīng)用程序的最新版本祭务。

在任何時(shí)候内狗，只有一個(gè)環(huán)境能夠處理所有真實(shí)的流量怪嫌，并對(duì)外提供服務(wù)。如今柳沙，所有的云服務(wù)平臺(tái)都能提供基于藍(lán)綠部署的選項(xiàng)岩灭。

當(dāng)然，我們還可以采用許多其他的微服務(wù)架構(gòu)模式赂鲤，如：Sidecar 模式噪径、鏈?zhǔn)轿⒎?wù)（Chained Microservice）、分支微服務(wù)（Branch Microservice）数初、事件溯源模式（Event Sourcing Pattern）熄云、和持續(xù)交付方式等。