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

這篇文章的知識(shí)點(diǎn)包括：微服務(wù)的概念、微服務(wù)的優(yōu)缺點(diǎn)、微服務(wù)的架構(gòu)以及微服務(wù)的使用示例，閱讀完整文相信大家對微服務(wù)會(huì)有一定的認(rèn)識(shí)。

10多年的文峰網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整文峰建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)公司從事“文峰網(wǎng)站設(shè)計(jì)”,“文峰網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

什么是微服務(wù)

• 微服務(wù) (Microservices) 是一種軟件架構(gòu)風(fēng)格，將應(yīng)用程序構(gòu)造為圍繞業(yè)務(wù)的小型自治服務(wù)的集合

• 微服務(wù)以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ)。每個(gè)服務(wù)都是獨(dú)立的，并實(shí)現(xiàn)單個(gè)業(yè)務(wù)功能

• 微服務(wù)利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān)的 API 集相互通信

• 微服務(wù)運(yùn)用了以業(yè)務(wù)功能為主導(dǎo)的設(shè)計(jì)概念，應(yīng)用程序在設(shè)計(jì)時(shí)就能先以業(yè)務(wù)功能或流程設(shè)計(jì)先行分割，將各個(gè)業(yè)務(wù)功能都獨(dú)立實(shí)現(xiàn)成一個(gè)能自主運(yùn)行的個(gè)體服務(wù)，然后再利用相同的協(xié)議將所有應(yīng)用程序需要的服務(wù)都組合起來，形成一個(gè)應(yīng)用程序

微服務(wù)例子1

• 以購物車應(yīng)用程序?yàn)槔?dāng)打開購物車應(yīng)用程序時(shí)，您看到的只是一個(gè)網(wǎng)站。但是，在后臺(tái)，購物車應(yīng)用程序具有用于接受付款服務(wù)，客戶服務(wù)等

• 假設(shè)此應(yīng)用程序的開發(fā)人員使用了單體框架，架構(gòu)如下圖

• 如圖，在單體架構(gòu)中，所有功能都放在一個(gè)代碼庫中，并在一個(gè)基礎(chǔ)數(shù)據(jù)庫下

• 現(xiàn)在，假設(shè)市場上出現(xiàn)了一個(gè)新品牌，并且開發(fā)人員希望將即將到來的品牌的所有詳細(xì)信息放入此應(yīng)用程序中

• 此時(shí)，不僅需要處理新品牌的服務(wù)，而且還必須重新構(gòu)建整個(gè)系統(tǒng)并相應(yīng)地進(jìn)行部署。為了避免此類挑戰(zhàn)，開發(fā)人員決定將其應(yīng)用程序從單體架構(gòu)轉(zhuǎn)換為微服務(wù)

• 開發(fā)人員為搜索，推薦，客戶服務(wù)等創(chuàng)建了單獨(dú)的微服務(wù)

• 此微服務(wù)架構(gòu)不僅可以幫助開發(fā)人員克服以前的架構(gòu)所面臨的所有挑戰(zhàn)，而且還可以輕松地構(gòu)建，部署和擴(kuò)展購物車應(yīng)用程序

微服務(wù)例子2

• 以旅游行業(yè)應(yīng)用程序?yàn)槔?br/>

• 整體服務(wù)包括了旅客關(guān)系管理、付款、消息通知等服務(wù)

• 傳統(tǒng)的單體常常采用如上圖所示的整體式架構(gòu)，并采取MVC的設(shè)計(jì)模式

• 三層架構(gòu)（MVC）的具體內(nèi)容如下

• 表示層（view）： 用戶使用應(yīng)用程序時(shí)，看到的、聽見的、輸入的或者交互的部分。

• 業(yè)務(wù)邏輯層（controller）： 根據(jù)用戶輸入的信息，進(jìn)行邏輯計(jì)算或者業(yè)務(wù)處理的部分。

• 數(shù)據(jù)訪問層（model）： 關(guān)注有效地操作原始數(shù)據(jù)的部分，如將數(shù)據(jù)存儲(chǔ)到存儲(chǔ)介質(zhì)（如數(shù)據(jù)庫、文件系統(tǒng)）及

• 從存儲(chǔ)介質(zhì)中讀取數(shù)據(jù)等。

