隨著開發(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ò)誤。