隨著開發(fā)團(tuán)隊(duì)轉(zhuǎn)向采用微服務(wù)，最佳使用案例有助于提供參考，因此可以了解一些主要廠商的微服務(wù)用例。

大多數(shù)企業(yè)開發(fā)團(tuán)隊(duì)將不再使用云托管的微服務(wù)。因?yàn)榇蠖鄶?shù)可能會(huì)出現(xiàn)問(wèn)題，而早期的使用者會(huì)放棄甚至拒絕使用微服務(wù)。最好的微服務(wù)用例分為四類，每個(gè)企業(yè)都應(yīng)該聯(lián)系一個(gè)或多個(gè)早期微服務(wù)采用者，讓他們提出一些建議。

微服務(wù)用例

第一個(gè)用例是使用微服務(wù)來(lái)促進(jìn)云采用。大多數(shù)開發(fā)團(tuán)隊(duì)認(rèn)識(shí)到，最佳的使用公共云和混合云的應(yīng)用程序架構(gòu)是不同的。很少有人準(zhǔn)備說(shuō)明這些差異，以及如何實(shí)現(xiàn)有序的部署，安全和合規(guī)的運(yùn)作以及全面的托管效率。微服務(wù)提供了一種新的應(yīng)用程序模型的路徑，即使以整體形式，也容易地托管在數(shù)據(jù)中心中，仍然輕松移動(dòng)到云平臺(tái)。

微服務(wù)在定義一種在綁定服務(wù)方面具有動(dòng)態(tài)性的服務(wù)模型方面超越了面向服務(wù)架構(gòu)（SOA）。微服務(wù)是一個(gè)設(shè)計(jì)（如果正確完成）功能的單元，是無(wú)狀態(tài)和可擴(kuò)展的，同時(shí)，以緊耦合或松散耦合意義連接。用戶可以將微服務(wù)和核心應(yīng)用程序組件集成到單個(gè)機(jī)器映像中，復(fù)制服務(wù)并避免組件連接和集成的問(wèn)題。可以使用API管理器將相同的微服務(wù)擴(kuò)展為受控共享服務(wù)，該管理器可復(fù)制SOA機(jī)制的安全性，然后以治理許可的REST形式暴露。這種選擇范圍在應(yīng)用設(shè)計(jì)中是無(wú)與倫比的，它是云計(jì)算的理想選擇。

第二個(gè)微服務(wù)用例的重點(diǎn)是通過(guò)微服務(wù)實(shí)現(xiàn)以業(yè)務(wù)為中心的經(jīng)典面向服務(wù)架構(gòu)（SOA）的目標(biāo)。微服務(wù)要高效，要求應(yīng)用架構(gòu)師與企業(yè)架構(gòu)師更加配合，以識(shí)別可重用的業(yè)務(wù)功能，以轉(zhuǎn)變?yōu)槲⒎?wù)。這是一個(gè)重要的，有價(jià)值的，偏離傳統(tǒng)的SOA模式，其中服務(wù)的定義主要是基于技術(shù)考慮。企業(yè)最近意識(shí)到需要對(duì)IT元素和組件化進(jìn)行更多的基于業(yè)務(wù)的評(píng)估，但是如何開始卻不太明確。

通過(guò)識(shí)別應(yīng)用程序的業(yè)務(wù)功能，然后在應(yīng)用程序之間映射常見或非常相似的功能，開始實(shí)施良好的微服務(wù)策略。這些功能成為微服務(wù)創(chuàng)建的目標(biāo)，盡管預(yù)計(jì)將有一些是廣義最大限度的重用，有些可以基于諸如無(wú)狀態(tài)行為和可擴(kuò)展性的技術(shù)目標(biāo)映射到一系列微服務(wù)而不是單個(gè)微服務(wù)。

第三個(gè)微服務(wù)用例是使用微服務(wù)來(lái)利用云計(jì)算的彈性和可擴(kuò)展性。企業(yè)知道，采用云計(jì)算的主要好處并不是降低計(jì)算成本，而是更有效，更高效的運(yùn)營(yíng)，提高業(yè)務(wù)靈活性和應(yīng)用程序的體驗(yàn)質(zhì)量。問(wèn)題在于，用戶并不清楚如何利用云功能實(shí)現(xiàn)這些優(yōu)勢(shì)。而微服務(wù)是最好的答案。

