作為一種在云服務中部署應用的新技術(shù)，微服務架構(gòu)目前保持著很高的行業(yè)熱度。中培偉業(yè)作為國內(nèi)領(lǐng)先的IT培訓機構(gòu)，為此精心打造了《IT項目管理最佳實踐》培訓課程，該課程培訓專家蔣老師在這里就微服務架構(gòu)的利弊進行了詳細介紹。

微服務架構(gòu)的好處

微服務架構(gòu)模式有很多好處。首先，通過分解巨大單體式應用為多個服務方法解決了復雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界。微服務架構(gòu)模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案，由此，單個服務很容易開發(fā)、理解和維護。

第二，這種架構(gòu)使得每個服務都可以有專門開發(fā)團隊來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術(shù)選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項目開始時采用的過時技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因為服務都是相對簡單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

第三，微服務架構(gòu)模式是每個微服務獨立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以采用AB測試，快速的部署變化。微服務架構(gòu)模式使得持續(xù)化部署成為可能。

最后，微服務架構(gòu)模式使得每個服務獨立擴展。你可以根據(jù)每個服務的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務資源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內(nèi)存數(shù)據(jù)庫。

微服務架構(gòu)的不足

Fred Brooks在30年前寫道，“there are no silver bullets”，像任何其它科技一樣，微服務架構(gòu)也有不足。其中一個跟他的名字類似，『微服務』強調(diào)了服務大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務組。盡管小服務更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署。

另外一個主要的不足是，微服務應用是分布式系統(tǒng)，由此會帶來固有的復雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什么難事，但相對于單體式應用中通過語言層級的方法或者進程調(diào)用，微服務下這種技術(shù)顯得更復雜一些。

另外一個關(guān)于微服務的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務架構(gòu)應用中，需要更新不同服務所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務架構(gòu)的應用也是很復雜的任務。比如，采用流行的Spring Boot架構(gòu)，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，同樣的服務測試需要啟動和它有關(guān)的所有服務(至少需要這些服務的stubs)。再重申一次，不能低估了采用微服務架構(gòu)帶來的復雜性。

另外一個挑戰(zhàn)在于，微服務架構(gòu)模式應用的改變將會波及多個服務。比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務架構(gòu)模式就需要考慮相關(guān)改變對不同服務的影響。比如，你需要更新服務C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務，而需要協(xié)調(diào)多服務的改變很少。

部署一個微服務應用也很復雜，一個分布式應用只需要簡單在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務。相對比，一個微服務應用一般由大批服務構(gòu)成。例如，根據(jù)Adrian Cockcroft，Hailo有160個不同服務構(gòu)成，NetFlix 有大約600個服務。每個服務都有多個實例。這就造成許多需要配置、部署、擴展和監(jiān)控的部分，除此之外，你還需要完成一個服務發(fā)現(xiàn)機制(后續(xù)文章中發(fā)表)，以用來發(fā)現(xiàn)與它通訊服務的地址(包括服務器地址和端口)。傳統(tǒng)的解決問題辦法不能用于解決這么復雜的問題。接續(xù)而來，成功部署一個微服務應用需要開發(fā)者有足夠的控制部署方法，并高度自動化。

一種自動化方法是使用PaaS服務，例如Cloud Foundry。 PaaS給開發(fā)者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包內(nèi)置解決了。同時，配置PaaS的系統(tǒng)和網(wǎng)絡專家可以采用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務應用的方法是開發(fā)對于你來說最基礎(chǔ)的PaaS系統(tǒng)。一個典型的開始點是使用一個集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我們會看看如何基于軟件部署方法例如NGINX，可以方便的在微服務層面提供緩存、權(quán)限控制、API統(tǒng)計和監(jiān)控。

想了解更多IT資訊，請訪問中培偉業(yè)官網(wǎng)：中培偉業(yè)