微服務(wù)為數(shù)據(jù)中心基礎(chǔ)設(shè)施節(jié)省了額外費(fèi)用，特別是在長(zhǎng)期維護(hù)方面。但是數(shù)據(jù)中心管理人員需要在實(shí)施之前正確評(píng)估它。

為了應(yīng)對(duì)不斷發(fā)展的工作流程和增加的數(shù)據(jù)消耗，組織正在轉(zhuǎn)向基于微服務(wù)的架構(gòu)，以提高開(kāi)發(fā)速度，并為其軟件帶來(lái)創(chuàng)新。

由于擴(kuò)展了基礎(chǔ)設(shè)施功能、補(bǔ)丁、系統(tǒng)更新和添加的代碼，以往的基于應(yīng)用程序的基礎(chǔ)設(shè)施可能會(huì)逐漸失去模塊化和易維護(hù)性。這使得更難以對(duì)軟件進(jìn)行更小、更頻繁的更改，并在快速更新周期的基礎(chǔ)上建立功能。更新這些老化的軟件模型是微服務(wù)的優(yōu)勢(shì)之一。

“如果采用得當(dāng)，可以與現(xiàn)有服務(wù)并行運(yùn)行，并且部署所需的時(shí)間比大型服務(wù)少得多。”總部位于亞特蘭大的Kairu咨詢公司企業(yè)首席架構(gòu)師Calvin Brown說(shuō)。

數(shù)據(jù)中心管理人員通常不參與創(chuàng)建微服務(wù)架構(gòu)，但他們必須了解硬件如何支持成功實(shí)施。越來(lái)越多的企業(yè)通過(guò)讓開(kāi)發(fā)人員創(chuàng)建更小的服務(wù)來(lái)幫助他們更快地運(yùn)行。

借助可促進(jìn)協(xié)作、測(cè)試和集成的DevOps模型，管理人員和開(kāi)發(fā)人員可以獲得微服務(wù)的好處，并獲得有效開(kāi)發(fā)周期和部署硬件的必要支持。

本地?cái)?shù)據(jù)中心中的微服務(wù)

微服務(wù)是耦合到實(shí)現(xiàn)業(yè)務(wù)功能的服務(wù)集合中的應(yīng)用程序。為了更加定期地維護(hù)某些軟件功能，開(kāi)發(fā)人員可以分解軟件組件或服務(wù)，以形成分布式系統(tǒng)。這使得該技術(shù)非常適合基于云計(jì)算或本地的數(shù)據(jù)中心部署，因?yàn)樗�是一種可根據(jù)開(kāi)發(fā)人員的需求量身定制的架構(gòu)模式。

許多數(shù)據(jù)中心管理人員已經(jīng)熟悉的Docker和自動(dòng)化軟件是微服務(wù)的關(guān)鍵推動(dòng)者。

“微服務(wù)不需要采用昂貴的專用硬件。”PhoenixNAP全球IT解決方案總裁兼首席執(zhí)行官Ian McCarty說(shuō)，“它們可以在商用數(shù)據(jù)中心硬件上運(yùn)行共享集群，這更容易擴(kuò)展和替換。”

要啟動(dòng)并運(yùn)行微服務(wù)應(yīng)用程序，數(shù)據(jù)中心管理人員必須使用具有低延遲連接的基礎(chǔ)設(shè)施。管理人員可以使用自動(dòng)化軟件來(lái)簡(jiǎn)化部署，因?yàn)樗麄儽仨殕为?dú)部署每個(gè)應(yīng)用程序組件，這通常在容器內(nèi)部署。

“微服務(wù)的部署和監(jiān)控比傳統(tǒng)的單片系統(tǒng)更加困難和昂貴。”McCarty說(shuō)。

利用微服務(wù)的好處

除了提供更加模塊化的方式來(lái)更新軟件模塊之外，微服務(wù)還節(jié)省了一些維護(hù)費(fèi)用，即從測(cè)試到生產(chǎn)的更快的工作流程。

管理人員可以看到在勒索軟件或分布式拒絕服務(wù)攻擊或意外中斷的情況下采用微服務(wù)的好處。如果一個(gè)功能脫機(jī)，管理員可以處理該問(wèn)題，而不是關(guān)閉整個(gè)系統(tǒng)。