• 雖然現(xiàn)在程序被分成了三層，但只是邏輯上的分層，并不是物理上的分層。也就是說，對不同層的代碼而言，經(jīng)過編譯、打包和部署后，所有的代碼最終還是運(yùn)行在同一個(gè)進(jìn)程中
  單體架構(gòu)在規(guī)模比較小的情況下工作情況良好，但是隨著系統(tǒng)規(guī)模的擴(kuò)大，它暴露出來的問題也越來越多，主要有以下幾點(diǎn)：

• 復(fù)雜性逐漸變高

• 比如有的項(xiàng)目有幾十萬行代碼，各個(gè)模塊之間區(qū)別比較模糊，邏輯比較混亂，代碼越多復(fù)雜性越高，越難解決遇到的問題

• 技術(shù)債務(wù)逐漸上升

• 公司的人員流動(dòng)是再正常不過的事情，有的員工在離職之前，疏于代碼質(zhì)量的自我管束，導(dǎo)致留下來很多坑，由于單體項(xiàng)目代碼量龐大的驚人，留下的坑很難被發(fā)覺，這就給新來的員工帶來很大的煩惱，人員流動(dòng)越大所留下的坑越多，也就是所謂的技術(shù)債務(wù)越來越多

• 維護(hù)成本大

• 當(dāng)應(yīng)用程序的功能越來越多、團(tuán)隊(duì)越來越大時(shí)，溝通成本、管理成本顯著增加。當(dāng)出現(xiàn) bug 時(shí)，可能引起 bug 的原因組合越來越多，導(dǎo)致分析、定位和修復(fù)的成本增加；并且在對全局功能缺乏深度理解的情況下，容易在修復(fù)bug 時(shí)引入新的 bug

• 持續(xù)交付周期長

• 構(gòu)建和部署時(shí)間會(huì)隨著功能的增多而增加，任何細(xì)微的修改都會(huì)觸發(fā)部署流水線。新人培養(yǎng)周期長：新成員了解背景、熟悉業(yè)務(wù)和配置環(huán)境的時(shí)間越來越長

• 技術(shù)選型成本高

• 單塊架構(gòu)傾向于采用統(tǒng)一的技術(shù)平臺(tái)或方案來解決所有問題，如果后續(xù)想引入新的技術(shù)或框架，成本和風(fēng)險(xiǎn)都很大

• 可擴(kuò)展性差

• 隨著功能的增加，垂直擴(kuò)展的成本將會(huì)越來越大；而對于水平擴(kuò)展而言，因?yàn)樗写a都運(yùn)行在同一個(gè)進(jìn)程，沒辦法做到針對應(yīng)用程序的部分功能做獨(dú)立的擴(kuò)展

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

• 將上面的整體架構(gòu)改造為如上圖所示的微服務(wù)

• 來自不同設(shè)備的不同客戶端嘗試使用不同的服務(wù)，例如搜索，構(gòu)建，配置和其他管理功能

• 所有服務(wù)均根據(jù)其功能進(jìn)行分離，并進(jìn)一步分離為單個(gè)微服務(wù)

• 這些微服務(wù)具有自己的負(fù)載均衡和執(zhí)行環(huán)境以執(zhí)行其功能,并在其自己的數(shù)據(jù)庫中捕獲數(shù)據(jù)

• 微服務(wù)之間通過無狀態(tài)服務(wù)器(REST、GRPC或消息總線)進(jìn)行通信

• 微服務(wù)借助服務(wù)發(fā)現(xiàn)來了解其通信路徑并執(zhí)行自動(dòng)化，監(jiān)控等操作功能

• 微服務(wù)執(zhí)行的所有功能通過API網(wǎng)關(guān)傳達(dá)給客戶端

微服務(wù)特點(diǎn)

• 解耦

• 系統(tǒng)中的服務(wù)在很大程度上是解耦的。因此，整個(gè)應(yīng)用程序可以輕松構(gòu)建，更改和擴(kuò)展

• 組件化

• 微服務(wù)被視為獨(dú)立的組件，可以輕松替換和升級(jí)

• 專注業(yè)務(wù)功能

• 業(yè)務(wù)功能–微服務(wù)非常簡單，專注于單一功能

• 獨(dú)立自主

