【編者按】

近幾年，隨著云計(jì)算技術(shù)的進(jìn)步和服務(wù)的增長(zhǎng)，微服務(wù)越來越成為在博客、媒體討論組和會(huì)議演講中出現(xiàn)的熱門話題，被更多的人重點(diǎn)關(guān)注。正如本文作者 51CTO博客專家孫杰在文中提到的，盡管微服務(wù)架構(gòu)存在著許多爭(zhēng)論，但這并不影響它正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實(shí)施提供著巨大的幫助的事實(shí)。究竟我們?yōu)槭裁葱枰⒎?wù)架構(gòu)？與傳統(tǒng)SOA相比，微服務(wù)架構(gòu)有哪些優(yōu)勢(shì)？在使用微服務(wù)架構(gòu)時(shí)，我們又將面臨哪些挑戰(zhàn)？

作者簡(jiǎn)介

　　孫杰，51CTO博客專家博主

孫杰，擁有超十二載IT領(lǐng)域工作經(jīng)驗(yàn)，先后在知名外企、電商平臺(tái)和國企能源行業(yè)的數(shù)據(jù)中心從事IT系統(tǒng)架構(gòu)搭建、云計(jì)算、大數(shù)據(jù)架構(gòu)部署及運(yùn)維等工作。熱愛技術(shù)喜歡分享，崇尚大道至簡(jiǎn)。在若干大中型項(xiàng)目的建設(shè)和運(yùn)維中，積累了豐富的系統(tǒng)運(yùn)維、架構(gòu)設(shè)計(jì)、平臺(tái)優(yōu)化等經(jīng)驗(yàn)。在博客平臺(tái)發(fā)布了大量IT技術(shù)和生活文章，并成為51CTO平臺(tái)上的專家博主。

如何理解微服務(wù)

微服務(wù)這一概念出現(xiàn)于2012年，是因軟件作者M(jìn)artin Fowler而流行，圍繞業(yè)務(wù)、自動(dòng)化部署、終端智能以及語言和數(shù)據(jù)的分散控制有一些常見的新特性。微服務(wù)也是一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)。隨著云計(jì)算技術(shù)的進(jìn)步和服務(wù)的增長(zhǎng)，微服務(wù)架構(gòu)越來越多的受到了人們的關(guān)注。盡管也存在著許多不同的爭(zhēng)論，微服務(wù)架構(gòu)模式卻正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實(shí)施提供著巨大的幫助。

通常我們的開發(fā)也是模塊化設(shè)計(jì)邏輯，程序完成后會(huì)打包并部署為一個(gè)個(gè)具體的應(yīng)用。每個(gè)具體的格式依賴于相應(yīng)的應(yīng)用語言和框架。例如，Java應(yīng)用通常會(huì)被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應(yīng)用會(huì)被打包成自包含的JAR格式，同樣，Rails和Node.js會(huì)被打包成層級(jí)目錄。這種應(yīng)用開發(fā)風(fēng)格很常見，也很易于調(diào)試，只需要簡(jiǎn)單運(yùn)行此應(yīng)用，用些工具鏈接UI就可以完成端到端測(cè)試。打包好的應(yīng)用拷貝到服務(wù)器端，通過在負(fù)載均衡器后端運(yùn)行多個(gè)拷貝就可以輕松實(shí)現(xiàn)應(yīng)用擴(kuò)展。在早期這類應(yīng)用運(yùn)行的都很好，但一個(gè)簡(jiǎn)單的應(yīng)用會(huì)隨著時(shí)間推移逐漸變大。幾年后，這個(gè)小而簡(jiǎn)單的應(yīng)用會(huì)變成了一個(gè)巨大的怪物。一旦你的應(yīng)用變成一個(gè)龐大而又復(fù)雜的怪物，那開發(fā)團(tuán)隊(duì)肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個(gè)應(yīng)用太復(fù)雜，以至于任何單個(gè)開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能將變的非常困難，并且很耗時(shí)。

當(dāng)一個(gè)應(yīng)用越大，啟動(dòng)時(shí)間就會(huì)越長(zhǎng)。那么大部分時(shí)間就要在等待中渡過，生產(chǎn)效率會(huì)受到極大影響。

另外，一個(gè)應(yīng)用在不同模塊發(fā)生資源沖突時(shí)，擴(kuò)展將會(huì)非常困難。應(yīng)用的另外一個(gè)問題是可靠性。當(dāng)所有模塊都運(yùn)行在一個(gè)進(jìn)程中，任何一個(gè)模塊中的一個(gè)bug，比如內(nèi)存泄露，將會(huì)有可能弄垮整個(gè)進(jìn)程。除此之外，因?yàn)樗袘?yīng)用實(shí)例都是唯一的，這個(gè)bug將會(huì)影響到整個(gè)應(yīng)用的可靠性。

如果采用微服務(wù)處理結(jié)構(gòu)模式則可以很好的解決上述問題。微服務(wù)架構(gòu)的思想不是開發(fā)一個(gè)復(fù)雜巨大的應(yīng)用，而是將應(yīng)用分解為若干小的、互相連接的微服務(wù)。

　　六大優(yōu)勢(shì)

微服務(wù)架構(gòu)相對(duì)于傳統(tǒng)的SOA，優(yōu)勢(shì)也很明顯：

1、復(fù)雜度可控：在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無止境的積累。每一個(gè)微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個(gè)微服務(wù)可由一個(gè)小規(guī)模開發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開發(fā)效率。

2、獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無需編譯、部署整個(gè)應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。

3、技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個(gè)微服務(wù)相對(duì)簡(jiǎn)單，當(dāng)需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)較低，甚至完全重構(gòu)一個(gè)微服務(wù)也是可行的。

4、容錯(cuò)：當(dāng)某一組建發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。

5、擴(kuò)展：?jiǎn)螇K架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展。

6、功能特定：一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如消息管理、客戶管理等等。每一個(gè)微服務(wù)都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會(huì)發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個(gè)Web UI，運(yùn)行時(shí)，每一個(gè)實(shí)例可能是一個(gè)云VM或者是Docker容器。

三大挑戰(zhàn)

1.固有的復(fù)雜性：微服務(wù)架構(gòu)有很多優(yōu)點(diǎn)，當(dāng)然也有其不足。比如微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

2.分區(qū)的數(shù)據(jù)庫架構(gòu)：另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。在商業(yè)交易系統(tǒng)中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對(duì)于單個(gè)應(yīng)用來說很容易，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫。而在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

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

使用微服務(wù)構(gòu)建適合云的新型應(yīng)用是很有意義的，因?yàn)樗屇慵壤昧藱M向擴(kuò)展架構(gòu)，也利用了縱向擴(kuò)展架構(gòu)，還額外得到API的組合，且在整個(gè)業(yè)務(wù)中可重復(fù)利用?？赡茉诿恳环昼姸荚诮桓缎路?wù)，這樣你就會(huì)擁有一個(gè)敏捷的且即時(shí)響應(yīng)的應(yīng)用程序平臺(tái)，當(dāng)然這一平臺(tái)一直在不斷改進(jìn)中，微服務(wù)架構(gòu)也在前進(jìn)著。

主要周邊技術(shù)

云VM

DOCKER容器

微服務(wù)架構(gòu)與SOA

微服務(wù)與分布式

微服務(wù)與數(shù)據(jù)一致性

微服務(wù)與數(shù)據(jù)庫

微服務(wù)與PAAS

微服務(wù)與自動(dòng)化部署

微服務(wù)與Mesos或者Kubernetes

微服務(wù)層面如何提供緩存、權(quán)限控制、API統(tǒng)計(jì)和監(jiān)控