我們?yōu)槭裁葱枰⒎?wù)架構(gòu)
原創(chuàng)【編者按】
近幾年，隨著云計算技術(shù)的進(jìn)步和服務(wù)的增長，微服務(wù)越來越成為在博客、媒體討論組和會議演講中出現(xiàn)的熱門話題，被更多的人重點關(guān)注。正如本文作者 51CTO博客專家孫杰在文中提到的，盡管微服務(wù)架構(gòu)存在著許多爭論，但這并不影響它正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實施提供著巨大的幫助的事實。究竟我們?yōu)槭裁葱枰⒎?wù)架構(gòu)？與傳統(tǒng)SOA相比，微服務(wù)架構(gòu)有哪些優(yōu)勢？在使用微服務(wù)架構(gòu)時，我們又將面臨哪些挑戰(zhàn)？
作者簡介
孫杰，51CTO博客專家博主
孫杰，擁有超十二載IT領(lǐng)域工作經(jīng)驗，先后在知名外企、電商平臺和國企能源行業(yè)的數(shù)據(jù)中心從事IT系統(tǒng)架構(gòu)搭建、云計算、大數(shù)據(jù)架構(gòu)部署及運(yùn)維等工作。熱愛技術(shù)喜歡分享，崇尚大道至簡。在若干大中型項目的建設(shè)和運(yùn)維中，積累了豐富的系統(tǒng)運(yùn)維、架構(gòu)設(shè)計、平臺優(yōu)化等經(jīng)驗。在博客平臺發(fā)布了大量IT技術(shù)和生活文章，并成為51CTO平臺上的專家博主。
如何理解微服務(wù)
微服務(wù)這一概念出現(xiàn)于2012年，是因軟件作者M(jìn)artin Fowler而流行，圍繞業(yè)務(wù)、自動化部署、終端智能以及語言和數(shù)據(jù)的分散控制有一些常見的新特性。微服務(wù)也是一項在云中部署應(yīng)用和服務(wù)的新技術(shù)。隨著云計算技術(shù)的進(jìn)步和服務(wù)的增長，微服務(wù)架構(gòu)越來越多的受到了人們的關(guān)注。盡管也存在著許多不同的爭論，微服務(wù)架構(gòu)模式卻正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實施提供著巨大的幫助。
通常我們的開發(fā)也是模塊化設(shè)計邏輯，程序完成后會打包并部署為一個個具體的應(yīng)用。每個具體的格式依賴于相應(yīng)的應(yīng)用語言和框架。例如，Java應(yīng)用通常會被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應(yīng)用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。這種應(yīng)用開發(fā)風(fēng)格很常見，也很易于調(diào)試，只需要簡單運(yùn)行此應(yīng)用，用些工具鏈接UI就可以完成端到端測試。打包好的應(yīng)用拷貝到服務(wù)器端，通過在負(fù)載均衡器后端運(yùn)行多個拷貝就可以輕松實現(xiàn)應(yīng)用擴(kuò)展。在早期這類應(yīng)用運(yùn)行的都很好，但一個簡單的應(yīng)用會隨著時間推移逐漸變大。幾年后，這個小而簡單的應(yīng)用會變成了一個巨大的怪物。一旦你的應(yīng)用變成一個龐大而又復(fù)雜的怪物，那開發(fā)團(tuán)隊肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個應(yīng)用太復(fù)雜，以至于任何單個開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能將變的非常困難，并且很耗時。
當(dāng)一個應(yīng)用越大，啟動時間就會越長。那么大部分時間就要在等待中渡過，生產(chǎn)效率會受到極大影響。
另外，一個應(yīng)用在不同模塊發(fā)生資源沖突時，擴(kuò)展將會非常困難。應(yīng)用的另外一個問題是可靠性。當(dāng)所有模塊都運(yùn)行在一個進(jìn)程中，任何一個模塊中的一個bug，比如內(nèi)存泄露，將會有可能弄垮整個進(jìn)程。除此之外，因為所有應(yīng)用實例都是唯一的，這個bug將會影響到整個應(yīng)用的可靠性。
如果采用微服務(wù)處理結(jié)構(gòu)模式則可以很好的解決上述問題。微服務(wù)架構(gòu)的思想不是開發(fā)一個復(fù)雜巨大的應(yīng)用，而是將應(yīng)用分解為若干小的、互相連接的微服務(wù)。
六大優(yōu)勢
微服務(wù)架構(gòu)相對于傳統(tǒng)的SOA，優(yōu)勢也很明顯：
1、復(fù)雜度可控：在將應(yīng)用分解的同時，規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個微服務(wù)可由一個小規(guī)模開發(fā)團(tuán)隊完全掌控，易于保持高可維護(hù)性和開發(fā)效率。
2、獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個微服務(wù)也可以獨(dú)立部署。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風(fēng)險，最終縮短應(yīng)用交付周期。
3、技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個團(tuán)隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單，當(dāng)需要對技術(shù)棧進(jìn)行升級時所面臨的風(fēng)險較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。
4、容錯：當(dāng)某一組建發(fā)生故障時，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機(jī)制實現(xiàn)應(yīng)用層面的容錯。
5、擴(kuò)展：單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴(kuò)展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨(dú)立進(jìn)行擴(kuò)展。
6、功能特定：一個微服務(wù)一般完成某個特定的功能，比如消息管理、客戶管理等等。每一個微服務(wù)都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個Web UI，運(yùn)行時，每一個實例可能是一個云VM或者是Docker容器。
三大挑戰(zhàn)
1.固有的復(fù)雜性：微服務(wù)架構(gòu)有很多優(yōu)點，當(dāng)然也有其不足。比如微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。
2.分區(qū)的數(shù)據(jù)庫架構(gòu)：另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。在商業(yè)交易系統(tǒng)中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單個應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。而在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。
3.波及多個服務(wù)：***一個問題在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個項目案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單個應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。相比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，***才是A，幸運(yùn)的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。
使用微服務(wù)構(gòu)建適合云的新型應(yīng)用是很有意義的，因為它讓你既利用了橫向擴(kuò)展架構(gòu)，也利用了縱向擴(kuò)展架構(gòu)，還額外得到API的組合，且在整個業(yè)務(wù)中可重復(fù)利用。可能在每一分鐘都在交付新服務(wù)，這樣你就會擁有一個敏捷的且即時響應(yīng)的應(yīng)用程序平臺，當(dāng)然這一平臺一直在不斷改進(jìn)中，微服務(wù)架構(gòu)也在前進(jìn)著。
主要周邊技術(shù)
- 云VM
- DOCKER容器
- 微服務(wù)架構(gòu)與SOA
- 微服務(wù)與分布式
- 微服務(wù)與數(shù)據(jù)一致性
- 微服務(wù)與數(shù)據(jù)庫
- 微服務(wù)與PAAS
- 微服務(wù)與自動化部署
- 微服務(wù)與Mesos或者Kubernetes
- 微服務(wù)層面如何提供緩存、權(quán)限控制、API統(tǒng)計和監(jiān)控
