[[439445]]

微服務(wù)架構(gòu)幫助你擴(kuò)展

微服務(wù)架構(gòu)可以幫助你進(jìn)行多個(gè)維度的擴(kuò)展：

• 流量和客戶。微服務(wù)使你能夠以更多流量和數(shù)據(jù)支持更多客戶。
• 開發(fā)人員和開發(fā)團(tuán)隊(duì)的數(shù)量。微服務(wù)架構(gòu)使你能夠添加更多的開發(fā)團(tuán)隊(duì)，從而為你的應(yīng)用程序添加更多的開發(fā)人員。而且由于開發(fā)人員不會(huì)像在單體開發(fā)過程中那樣互相影響，使得他們的工作效率更高。
• 復(fù)雜性和能力。團(tuán)隊(duì)不需要考慮太多的應(yīng)用程序的表面問題，這使他們能夠?qū)Ｗ⒆约旱念I(lǐng)域去處理更復(fù)雜的問題。當(dāng)更多團(tuán)隊(duì)可以處理多種領(lǐng)域中的問題時(shí)，他們就有可能完成更復(fù)雜的項(xiàng)目。

面向單一團(tuán)隊(duì)的服務(wù)架構(gòu)(STOSA)

僅僅將你的應(yīng)用程序遷移到基于微服務(wù)的架構(gòu)是不夠的。即使你使用微服務(wù)架構(gòu)，但開發(fā)團(tuán)隊(duì)仍有可能需要處理不同的服務(wù)項(xiàng)目，團(tuán)隊(duì)之間也有可能創(chuàng)建復(fù)雜的交互。最壞的情況是，即使轉(zhuǎn)向基于微服務(wù)的架構(gòu)，你仍然可能陷入開發(fā)困境。

為了避免這些問題，你必須建立一個(gè)明確的服務(wù)所有權(quán)制度和責(zé)任模型。每個(gè)服務(wù)都需要一個(gè)獨(dú)立的、明確的、清晰的負(fù)責(zé)人，該負(fù)責(zé)人對(duì)服務(wù)負(fù)全部責(zé)任，并且每一個(gè)服務(wù)工作都需要進(jìn)行管理和委派。我建議使用一個(gè)模型，例如面向單一團(tuán)隊(duì)的服務(wù)架構(gòu) (STOSA)，它可以讓你的應(yīng)用程序和開發(fā)團(tuán)隊(duì)更好地好擴(kuò)展以滿足業(yè)務(wù)需求。

微服務(wù)架構(gòu)的成本

微服務(wù)架構(gòu)確實(shí)是有成本的。雖然，單個(gè)服務(wù)更易于理解和管理，但使用微服務(wù)架構(gòu)的應(yīng)用程序作為一個(gè)整體，明顯具有更多的活動(dòng)部件，本身就變得更加復(fù)雜龐大，這會(huì)導(dǎo)致應(yīng)用程序變得復(fù)雜。這種復(fù)雜性也會(huì)給應(yīng)用程序的其他部分帶來問題，這些問題不應(yīng)該被忽視。

此外，當(dāng)許多陷入困境的公司(如圖1所示)計(jì)劃遷移到微服務(wù)架構(gòu)(如圖2所示)時(shí)，他們通常會(huì)發(fā)現(xiàn)過渡期比他們希望或預(yù)期的更困難、更昂貴。因此，在遷移過程中，他們就放棄了。這導(dǎo)致他們是部分遷移的，而這種情況通常比開始時(shí)還要糟糕。

圖1

圖2

在遷移到微服務(wù)架構(gòu)之前，請(qǐng)確保你了解未來要花費(fèi)的成本、收益和挑戰(zhàn)。你必須設(shè)定適當(dāng)?shù)钠谕拍苁惯w移成功，并在未來得到你理想中的應(yīng)用程序。

作者：Lee Atchison，云計(jì)算和應(yīng)用程序現(xiàn)代化領(lǐng)域公認(rèn)的專家。Lee在產(chǎn)品開發(fā)、架構(gòu)、擴(kuò)展和現(xiàn)代化應(yīng)用方面擁有超過三十年的經(jīng)驗(yàn)，曾在 Amazon、Amazon Web Services (AWS)、New Relic等現(xiàn)代應(yīng)用行業(yè)工作過。Lee最近的一本書是《Architing for Scale(O'Reilly Media)》。

原文網(wǎng)址：https://www.infoworld.com/article/3637016/why-you-should-use-a-microservice-architecture.html