微服務(wù)還可以提高數(shù)據(jù)中心的可擴(kuò)展性和資源利用率。IT管理人員可以通過(guò)擴(kuò)大受影響組件的數(shù)量來(lái)處理需求高峰，而不是部署整個(gè)系統(tǒng)的副本。

“組織可以通過(guò)在云計(jì)算或其他數(shù)據(jù)中心部署臨時(shí)虛擬機(jī)來(lái)滿足特殊需求，而不必?fù)碛凶銐驈?qiáng)大的數(shù)據(jù)中心來(lái)支持整個(gè)系統(tǒng)。”McCarty說(shuō)。

開(kāi)發(fā)人員可以在自己的計(jì)算機(jī)上構(gòu)建每個(gè)服務(wù)，而不必?fù)?dān)心沒(méi)有足夠的資源來(lái)運(yùn)行它。

對(duì)于長(zhǎng)期維護(hù)，每個(gè)開(kāi)發(fā)團(tuán)隊(duì)都可以使用他們想要的源代碼來(lái)解決他們的問(wèn)題。這可以減少進(jìn)行更改所需的時(shí)間和協(xié)調(diào)性。

整體的微服務(wù)架構(gòu)并不強(qiáng)制IT管理員沿著特定的路徑前進(jìn)，因?yàn)樗�可以根�?jù)各個(gè)模塊的需要適應(yīng)多種技術(shù)和源代碼。這需要管理人員和開(kāi)發(fā)人員之間的溝通，因?yàn)楣芾砣藛T必須確保使用容器，小型云部署甚至無(wú)服務(wù)器部署來(lái)支持微服務(wù)是可行的。如果在開(kāi)發(fā)人員開(kāi)始編碼之前硬件沒(méi)有到位，則會(huì)延遲啟動(dòng)時(shí)間，增加配置成本，并減少了微服務(wù)的好處。

此外，如果管理人員使用異構(gòu)環(huán)境來(lái)支持微服務(wù)，那么他們必須確認(rèn)服務(wù)器和云平臺(tái)之間的兼容性，以便在架構(gòu)生效后最大限度地減少停機(jī)時(shí)間。

綜合考慮

在實(shí)施該技術(shù)之前，組織必須正確評(píng)估基于微服務(wù)體系結(jié)構(gòu)的用途。

“如果傳統(tǒng)的單片應(yīng)用程序變得難以管理或更新，那么微服務(wù)可能是使應(yīng)用程序更加健壯和可擴(kuò)展的良好機(jī)制。”451 Research公司首席分析師Jay Lyman說(shuō)，“如果沒(méi)有問(wèn)題，可能不需要微服務(wù)。”

此外，管理人員必須考慮如何分組功能以及哪些API將支持不同的模塊。在規(guī)劃服務(wù)分組時(shí)，開(kāi)發(fā)人員必須確保組件彼此一致，并且不應(yīng)在同一模塊中分組太多功能。

數(shù)據(jù)中心管理員需要了解任何部署計(jì)劃。這意味著評(píng)估當(dāng)前服務(wù)器和云計(jì)算容量，包括計(jì)算應(yīng)用程序帶寬和存儲(chǔ)要求，以確保微服務(wù)可以有效地長(zhǎng)期運(yùn)行，并處理數(shù)據(jù)的波動(dòng)。

采用基于微服務(wù)的架構(gòu)

451 Research公司表示，超過(guò)三分之一的企業(yè)IT決策者表示正處于微服務(wù)的初始或廣泛生產(chǎn)使用階段。在調(diào)查期間，62%的人表示正在積極評(píng)估測(cè)試環(huán)境中的微服務(wù)。只有4%的人表示沒(méi)有興趣采用。

而行業(yè)巨頭，如亞馬遜與AWS API集成和AWS Lambda以及微軟的Azure API管理，將推動(dòng)采用，因?yàn)樗麄冊(cè)趲椭�客戶的微服�?wù)實(shí)施方面投入了大量資金。

即使在大型技術(shù)組織的幫助下，IT管理員仍必須與開(kāi)發(fā)人員合作，找到適當(dāng)?shù)膶Ｓ梅��?wù)器，云計(jì)算和容器組合，以支持更靈活的軟件架構(gòu)，并了解微服務(wù)的優(yōu)勢(shì)。