Lucas Carlson 陳琳華

使用微服務(wù)架構(gòu)將大型應(yīng)用程序分解為可橫向擴(kuò)展的輕量級(jí)應(yīng)用程序。

你正在為幾十萬(wàn)行遺留的C ++續(xù)命吧?？瓤龋覀円l(shuí)？數(shù)百萬(wàn)行的Vectran只是IBM在上世紀(jì)七十年代開(kāi)發(fā)的一種短命的Fortran變體。但是，嘿，如果它們還沒(méi)壞呢？除非它們壞了。每當(dāng)有人試圖添加功能時(shí)，它們就會(huì)崩潰。嘗試修復(fù)漏洞會(huì)產(chǎn)生更多的漏洞。但是如果你不碰它們，它們就會(huì)一直工作下去。

問(wèn)題在于創(chuàng)新需要敏捷和速度。那些從未擔(dān)心過(guò)“千年蟲(chóng)”（Y2K）計(jì)算機(jī)系統(tǒng)漏洞的新炫酷公司正在拋棄你的那些老舊軟件。投資者們需要的是新一代重大創(chuàng)新。大批客戶也正在選擇拋棄這些老舊軟件。

解決方案是殺死那些單體大型應(yīng)用程序，并且不再創(chuàng)建新的類(lèi)似應(yīng)用程序。實(shí)現(xiàn)的方法是使用微服務(wù)架構(gòu)，這種技術(shù)可將大型應(yīng)用程序分解為可以橫向擴(kuò)展的輕量級(jí)應(yīng)用程序。

微服務(wù)定義

微服務(wù)將功能分解為由RESTful API松散耦合的獨(dú)立應(yīng)用程序。例如，eBay在2006年開(kāi)發(fā)的獨(dú)立Java servlet應(yīng)用程序，以用于處理用戶、項(xiàng)目、賬戶、反饋、交易和70多項(xiàng)其他要素。這些邏輯功能應(yīng)用程序中的每一個(gè)都是一個(gè)微服務(wù)。

這些微服務(wù)每一個(gè)都是獨(dú)立的，并且不共享數(shù)據(jù)層。每個(gè)都有自己的數(shù)據(jù)庫(kù)和負(fù)載均衡器。隔離是微服務(wù)架構(gòu)的關(guān)鍵要素。不同的微服務(wù)需要不同的擴(kuò)展技術(shù)。例如，一些微服務(wù)可能使用關(guān)系型數(shù)據(jù)庫(kù)，而其他的可能使用NoSQL數(shù)據(jù)庫(kù)。

微服務(wù)的好處

微服務(wù)架構(gòu)將內(nèi)部架構(gòu)非常復(fù)雜的大型單體應(yīng)用程序分解成小型的可獨(dú)立擴(kuò)展的應(yīng)用程序。每個(gè)微服務(wù)都很小，開(kāi)發(fā)、更新和部署也不太復(fù)雜。

在考慮它們時(shí)，為什么首先要將這些功能都構(gòu)建到單個(gè)應(yīng)用程序中呢？至少在理論上，你可以想象為它們可存在于單獨(dú)的應(yīng)用程序和數(shù)據(jù)孤島中，這不會(huì)有什么大問(wèn)題。例如，如果拍賣(mài)收到兩份投標(biāo)書(shū)，但只有四分之一的銷(xiāo)售收到反饋，那么在一天中的任何時(shí)間投標(biāo)服務(wù)的活躍程度至少是反饋應(yīng)用程序的八倍。如果將這些組合到一個(gè)應(yīng)用程序中，你最終運(yùn)行并更新的代碼將比經(jīng)常需要的更多。 在本質(zhì)上，將不同的功能組分隔成單獨(dú)的應(yīng)用程序中是有其自身的道理。

圍繞微服務(wù)架構(gòu)進(jìn)行開(kāi)發(fā)可獲得一些隱性優(yōu)勢(shì)，例如可與PaaS、Docker和Linux容器等新技術(shù)緊密結(jié)合。

以微服務(wù)方式構(gòu)建應(yīng)用程序不僅可使應(yīng)用程序更加靈活和更具可擴(kuò)展性，它們還增加了構(gòu)建應(yīng)用程序的團(tuán)隊(duì)的可伸縮性。使用單一代碼，你可以建立一支大型團(tuán)隊(duì)，雖然團(tuán)隊(duì)成員能夠處理大段代碼，但是他們始終彼此掣肘。隨著代碼整體的增長(zhǎng)，開(kāi)發(fā)速度會(huì)斷崖式下降。