• 開發(fā)人員和團(tuán)隊(duì)可以彼此獨(dú)立地工作，從而提高了速度

• 持續(xù)交付

• 通過自動(dòng)化的構(gòu)建、測試和部署，允許頻繁發(fā)布軟件

• 分散治理

• 重點(diǎn)是使用正確的工具完成正確的工作。這意味著沒有標(biāo)準(zhǔn)化模式或任何技術(shù)模式。開發(fā)人員可以自由選擇最有用的工具來解決他們的問題

• 敏捷開發(fā)

• 微服務(wù)支持敏捷開發(fā)。任何新功能都可以快速開發(fā)并丟棄

微服務(wù)的優(yōu)點(diǎn)

• 單一職責(zé)

• 微服務(wù)架構(gòu)中的每個(gè)服務(wù)，都是具有業(yè)務(wù)邏輯的，符合高內(nèi)聚、低耦合原則以及單一職責(zé)原則的單元，不同的服務(wù)通過“管道”的方式靈活組合，從而構(gòu)建出龐大的系統(tǒng)

• 輕量級(jí)通信

• 服務(wù)之間通過輕量級(jí)的通信機(jī)制實(shí)現(xiàn)互通互聯(lián)，而所謂的輕量級(jí)，通常指語言無關(guān)、平臺(tái)無關(guān)的交互方式

• 對于輕量級(jí)通信的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關(guān)、平臺(tái)無關(guān)的；對于通信的協(xié)議而言，通?；?HTTP，能讓服務(wù)間的通信變得標(biāo)準(zhǔn)化、無狀態(tài)化。目前大家熟悉的 REST（Representational StateTransfer）、GRPC是實(shí)現(xiàn)服務(wù)間互相協(xié)作的輕量級(jí)通信機(jī)制之一。使用輕量級(jí)通信機(jī)制，可以讓團(tuán)隊(duì)選擇更適合的語言、工具或者平臺(tái)來開發(fā)服務(wù)本身

• 提高容錯(cuò)性（fault isolation），一個(gè)服務(wù)的內(nèi)存泄露并不會(huì)讓整個(gè)系統(tǒng)癱瘓

• 獨(dú)立性

• 服務(wù)獨(dú)立測試、部署、升級(jí)、發(fā)布

• 在單塊架構(gòu)中所有功能都在同一個(gè)代碼庫，功能的開發(fā)不具有獨(dú)立性；當(dāng)不同小組完成多個(gè)功能后，需要經(jīng)過集成和回歸測試，測試過程也不具有獨(dú)立性；當(dāng)測試完成后，應(yīng)用被構(gòu)建成一個(gè)包，如果某個(gè)功能存在 bug，將導(dǎo)致整個(gè)部署失敗或者回滾

• 新技術(shù)的應(yīng)用，系統(tǒng)不會(huì)被長期限制在某個(gè)技術(shù)棧上

• 可以根據(jù)市場需求，靈活多變的組合出新的業(yè)務(wù)場景

• 降低代碼耦合度

• 服務(wù)實(shí)例水平擴(kuò)展，服務(wù)單一職責(zé)，功能獨(dú)立。保證可靠性與性能，提升資源利用

• 由于微服務(wù)是以業(yè)務(wù)功能導(dǎo)向的實(shí)現(xiàn)，因此不會(huì)受到應(yīng)用程序的干擾，微服務(wù)的管理員可以視運(yùn)算資源的需要來配置微服務(wù)到不同的運(yùn)算資源內(nèi)，或是布建新的運(yùn)算資源并將它配置進(jìn)去

• 提升開發(fā)交流，每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解

• 進(jìn)程隔離、故障隔離

• 單塊架構(gòu)中，整個(gè)系統(tǒng)運(yùn)行在同一個(gè)進(jìn)程中，當(dāng)應(yīng)用進(jìn)行部署時(shí)，必須停掉當(dāng)前正在運(yùn)行的應(yīng)用，部署完成后再重啟進(jìn)程，無法做到獨(dú)立部署 有時(shí)候我們會(huì)將重復(fù)的代碼抽取出來封裝成組件，在單塊架構(gòu)中，組件通常的形態(tài)叫做共享庫（如 jar 包或者DLL），但是當(dāng)程序運(yùn)行時(shí)，所有組件最終也會(huì)被加載到同一進(jìn)程中運(yùn)行。

  • 在微服務(wù)架構(gòu)中，應(yīng)用程序由多個(gè)服務(wù)組成，每個(gè)服務(wù)都是高度自治的獨(dú)立業(yè)務(wù)實(shí)體，可以運(yùn)行在獨(dú)立的進(jìn)程中，不同的服務(wù)能非常容易地部署到不同的主機(jī)上

