微服務(wù)架構(gòu)優(yōu)缺點

隨著DevOps、持續(xù)交付等理念的深入人心，微服務(wù)架構(gòu)開始走進(jìn)我們的視野。

那么微服務(wù)是業(yè)界期待已久的解決方案么？或者說微服務(wù)要比整體解決方案更加簡單？

讓我們先對微服務(wù)下個定義：

微服務(wù)是用一組小服務(wù)的方式來構(gòu)建一個應(yīng)用，服務(wù)獨立運行在不同的進(jìn)程中，服務(wù)之間通過輕量的通訊機(jī)制（如RESTful接口）來交互，并且服務(wù)可以通過自動化部署方式獨立部署。正因為微服務(wù)架構(gòu)中，服務(wù)之間是相互獨立的，所以不同的服務(wù)可以使用不同的語言來開發(fā)，或者根據(jù)業(yè)務(wù)的需求使用不同類型的數(shù)據(jù)庫。

來自ThoughtWorks的James Lewis和Martin Fowler分享了他們對微服務(wù)架構(gòu)的理解以及看法。文章中作者詳細(xì)介紹了微服務(wù)的特點以及相對于傳統(tǒng)架構(gòu)的微服務(wù)架構(gòu)的優(yōu)勢。

微服務(wù)的一些優(yōu)勢是顯而易見的：

1. 服務(wù)簡單，只關(guān)注一個業(yè)務(wù)功能 
   在James看來，傳統(tǒng)的整體風(fēng)格的架構(gòu)在構(gòu)建部署和擴(kuò)展伸縮方面有很大的局限性，其服務(wù)端應(yīng)用就像是一塊鐵板，笨重且不可拆分，系統(tǒng)中任何程序的改變都需要整個應(yīng)用重新構(gòu)建和部署新版本。在進(jìn)行水平擴(kuò)展時也只能整個系統(tǒng)擴(kuò)展，而不能針對某一個功能模塊進(jìn)行擴(kuò)展。 
   而微服務(wù)架構(gòu)將系統(tǒng)以組件化的方式分解為多個服務(wù)，服務(wù)之間相對獨立且松耦合，單一功能的改變只需要重新構(gòu)建部署相應(yīng)的服務(wù)即可。

2. 每個微服務(wù)可由不同團(tuán)隊開發(fā) 
   傳統(tǒng)的開發(fā)模式在分工時往往以技術(shù)為單位，比如UI團(tuán)隊、服務(wù)端團(tuán)隊和數(shù)據(jù)庫團(tuán)隊，這樣的分工可能會導(dǎo)致任何功能上的改變都需要跨團(tuán)隊溝通和協(xié)調(diào)。而微服務(wù)則倡導(dǎo)圍繞服務(wù)來分工，不同的服務(wù)可以采用不同的技術(shù)來實現(xiàn)，一個團(tuán)隊中應(yīng)該包含開發(fā)所需的所有技能，比如用戶體驗、數(shù)據(jù)庫、項目管理。

3. 微服務(wù)是松散耦合的 
   微服務(wù)架構(gòu)拋棄了ESB復(fù)雜的業(yè)務(wù)規(guī)則編排、消息路由等功能，微服務(wù)架構(gòu)中服務(wù)是高內(nèi)聚的，每個服務(wù)都會處理相應(yīng)的業(yè)務(wù)，所有的業(yè)務(wù)邏輯應(yīng)該盡量在服務(wù)內(nèi)部處理，且服務(wù)間的通信盡可能的輕量化，比如使用Restful的方式。

4. 可用不同的編程語言與工具開發(fā) 
   傳統(tǒng)的軟件開發(fā)中經(jīng)常會使用同一個技術(shù)平臺來解決所有的問題，而經(jīng)驗表明使用合適的工具做合適的事情會讓開發(fā)變得事半功倍。微服務(wù)架構(gòu)天生就具有這樣的特性，我們可以使用Node.js來開發(fā)一個簡單的報表頁面，使用C++來編寫一個實時聊天組件。