不過(guò)，借助微服務(wù)架構(gòu)，應(yīng)用程序可由小型的、分散的開(kāi)發(fā)團(tuán)隊(duì)構(gòu)建。他們可以獨(dú)立地工作和修改微服務(wù)。這樣做的好處是升級(jí)服務(wù)和添加功能更加便捷。軟件和開(kāi)發(fā)流程也將變得更加靈活。

微服務(wù)的挑戰(zhàn)

但每個(gè)架構(gòu)都有優(yōu)點(diǎn)和缺點(diǎn)。雖然優(yōu)點(diǎn)明顯，但是微服務(wù)架構(gòu)也帶來(lái)了一系列難以解決的新問(wèn)題——特別是記錄、監(jiān)控、測(cè)試和調(diào)試去中心化且松散耦合的新應(yīng)用程序

如果有一個(gè)漏洞，那么哪個(gè)微服務(wù)應(yīng)當(dāng)對(duì)此負(fù)責(zé)呢？微服務(wù)之間的相互依存關(guān)系使得這個(gè)問(wèn)題很難回答。微服務(wù)通常通過(guò)輕量級(jí)JSON REST API彼此通信。與其前身XML-RPC和SOAP不同的地方是，REST接口的定義正變得越來(lái)越松散。雖然這些輕量級(jí)API更靈活，更容易擴(kuò)展，但是它們?cè)黾恿诵枰O(jiān)控的新接口，這可能會(huì)產(chǎn)生中斷破壞或?qū)е鲁霈F(xiàn)漏洞。

在單體應(yīng)用程序中，你可以在代碼中添加調(diào)試鉤子，并在邏輯上逐步執(zhí)行每個(gè)執(zhí)行層以發(fā)現(xiàn)問(wèn)題區(qū)域。如果當(dāng)數(shù)十個(gè)甚至數(shù)百個(gè)獨(dú)立的微服務(wù)使用松散定義的API彼此之間相系通信，那么在處理由這些微服務(wù)組成的網(wǎng)格時(shí)，你就不能再這么做了。

盡管如此，但是通過(guò)精心安排，這些困難是可以被克服的。一些調(diào)試工具可以提供幫助，不過(guò)你可能需要根據(jù)其他部分的情況整合自己的解決方案。

微服務(wù)與容器和PaaS的關(guān)系

一種常見(jiàn)的誤解是，如果要使用微服務(wù)，那么你需要使用PaaS或Linux容器。其實(shí)事實(shí)根本不是這么回事。你可以在沒(méi)有微服務(wù)的情況下使用PaaS和Linux容器，并且也可以使用沒(méi)有PaaS或Linux容器的微服務(wù)。它們彼此并不需要對(duì)方。

不過(guò)，它們之間確實(shí)能夠很好地相互補(bǔ)充。無(wú)論是Heroku等公有云，還是Cloud Foundry或者OpenShift等私有云，PaaS環(huán)境都可以優(yōu)化運(yùn)行許多小型應(yīng)用程序。將330萬(wàn)行C ++應(yīng)用程序移植到PaaS平臺(tái)的事情永遠(yuǎn)都不會(huì)發(fā)生。

如果將應(yīng)用程序分解為小型可獨(dú)立擴(kuò)展的自足性應(yīng)用程序，那么這些小型應(yīng)用程序通常都非常適合在PaaS環(huán)境中運(yùn)行。

同樣，Linux容器也非常適合如微服務(wù)等小型無(wú)狀態(tài)應(yīng)用程序，而不是大型的單體應(yīng)用程序。

畢竟，虛擬機(jī)和Linux容器之間最大和最明顯的區(qū)別之一是缺少狀態(tài)。虛擬機(jī)可通過(guò)配置保持其狀態(tài)，而Linux容器的架構(gòu)在本質(zhì)上已經(jīng)不再與基礎(chǔ)映像有任何差異。你可以在Linux容器中安裝有狀態(tài)的文件夾，但是除非提交更改，否則容器本身不會(huì)進(jìn)行更改。