• 即使應(yīng)用程序的一項(xiàng)服務(wù)不起作用，系統(tǒng)仍然可以繼續(xù)運(yùn)行

• 數(shù)據(jù)分區(qū)，數(shù)據(jù)獨(dú)立，可靠性保證

微服務(wù)的缺點(diǎn)

• 微服務(wù)提高了系統(tǒng)的復(fù)雜度

• 開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性

• 服務(wù)之間的分布式事務(wù)問題

• 服務(wù)的注冊與發(fā)現(xiàn)問題

• 數(shù)據(jù)隔離再來的報(bào)表處理問題

• 不同服務(wù)實(shí)例的管理困難，持續(xù)自動(dòng)化部署的要求

• 運(yùn)維要求較高

• 對于單體架構(gòu)來講，我們只需要維護(hù)好這一個(gè)項(xiàng)目就可以了，但是對于微服務(wù)架構(gòu)來講，由于項(xiàng)目是由多個(gè)微服務(wù)構(gòu)成的，每個(gè)模塊出現(xiàn)問題都會(huì)造成整個(gè)項(xiàng)目運(yùn)行出現(xiàn)異常，想要知道是哪個(gè)模塊造成的問題往往是不容易的，因?yàn)槲覀儫o法一步一步通過debug的方式來跟蹤，這就對運(yùn)維人員提出了很高的要求

• 分布式的復(fù)雜性

• 對于單體架構(gòu)來講，我們可以不使用分布式，但是對于微服務(wù)架構(gòu)來說，分布式幾乎是必會(huì)用的技術(shù)，由于分布式本身的復(fù)雜性，導(dǎo)致微服務(wù)架構(gòu)也變得復(fù)雜起來

• 接口調(diào)整成本高

• 比如，用戶微服務(wù)是要被訂單微服務(wù)和電影微服務(wù)所調(diào)用的，一旦用戶微服務(wù)的接口發(fā)生大的變動(dòng)，那么所有依賴它的微服務(wù)都要做相應(yīng)的調(diào)整，由于微服務(wù)可能非常多，那么調(diào)整接口所造成的成本將會(huì)明顯提高

微服務(wù)的溝通

溝通與事件廣播

微服務(wù)的規(guī)劃與單體式應(yīng)用程序十分不同，微服務(wù)中每個(gè)服務(wù)都需要避免與其他服務(wù)有所牽連，且都要能夠自主，并在其他服務(wù)發(fā)生錯(cuò)誤時(shí)不受干擾
倘若真有溝通，也應(yīng)采用異步溝通的方式來避免緊密的相依性問題。要達(dá)到此目的，則可用下列兩種方式：

• 事件存儲(chǔ)中心（Event Store）
  這可以讓你在服務(wù)集群中廣播事件，并且在每個(gè)服務(wù)中監(jiān)聽這些事件并作處理，這令服務(wù)之間沒有緊密的相依性，而這些發(fā)生的事件都會(huì)被保存在事件存儲(chǔ)中心里。這意味著當(dāng)微服務(wù)重新上線、部署時(shí)可以重播（Replay）所有的事件。這也造就了微服務(wù)的數(shù)據(jù)庫隨時(shí)都可以被刪除、摧毀，且不需要從其他服務(wù)中獲取數(shù)據(jù)

• 消息隊(duì)列（Message Queue）

• 能夠在服務(wù)集群中廣播消息，并傳遞到每個(gè)服務(wù)中

• 比較有名的消息中間件如：NSQ、RabbitMQ、Nats、Kafka

• A 服務(wù)上廣播一個(gè)事件，此事件可以順帶一些數(shù)據(jù)。B 服務(wù)可以監(jiān)聽這個(gè)事件并在接收到之后有所處理。這些過程都是異步處理的