彈性或可伸縮性意味著擴(kuò)展或收縮應(yīng)用程序資源以匹配工作負(fù)載并響應(yīng)失敗。這意味著構(gòu)建應(yīng)用程序，以便應(yīng)用程序的“瓶頸”組件可以實(shí)例化多個(gè)副本，并且可以在副本之間平衡工作負(fù)載。微服務(wù)說(shuō)明如何構(gòu)建組件以使此過(guò)程變得容易，并且用于將安全性/治理實(shí)踐應(yīng)用于微服務(wù)的API管理器也可用于負(fù)載平衡和實(shí)例管理。

這種用例也可以被視為將應(yīng)用程序移動(dòng)到基于容器的部署的一種方式，這是采用云計(jì)算企業(yè)越來(lái)越重要的一個(gè)目標(biāo)。由于微服務(wù)是相對(duì)較小的功能元素，它們適用于容器的低開銷模型，并且已經(jīng)做了大量工作來(lái)證明兩種技術(shù)的最佳結(jié)合。

最后一個(gè)，也許最復(fù)雜的微服務(wù)用例是創(chuàng)建事件驅(qū)動(dòng)的企業(yè)。。應(yīng)用程序設(shè)計(jì)長(zhǎng)期以來(lái)是基于應(yīng)用程序的概念，它是通過(guò)靜態(tài)工作流鏈接的一系列組件，通常通過(guò)消息/服務(wù)總線支持。企業(yè)IT作為企業(yè)事件響應(yīng)的一種看法是一種替代模式，對(duì)于IT和業(yè)務(wù)整體而言，它們比組件化或云計(jì)算具有更大的潛在影響。然而，事件驅(qū)動(dòng)的企業(yè)流程也與傳統(tǒng)設(shè)計(jì)有著深刻的背離，也是架構(gòu)師和開發(fā)人員面臨的挑戰(zhàn)。

找到工作的用例

微服務(wù)比任何當(dāng)前的技術(shù)開發(fā)直接支持事件驅(qū)動(dòng)的業(yè)務(wù)IT方式。作為無(wú)狀態(tài)功能實(shí)現(xiàn)的細(xì)粒度微服務(wù)可以根據(jù)需要向外推，這將開啟一個(gè)全新的應(yīng)用程序設(shè)計(jì)模型，功能組件根據(jù)需要進(jìn)行封送，并推送到工作人員起源點(diǎn)，并收集公司數(shù)據(jù)的信息庫(kù)。

大多數(shù)公司會(huì)發(fā)現(xiàn)微服務(wù)器的這些用例區(qū)域之一是相關(guān)的，許多公司會(huì)發(fā)現(xiàn)其中的幾個(gè)（甚至全部都可以應(yīng)用）。微服務(wù)并不會(huì)自動(dòng)解決這些問(wèn)題，很明顯，用例是應(yīng)用微服務(wù)的指南，但不一定是一個(gè)路線圖。最聰明的做法就是查看上面的所有要點(diǎn)，并將它們從即刻和長(zhǎng)期的重要性中排除。然后，確定與每個(gè)重點(diǎn)相關(guān)的微服務(wù)功能，并決定哪些特定的微服務(wù)能力是最重要的。

微型服務(wù)仍處于起步階段，很容易造成錯(cuò)誤，因?yàn)槿魏谓o定領(lǐng)域的最佳實(shí)踐仍然不成熟。這意味著，與微型服務(wù)一樣有價(jià)值，如今，它們?nèi)匀皇且粋€(gè)更多用戶支持的更長(zhǎng)時(shí)間的風(fēng)險(xiǎn)更高的策略。用戶需要花費(fèi)一定的時(shí)間評(píng)估使用案例，并仔細(xì)開發(fā)自己的微服務(wù)策略，以防止難以糾正早期的錯(cuò)誤。