微服務(wù)架構(gòu)的橫向擴(kuò)展理念促進(jìn)了無(wú)共享、無(wú)狀態(tài)應(yīng)用程序的概念。它們不存儲(chǔ)或修改底層文件系統(tǒng)。為什么人們將微服務(wù)與Linux容器容易混為一談呢？原因在于兩者都不保留狀態(tài)。

微服務(wù)與SOA的關(guān)系

微服務(wù)與SOA（面向服務(wù)的架構(gòu)）關(guān)系密切，但又存在明顯差異。從表面上看，SOA與SOAP和XML-RPC相關(guān)聯(lián)，而微服務(wù)則與JSON相關(guān)聯(lián)。但在某些方面，相關(guān)的API格式有著明顯的外觀差異。

同樣，SOA使用企業(yè)服務(wù)總線，而微服務(wù)使用更輕量級(jí)的發(fā)布-訂閱服務(wù)總線。 盡管后者更為輕便但是原理是相似的。

微服務(wù)架構(gòu)和SOA之間的最大區(qū)別在于微服務(wù)必須可獨(dú)立部署，而SOA服務(wù)則通常在部署整體中實(shí)現(xiàn)。

微服務(wù)是否適合你？

重要的是要記住，微服務(wù)是對(duì)撞到“看不見(jiàn)的天花板”的應(yīng)對(duì)舉措。在某些時(shí)候，傳統(tǒng)的單體應(yīng)用程序架構(gòu)無(wú)法再進(jìn)行擴(kuò)展。每個(gè)成功的軟件項(xiàng)目都會(huì)遇到這種情況。數(shù)據(jù)庫(kù)會(huì)變得異常龐大，或是代碼行數(shù)已經(jīng)太多達(dá)到了數(shù)百萬(wàn)行，亦或是再也無(wú)法快速添加功能。

如果你還沒(méi)有撞到“看不見(jiàn)的天花板”。也就是說(shuō)，如果遺留應(yīng)用程序仍然運(yùn)行良好并且不需要改變太多，那么只是為了部署微服務(wù)而部署將會(huì)導(dǎo)致你基本上無(wú)法從中獲得什么好處。

畢竟，微服務(wù)的開(kāi)發(fā)過(guò)程不同于常規(guī)，并且具有難度。讓所有這些新服務(wù)保持運(yùn)行有時(shí)會(huì)讓人感覺(jué)像在空中將十幾個(gè)球拋來(lái)拋去。部署Kubernetes等編排工具可做一些調(diào)整。復(fù)雜的微服務(wù)架構(gòu)有著自己的詞典，它們能夠涵蓋你需要采用的所有新軟件模式。

然而，微服務(wù)并不像SOA被使用時(shí)那樣令人生畏。實(shí)際上，微服務(wù)實(shí)踐甚至可以在最小的軟件項(xiàng)目中實(shí)現(xiàn)，并且不需要拋棄所有舊代碼重新開(kāi)始。

如果你的大型應(yīng)用程序正在失控但軟件生命周期還有很長(zhǎng)時(shí)間，創(chuàng)新速度也已經(jīng)停滯不前，那么微服務(wù)可能正是你需要的東西?；蛘?，如果你剛剛開(kāi)始起步，那么從一開(kāi)始就考慮構(gòu)建基于微服務(wù)的應(yīng)用程序是非常明智的。

eBay表示，微服務(wù)架構(gòu)讓他們具備了進(jìn)行大規(guī)模擴(kuò)展的能力，提高了代碼的可擴(kuò)展性和可維護(hù)性，促進(jìn)了快速業(yè)務(wù)創(chuàng)新，創(chuàng)建了更快的產(chǎn)品交付模式，甚至連安全性也得到了增強(qiáng)。谷歌、亞馬遜、推特、PayPal和Netflix都有類(lèi)似的體驗(yàn)。 為了更便捷地部署微服務(wù)，許多公司還開(kāi)發(fā)了公共工具。

無(wú)論你是遇到了維護(hù)遺留代碼的問(wèn)題并且一籌莫展，還是已經(jīng)開(kāi)始使用全新的應(yīng)用程序，現(xiàn)在正是嘗試用微服務(wù)方式進(jìn)行應(yīng)用程序開(kāi)發(fā)的好時(shí)機(jī)。