• A 服務(wù)并不需要等到 B 服務(wù)處理完該事件后才能繼續(xù)，而這也代表 A 服務(wù)無法獲取 B 服務(wù)的處理結(jié)果

• 與事件存儲(chǔ)中心不同的是：消息隊(duì)列并不會(huì)保存事件。一旦事件被消化（接收）后就會(huì)從隊(duì)列中消失

服務(wù)發(fā)現(xiàn)

• 單個(gè)微服務(wù)在上線的時(shí)候，會(huì)向服務(wù)注冊中心注冊自己的 IP 位置、服務(wù)內(nèi)容

• 當(dāng)服務(wù)需要調(diào)用另一個(gè)服務(wù)的時(shí)候，會(huì)去詢問服務(wù)探索中心該服務(wù)的 IP 位置，得到位置后即可直接向目標(biāo)服務(wù)發(fā)起調(diào)用

• 這么做的用意是可以統(tǒng)一集中所有服務(wù)的位置，就不會(huì)分散于每個(gè)微服務(wù)中

• 服務(wù)發(fā)現(xiàn)中心可以每隔一段時(shí)間就向微服務(wù)進(jìn)行健康檢查（TCP 調(diào)用、HTTP 調(diào)用、Ping）

• 倘若該服務(wù)在時(shí)間內(nèi)沒有回應(yīng)，則將其從服務(wù)中心移除，避免其他微服務(wù)對一個(gè)無回應(yīng)的服務(wù)進(jìn)行調(diào)用

• 即便微服務(wù)重新在其他ip上部署，其他服務(wù)也是無感知的

• 比較常用的服務(wù)發(fā)現(xiàn)有：etcd，consul，普遍都采用了raft等分布式算法

微服務(wù)其他需要考慮的因素

• 網(wǎng)絡(luò)延遲

• 分布式事務(wù)

• 限流

• 例如一個(gè)服務(wù)掛掉后，上游服務(wù)或者用戶一般會(huì)習(xí)慣性地重試訪問。這導(dǎo)致一旦服務(wù)恢復(fù)正常，很可能因?yàn)樗查g網(wǎng)絡(luò)流量過大又立刻掛掉

• 因此服務(wù)需要能夠自我保護(hù)——限流。限流策略有很多，最簡單的比如當(dāng)單位時(shí)間內(nèi)請求數(shù)過多時(shí)，丟棄多余的請求。另外，也可以考慮分區(qū)限流。僅拒絕來自產(chǎn)生大量請求的服務(wù)的請求

• 熔斷

• 當(dāng)一個(gè)服務(wù)因?yàn)楦鞣N原因停止響應(yīng)時(shí)，調(diào)用方通常會(huì)等待一段時(shí)間，然后超時(shí)或者收到錯(cuò)誤返回

• 如果調(diào)用鏈路比較長，可能會(huì)導(dǎo)致請求堆積，整條鏈路占用大量資源一直在等待下游響應(yīng)。所以當(dāng)多次訪問一個(gè)服務(wù)失敗時(shí)，應(yīng)熔斷，標(biāo)記該服務(wù)已停止工作，直接返回錯(cuò)誤。直至該服務(wù)恢復(fù)正常后再重新建立連接

• 服務(wù)降級(jí)

• 當(dāng)Service A調(diào)用Service B，失敗多次達(dá)到一定閥值，Service A不會(huì)再去調(diào)Service B，而會(huì)去執(zhí)行本地的降級(jí)方法

• 降級(jí)服務(wù)其實(shí)就是犧牲掉一些邏輯處理，或者停止部分依賴服務(wù)的請求。以保障服務(wù)可以提供關(guān)鍵能力

• 權(quán)限控制

• API網(wǎng)關(guān)

• 分布式追蹤

• 分布式日志記錄

• 配置中心

• 關(guān)微服務(wù)就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果喜歡這篇文章，不如把它分享出去讓更多的人看到。

網(wǎng)站名稱：微服務(wù)是什么？有什么優(yōu)缺點(diǎn)？
文章轉(zhuǎn)載：http://bm7419.com/article40/jcsiho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、企業(yè)建站、關(guān)鍵詞優(yōu)化、靜態(tài)網(wǎng)站、服務(wù)器托管、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)