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

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

在筆者看來，微服務(wù)架構(gòu)的演變更像是一個公司的發(fā)展過程，從最開始的小公司，到后來的大集團。大集團可拆分出多個子公司，每個子公司的都有自己獨立的業(yè)務(wù)、員工，各自發(fā)展，互不影響，合起來則是威力無窮。臃腫的系統(tǒng)、重復(fù)的代碼、超長的啟動時間帶給開發(fā)人員的只有無限的埋怨，絲毫沒有那種很舒服的、很流暢的寫代碼的感覺。他們把大部分時間都花在解決問題和項目啟動上面了。

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

使用微服務(wù)架構(gòu)能夠為我們帶來如下好處：

1.服務(wù)的獨立部署

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

2.服務(wù)的快速啟動

拆分之后服務(wù)啟動的速度必然要比拆分之前快很多，因為依賴的庫少了，代碼量也少了。

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

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

4.職責(zé)專一，由專門的團隊負(fù)責(zé)專門的服務(wù)

企業(yè)網(wǎng)站設(shè)計,業(yè)務(wù)發(fā)展迅速時，研發(fā)人員也會越來越多，每個團隊可以負(fù)責(zé)對應(yīng)的業(yè)務(wù)線，服務(wù)的拆分有利于團隊之間的分工。

5.服務(wù)可以動態(tài)按需擴容

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

6.代碼的復(fù)用

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

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

對于網(wǎng)站建設(shè)公司來說，微服務(wù)其實是一把雙刃劍，既然有利必然也會有弊。下面我們來談?wù)勎⒎?wù)有哪些弊端，以及能采取什么辦法避免。

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

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

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

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

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

3.測試的難度提升

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

4.運維難度的提升

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