微服務(wù)架構(gòu)的引入為多樣化持久保存數(shù)據(jù)提供可能，持久層可以使用傳統(tǒng)關(guān)系數(shù)據(jù)庫和NoSQL。不同于傳統(tǒng)的應(yīng)用，微服務(wù)架構(gòu)中，我們可以為每個服務(wù)選擇一個新的適合業(yè)務(wù)邏輯的數(shù)據(jù)庫系統(tǒng)，比如MongoDB、PostgreSQL。這樣做的好處是顯而易見的，首先我們可以根據(jù)業(yè)務(wù)類型（讀多還是寫多等）來決定使用哪種類型的數(shù)據(jù)庫，其次這樣可以減小單個數(shù)據(jù)庫的負(fù)載。James的文章在社區(qū)引起了廣泛的討論，Contino公司的CTO Benjamin Wootton撰文表示微服務(wù)并沒有想象中的那么好，并建議開發(fā)者在選用此架構(gòu)時一定要慎重。Benjamin認(rèn)為微服務(wù)架構(gòu)時可能會面臨下面一些挑戰(zhàn)：

1. 運維開銷 
   更多的服務(wù)也就意味著更多的運維，產(chǎn)品團(tuán)隊需要保證所有的相關(guān)服務(wù)都有完善的監(jiān)控等基礎(chǔ)設(shè)施，傳統(tǒng)的架構(gòu)開發(fā)者只需要保證一個應(yīng)用正常運行，而現(xiàn)在卻需要保證幾十甚至上百道工序高效運轉(zhuǎn)，這是一個艱巨的任務(wù)。

2. DevOps要求 
   使用微服務(wù)架構(gòu)后，開發(fā)團(tuán)隊需要保證一個Tomcat集群可用，保證一個數(shù)據(jù)庫可用，這就意味著團(tuán)隊需要高品質(zhì)的DevOps和自動化技術(shù)。而現(xiàn)在，這樣的全棧式人才很少。

3. 隱式接口 
   服務(wù)和服務(wù)之間通過接口來“聯(lián)系”，當(dāng)某一個服務(wù)更改接口格式時，可能涉及到此接口的所有服務(wù)都需要做調(diào)整。

4. 重復(fù)勞動 
   在很多服務(wù)中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務(wù)的程度，這個時候可能不同的服務(wù)團(tuán)隊都會單獨開發(fā)這一功能，重復(fù)的業(yè)務(wù)邏輯，這違背了良好的軟件工程中的很多原則。

5. 分布式系統(tǒng)的復(fù)雜性 
   微服務(wù)通過REST API或消息來將不同的服務(wù)聯(lián)系起來，這在之前可能只是一個簡單的遠(yuǎn)程過程調(diào)用。分布式系統(tǒng)也就意味著開發(fā)者需要考慮網(wǎng)絡(luò)延遲、容錯、消息序列化、不可靠的網(wǎng)絡(luò)、異步、版本控制、負(fù)載等，而面對如此多的微服務(wù)都需要分布式時，整個產(chǎn)品需要有一整套完整的機(jī)制來保證各個服務(wù)可以正常運轉(zhuǎn)。

6. 事務(wù)、異步、測試面臨挑戰(zhàn) 
   跨進(jìn)程之間的事務(wù)、大量的異步處理、多個微服務(wù)之間的整體測試都需要有一整套的解決方案，而現(xiàn)在看起來，這些技術(shù)并沒有成熟。

總而言之，微服務(wù)架構(gòu)有很多吸引人的地方，不過在擁抱微服務(wù)之前要認(rèn)清它所帶來的挑戰(zhàn)。而每一種架構(gòu)都有其優(yōu)缺點，我們需要根據(jù)項目業(yè)務(wù)和團(tuán)隊情況來選擇合適的架構(gòu)。

更多內(nèi)容請關(guān)注微信公眾號：it_haha