什么是微服務？關于輕量級軟件開發的詮釋

Lucas Carlson 陳琳華

使用微服務架構將大型應用程序分解為可橫向擴展的輕量級應用程序。

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

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

解決方案是殺死那些單體大型應用程序，并且不再創建新的類似應用程序。實現的方法是使用微服務架構，這種技術可將大型應用程序分解為可以橫向擴展的輕量級應用程序。

微服務定義

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

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

微服務的好處

微服務架構將內部架構非常復雜的大型單體應用程序分解成小型的可獨立擴展的應用程序。每個微服務都很小，開發、更新和部署也不太復雜。

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

圍繞微服務架構進行開發可獲得一些隱性優勢，例如可與PaaS、Docker和Linux容器等新技術緊密結合。

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

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

微服務的挑戰

但每個架構都有優點和缺點。雖然優點明顯，但是微服務架構也帶來了一系列難以解決的新問題——特別是記錄、監控、測試和調試去中心化且松散耦合的新應用程序

如果有一個漏洞，那么哪個微服務應當對此負責呢？微服務之間的相互依存關系使得這個問題很難回答。微服務通常通過輕量級JSON REST API彼此通信。與其前身XML-RPC和SOAP不同的地方是，REST接口的定義正變得越來越松散。雖然這些輕量級API更靈活，更容易擴展，但是它們增加了需要監控的新接口，這可能會產生中斷破壞或導致出現漏洞。

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

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

微服務與容器和PaaS的關系

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

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

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

同樣，Linux容器也非常適合如微服務等小型無狀態應用程序，而不是大型的單體應用程序。

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

微服務架構的橫向擴展理念促進了無共享、無狀態應用程序的概念。它們不存儲或修改底層文件系統。為什么人們將微服務與Linux容器容易混為一談呢？原因在于兩者都不保留狀態。

微服務與SOA的關系

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

同樣，SOA使用企業服務總線，而微服務使用更輕量級的發布-訂閱服務總線。 盡管后者更為輕便但是原理是相似的。

微服務架構和SOA之間的最大區別在于微服務必須可獨立部署，而SOA服務則通常在部署整體中實現。

微服務是否適合你？

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

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

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

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

如果你的大型應用程序正在失控但軟件生命周期還有很長時間，創新速度也已經停滯不前，那么微服務可能正是你需要的東西?；蛘撸绻銊倓傞_始起步，那么從一開始就考慮構建基于微服務的應用程序是非常明智的。

eBay表示，微服務架構讓他們具備了進行大規模擴展的能力，提高了代碼的可擴展性和可維護性，促進了快速業務創新，創建了更快的產品交付模式，甚至連安全性也得到了增強。谷歌、亞馬遜、推特、PayPal和Netflix都有類似的體驗。 為了更便捷地部署微服務，許多公司還開發了公共工具。

無論你是遇到了維護遺留代碼的問題并且一籌莫展，還是已經開始使用全新的應用程序，現在正是嘗試用微服務方式進行應用程序開發的好時機。