微服務(wù)是什么？它的優(yōu)缺點(diǎn)有哪些？

“微服務(wù)”一詞來源于 Martin Fowler 的《Microservices》一文。微服務(wù)是一種架構(gòu)風(fēng)格，即將單體應(yīng)用劃分為小型的服務(wù)單元，微服務(wù)之間使用 HTTP 的 API 進(jìn)行資源訪問與操作。

在筆者看來，微服務(wù)架構(gòu)的演變更像是一個(gè)公司的發(fā)展過程，從最開始的小公司，到后來的大集團(tuán)。大集團(tuán)可拆分出多個(gè)子公司，每個(gè)子公司的都有自己獨(dú)立的業(yè)務(wù)、員工，各自發(fā)展，互不影響，合起來則是威力無窮。

臃腫的系統(tǒng)、重復(fù)的代碼、超長的啟動(dòng)時(shí)間帶給開發(fā)人員的只有無限的埋怨，絲毫沒有那種很舒服的、很流暢的寫代碼的感覺。他們把大部分時(shí)間都花在解決問題和項(xiàng)目啟動(dòng)上面了。

微服務(wù)架構(gòu)的優(yōu)勢

使用微服務(wù)架構(gòu)能夠?yàn)槲覀儙砣缦潞锰?#xff1a;

1）服務(wù)的獨(dú)立部署

每個(gè)服務(wù)都是一個(gè)獨(dú)立的項(xiàng)目，可以獨(dú)立部署，不依賴于其他服務(wù)，耦合性低。

2）服務(wù)的快速啟動(dòng)

拆分之后服務(wù)啟動(dòng)的速度必然要比拆分之前快很多，因?yàn)橐蕾嚨膸焐倭?#xff0c;代碼量也少了。

3）更加適合敏捷開發(fā)

敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行。服務(wù)拆分可以快速發(fā)布新版本，修改哪個(gè)服務(wù)只需要發(fā)布對應(yīng)的服務(wù)即可，不用整體重新發(fā)布。

4）職責(zé)專一，由專門的團(tuán)隊(duì)負(fù)責(zé)專門的服務(wù)

業(yè)務(wù)發(fā)展迅速時(shí)，研發(fā)人員也會(huì)越來越多，每個(gè)團(tuán)隊(duì)可以負(fù)責(zé)對應(yīng)的業(yè)務(wù)線，服務(wù)的拆分有利于團(tuán)隊(duì)之間的分工。

5）服務(wù)可以動(dòng)態(tài)按需擴(kuò)容

當(dāng)某個(gè)服務(wù)的訪問量較大時(shí)，我們只需要將這個(gè)服務(wù)擴(kuò)容即可。

6）代碼的復(fù)用

每個(gè)服務(wù)都提供 REST API，所有的基礎(chǔ)服務(wù)都必須抽出來，很多的底層實(shí)現(xiàn)都可以以接口方式提供。

微服務(wù)架構(gòu)的劣勢

微服務(wù)其實(shí)是一把雙刃劍，既然有利必然也會(huì)有弊。下面我們來談?wù)勎⒎?wù)有哪些弊端，以及能采取什么辦法避免。

1）分布式部署，調(diào)用的復(fù)雜性高

單體應(yīng)用的時(shí)候，所有模塊之前的調(diào)用都是在本地進(jìn)行的，在微服務(wù)中，每個(gè)模塊都是獨(dú)立部署的，通過 HTTP 來進(jìn)行通信，這當(dāng)中會(huì)產(chǎn)生很多問題，比如網(wǎng)絡(luò)問題、容錯(cuò)問題、調(diào)用關(guān)系等。

2）獨(dú)立的數(shù)據(jù)庫，分布式事務(wù)的挑戰(zhàn)

每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫，這就是所謂的去中心化的數(shù)據(jù)管理。這種模式的優(yōu)點(diǎn)在于不同的服務(wù)，可以選擇適合自身業(yè)務(wù)的數(shù)據(jù)，比如訂單服務(wù)可以用?MySQL、評(píng)論服務(wù)可以用 Mongodb、商品搜索服務(wù)可以用 Elasticsearch。

缺點(diǎn)就是事務(wù)的問題了，目前最理想的解決方案就是柔性事務(wù)中的最終一致性，后面的章節(jié)會(huì)給大家做具體介紹。

3）測試的難度提升

服務(wù)和服務(wù)之間通過接口來交互，當(dāng)接口有改變的時(shí)候，對所有的調(diào)用方都是有影響的，這時(shí)自動(dòng)化測試就顯得非常重要了，如果要靠人工一個(gè)個(gè)接口去測試，那工作量就太大了。這里要強(qiáng)調(diào)一點(diǎn)，就是 API 文檔的管理尤為重要。

4）運(yùn)維難度的提升

在采用傳統(tǒng)的單體應(yīng)用時(shí)，我們可能只需要關(guān)注一個(gè) Tomcat 的集群、一個(gè) MySQL 的集群就可以了，但這在微服務(wù)架構(gòu)下是行不通的。當(dāng)業(yè)務(wù)增加時(shí)，服務(wù)也將越來越多，服務(wù)的部署、監(jiān)控將變得非常復(fù)雜，這個(gè)時(shí)候?qū)τ谶\(yùn)維的要求就高了。

總結(jié)

以上是生活随笔為你收集整理的《springcloud超级入门》微服务的概念和优缺点《一》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。