Lucas Carlson 陳琳華

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

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

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

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

微服務(wù)定義

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

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

微服務(wù)的好處

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

微服務(wù)架構(gòu)的橫向擴(kuò)展理念促進(jìn)了無共享、無狀態(tài)應(yīng)用程序的概念。它們不存儲或修改底層文件系統(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ù)使用更輕量級的發(fā)布-訂閱服務(wù)總線。 盡管后者更為輕便但是原理是相似的。

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

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

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

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

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

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

如果你的大型應(yīng)用程序正在失控但軟件生命周期還有很長時間，創(chuàng)新速度也已經(jīng)停滯不前，那么微服務(wù)可能正是你需要的東西?；蛘撸绻銊倓傞_始起步，那么從一開始就考慮構(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都有類似的體驗。 為了更便捷地部署微服務(wù)，許多公司還開發(fā)了公共工具。

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