戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！

作者 |?李運(yùn)華

出品 |?技術(shù)瑣話

微服務(wù)是近幾年非常火熱的架構(gòu)設(shè)計(jì)理念，大部分人認(rèn)為是MartinFlower提出了微服務(wù)概念，但事實(shí)上微服務(wù)概念的歷史要早得多，也不是Martin Flower創(chuàng)造出來的，Martin只是將微服務(wù)進(jìn)行了系統(tǒng)的闡述。不過不能否認(rèn)Martin在推動(dòng)微服務(wù)火熱起來的作用，微服務(wù)能火，Martin功不可沒。

參考維基百科英文版，我們簡單梳理一下微服務(wù)的歷史：

• 2005年：Dr. PeterRodgers在Web ServicesEdge大會(huì)上提出了“Micro-Web-Services”的概念。

• 2011年：一個(gè)軟件架構(gòu)工作組使用了“microservice”一詞來描述一種架構(gòu)模式。

• 2012年：同樣是這個(gè)架構(gòu)工作組，正式確定用“microservice”來代表這種架構(gòu)。

• 2012年：ThoughtWorks的James Lewis針對(duì)微服務(wù)概念在QCon San Francisco 2012發(fā)表了演講。

• 2014年：James Lewis和Martin Flower合寫了關(guān)于微服務(wù)的一篇學(xué)術(shù)性的文章，詳細(xì)闡述了微服務(wù)。

由于微服務(wù)的理念中也包含了“服務(wù)”的概念，而SOA中也有“服務(wù)”的概念，我們自然而言地會(huì)提出疑問：微服務(wù)與SOA是什么關(guān)系，有什么區(qū)別，為何有了SOA還要提微服務(wù)？這幾個(gè)問題是理解微服務(wù)的關(guān)鍵，否則如果只是跟風(fēng)拿來就用，既不會(huì)用，也用不好，用了不但沒有效果，反而還可能有副作用。

微服務(wù)與SOA的關(guān)系

對(duì)于了解過SOA的人來說，第一次看到微服務(wù)這個(gè)概念肯定會(huì)有所疑惑：為何有了SOA還要提微服務(wù)呢？等到簡單看完微服務(wù)的介紹后，很多人可能就有一個(gè)疑惑：這不就是SOA嗎？

關(guān)于SOA和微服務(wù)的關(guān)系和區(qū)別，大概分為幾個(gè)典型的觀點(diǎn)。

• 微服務(wù)是SOA的實(shí)現(xiàn)方式

如下圖所示，這種觀點(diǎn)認(rèn)為SOA是一種架構(gòu)理念，而微服務(wù)是SOA理念的一種具體實(shí)現(xiàn)方法。例如，“微服務(wù)就是使用HTTP RESTful協(xié)議來實(shí)現(xiàn)ESB的SOA”，“使用SOA來構(gòu)建單個(gè)系統(tǒng)就是微服務(wù)”“微服務(wù)就是更細(xì)粒度的SOA”。

? ? ? ? ? ? ? ? ? ? ? ? ? ??

• 微服務(wù)是去掉ESB后的SOA

如下圖所示，這種觀點(diǎn)認(rèn)為傳統(tǒng)SOA架構(gòu)最廣為人詬病的就是龐大、復(fù)雜、低效的ESB，因此將ESB去掉，改為輕量級(jí)的HTTP實(shí)現(xiàn)，就是微服務(wù)。

• 微服務(wù)是一種和SOA相似，但本質(zhì)上不同的架構(gòu)理念

如下圖所示，這種觀點(diǎn)認(rèn)為微服務(wù)和SOA只是有點(diǎn)類似，但本質(zhì)上是不同的架構(gòu)設(shè)計(jì)理念。相似點(diǎn)在于下圖中交叉的地方，就是兩者都關(guān)注“服務(wù)”，都是通過服務(wù)的拆分來解決可擴(kuò)展性問題。本質(zhì)上不同的地方在于幾個(gè)核心理念的差異：是否有ESB、服務(wù)的粒度、架構(gòu)設(shè)計(jì)的目標(biāo)等。

以上觀點(diǎn)看似都有一定的道理，但都有點(diǎn)差別，到底哪個(gè)才是準(zhǔn)確的呢？單純從概念上是難以分辨的，我們對(duì)比一下SOA和微服務(wù)的一些具體做法，再來看看到底哪一種觀點(diǎn)更加符合實(shí)際情況。

• 服務(wù)粒度

整體上來說，SOA的服務(wù)粒度要粗一些，而微服務(wù)的服務(wù)粒度要細(xì)一些。例如，對(duì)一個(gè)大型企業(yè)來說，“員工管理系統(tǒng)”就是一個(gè)SOA架構(gòu)中的服務(wù)；而如果采用微服務(wù)架構(gòu)，則“員工管理系統(tǒng)”會(huì)被拆分為更多的服務(wù)，比如“員工信息管理”“員工考勤管理”“員工假期管理”“員工福利管理”等更多服務(wù)。

• 服務(wù)通信

SOA采用了ESB作為服務(wù)間通信的關(guān)鍵組件，負(fù)責(zé)服務(wù)定義、服務(wù)路由、消息轉(zhuǎn)換、消息傳遞，總體上是重量級(jí)的實(shí)現(xiàn)。微服務(wù)推薦使用統(tǒng)一的協(xié)議和格式，例如，RESTful協(xié)議、RPC協(xié)議，無須ESB這樣的重量級(jí)實(shí)現(xiàn)。Martin Flower將微服務(wù)架構(gòu)的服務(wù)通信理念稱為“Smart endpoints anddumb pipes”，簡單翻譯為“聰明的終端，愚蠢的管道”。之所以用“愚蠢”二字，其實(shí)就是與ESB對(duì)比的，因?yàn)?/span>ESB太強(qiáng)大了，既知道每個(gè)服務(wù)的協(xié)議類型（例如，是RMI還是HTTP），又知道每個(gè)服務(wù)的數(shù)據(jù)類型（例如，是XML還是JSON），還知道每個(gè)數(shù)據(jù)的格式（例如，是2017-01-01還是01/01/2017），而微服務(wù)的“dumb pipes”僅僅做消息傳遞，對(duì)消息格式和內(nèi)容一無所知。

• 服務(wù)交付

SOA對(duì)服務(wù)的交付并沒有特殊要求，因?yàn)?/span>SOA更多考慮的是兼容已有的系統(tǒng)；微服務(wù)的架構(gòu)理念要求“快速交付”，相應(yīng)地要求采取自動(dòng)化測試、持續(xù)集成、自動(dòng)化部署等敏捷開發(fā)相關(guān)的最佳實(shí)踐。如果沒有這些基礎(chǔ)能力支撐，微服務(wù)規(guī)模一旦變大（例如，超過20個(gè)微服務(wù)），整體就難以達(dá)到快速交付的要求，這也是很多企業(yè)在實(shí)行微服務(wù)時(shí)踩過的一個(gè)明顯的坑，就是系統(tǒng)拆分為微服務(wù)后，部署的成本呈指數(shù)上升。

• 應(yīng)用場景

SOA更加適合于龐大、復(fù)雜、異構(gòu)的企業(yè)級(jí)系統(tǒng)，這也是SOA誕生的背景。這類系統(tǒng)的典型特征就是很多系統(tǒng)已經(jīng)發(fā)展多年，采用不同的企業(yè)級(jí)技術(shù)，有的是內(nèi)部開發(fā)的，有的是外部購買的，無法完全推倒重來或進(jìn)行大規(guī)模的優(yōu)化和重構(gòu)。因?yàn)槌杀竞陀绊懱?#xff0c;只能采用兼容的方式進(jìn)行處理，而承擔(dān)兼容任務(wù)的就是ESB。

微服務(wù)更加適合于快速、輕量級(jí)、基于Web的互聯(lián)網(wǎng)系統(tǒng)，這類系統(tǒng)業(yè)務(wù)變化快，需要快速嘗試、快速交付；同時(shí)基本都是基于Web，雖然開發(fā)技術(shù)可能差異很大（例如，Java、C++、.NET等），但對(duì)外接口基本都是提供HTTP RESTful風(fēng)格的接口，無須考慮在接口層進(jìn)行類似SOA的ESB那樣的處理。

綜合上述分析，我們將SOA和微服務(wù)對(duì)比如下表所示。?

對(duì) 比 維 度	SOA	微? 服? 務(wù)
服務(wù)粒度	粗	細(xì)
服務(wù)通信	重量級(jí)，ESB	輕量級(jí)，例如HTTP/ RESTful
服務(wù)交付	慢	快
應(yīng)用場景	企業(yè)級(jí)	互聯(lián)網(wǎng)

?

因此，我們可以看到，SOA和微服務(wù)本質(zhì)上是兩種不同的架構(gòu)設(shè)計(jì)理念，只是在“服務(wù)”這個(gè)點(diǎn)上有交集而已，因此兩者的關(guān)系應(yīng)該是第三種模式。

其實(shí)，Martin Flower在他的微服務(wù)文章中，已經(jīng)做了很好的提煉：

?

In short, the ?microservice architectural style is an approach to developing asingle ?application as a suite of small services, each running in its own process and ?communicating with lightweight mechanisms, often an HTTP resource API. These ?services are built around business capabilities and independently deployable ?by fully automated deployment machinery.

?

上述英文的三個(gè)關(guān)鍵詞分別是：small、lightweight、automated，基本上濃縮了微服務(wù)的精華，也是微服務(wù)與SOA的本質(zhì)區(qū)別所在。

通過前面的詳細(xì)分析和比較，似乎微服務(wù)本質(zhì)上就是一種比SOA要優(yōu)秀很多的架構(gòu)模式，那是否意味著我們都應(yīng)該把架構(gòu)重構(gòu)為微服務(wù)呢？

其實(shí)不然，SOA和微服務(wù)是兩種不同理念的架構(gòu)模式，并不存在孰優(yōu)孰劣，而只是應(yīng)用場景不同而已。我們介紹SOA時(shí)候提到其產(chǎn)生歷史背景是因?yàn)槠髽I(yè)的IT服務(wù)系統(tǒng)龐大而又復(fù)雜，改造成本很高，但業(yè)務(wù)上又要求其互通，因此才會(huì)提出SOA這種解決方案。如果我們將微服務(wù)的架構(gòu)模式生搬硬套到企業(yè)級(jí)IT服務(wù)系統(tǒng)中，這些IT服務(wù)系統(tǒng)的改造成本可能遠(yuǎn)遠(yuǎn)超出實(shí)施SOA的成本。

微服務(wù)的陷阱

單純從上面的對(duì)比來看，似乎SOA一無是處而微服務(wù)無所不能，這也導(dǎo)致了很多團(tuán)隊(duì)在實(shí)踐時(shí)不加思考地采用微服務(wù)—既不考慮團(tuán)隊(duì)的規(guī)模，也不考慮業(yè)務(wù)的發(fā)展，也沒有考慮基礎(chǔ)技術(shù)的支撐，只是覺得微服務(wù)很牛就趕緊來實(shí)施，以為實(shí)施了微服務(wù)后就什么問題都解決了，而一旦真正實(shí)施后才發(fā)現(xiàn)掉到微服務(wù)的坑里面去了。

我們看一下微服務(wù)具體有哪些坑。

• 服務(wù)劃分過細(xì)，服務(wù)間關(guān)系復(fù)雜

服務(wù)劃分過細(xì)，單個(gè)服務(wù)的復(fù)雜度確實(shí)下降了，但整個(gè)系統(tǒng)的復(fù)雜度卻上升了，因?yàn)槲⒎?wù)將系統(tǒng)內(nèi)的復(fù)雜度轉(zhuǎn)移為系統(tǒng)間的復(fù)雜度了。

從理論的角度來計(jì)算，n個(gè)服務(wù)的復(fù)雜度是n×(n-1)/2，整體系統(tǒng)的復(fù)雜度是隨著微服務(wù)數(shù)量的增加呈指數(shù)級(jí)增加的。下圖形象了說明了整體復(fù)雜度。

粗粒度劃分服務(wù)時(shí)，系統(tǒng)被劃分為3個(gè)服務(wù)，雖然單個(gè)服務(wù)較大，但服務(wù)間的關(guān)系很簡單；細(xì)粒度劃分服務(wù)時(shí)，雖然單個(gè)服務(wù)小了一些，但服務(wù)間的關(guān)系卻復(fù)雜了很多。

• 服務(wù)數(shù)量太多，團(tuán)隊(duì)效率急劇下降

微服務(wù)的“微”字，本身就是一個(gè)陷阱，很多團(tuán)隊(duì)看到“微”字后，就想到必須將服務(wù)拆分得很細(xì)，有的團(tuán)隊(duì)人員規(guī)模是5~6個(gè)人，然而卻拆分出30多個(gè)微服務(wù)，平均每個(gè)人要維護(hù)5個(gè)以上的微服務(wù)。

這樣做給工作效率帶來了明顯的影響，一個(gè)簡單的需求開發(fā)就需要涉及多個(gè)微服務(wù)，光是微服務(wù)之間的接口就有6~7個(gè)，無論設(shè)計(jì)、開發(fā)，還是測試、部署，都需要工程師不停地在不同的服務(wù)間切換。

• 開發(fā)工程師要設(shè)計(jì)多個(gè)接口，打開多個(gè)工程，調(diào)試時(shí)要部署多個(gè)程序，提測時(shí)打多個(gè)包。

• 測試工程師要部署多個(gè)環(huán)境，準(zhǔn)備多個(gè)微服務(wù)的數(shù)據(jù)，測試多個(gè)接口。

• 運(yùn)維工程師每次上線都要操作多個(gè)微服務(wù)，并且微服務(wù)之間可能還有依賴關(guān)系。

  
  

• 調(diào)用鏈太長，性能下降

由于微服務(wù)之間都是通過HTTP或RPC調(diào)用的，每次調(diào)用必須經(jīng)過網(wǎng)絡(luò)。一般線上的業(yè)務(wù)接口之間的調(diào)用，平均響應(yīng)時(shí)間大約為50ms，如果用戶的一起請(qǐng)求需要經(jīng)過6次微服務(wù)調(diào)用，則性能消耗就是300ms，這在很多高性能業(yè)務(wù)場景下是難以滿足需求的。為了支撐業(yè)務(wù)請(qǐng)求，可能需要大幅增加硬件，這就導(dǎo)致了硬件成本的大幅上升。

• 調(diào)用鏈太長，問題定位困難

系統(tǒng)拆分為微服務(wù)后，一次用戶請(qǐng)求需要多個(gè)微服務(wù)協(xié)同處理，任意微服務(wù)的故障都將導(dǎo)致整個(gè)業(yè)務(wù)失敗。然而由于微服務(wù)數(shù)量較多，且故障存在擴(kuò)散現(xiàn)象，快速定位到底是哪個(gè)微服務(wù)故障是一件復(fù)雜的事情。樣例如下圖所示。

Service C的數(shù)據(jù)庫出現(xiàn)慢查詢，導(dǎo)致Service C給Service B的響應(yīng)錯(cuò)誤，Service B?給Service A的響應(yīng)錯(cuò)誤，Service A給用戶的響應(yīng)錯(cuò)誤。我們?cè)趯?shí)際定位時(shí)是不會(huì)有圖例中這么清晰的，最開始是用戶報(bào)錯(cuò)，這時(shí)我們首先會(huì)去查Service A。導(dǎo)致Service A故障的原因有很多，我們可能要花半個(gè)小時(shí)甚至1個(gè)小時(shí)才能發(fā)現(xiàn)是ServiceB返回錯(cuò)誤導(dǎo)致的。于是我們又去查Service B，這相當(dāng)于重復(fù)Service A故障定位的步驟……如此循環(huán)下去，最后可能花費(fèi)了幾個(gè)小時(shí)才能定位到是Service C的數(shù)據(jù)庫慢查詢導(dǎo)致了錯(cuò)誤。

如果多個(gè)微服務(wù)同時(shí)發(fā)生不同類型的故障，則定位故障更加復(fù)雜，如下圖所示。

Service C的數(shù)據(jù)庫發(fā)生慢查詢故障，同時(shí)Service C到Service D的網(wǎng)絡(luò)出現(xiàn)故障，此時(shí)到底是哪個(gè)原因?qū)е铝?/span>Service C返回Error給Service B，需要大量的信息和人力去排查。

• 沒有自動(dòng)化支撐，無法快速交付

如果沒有相應(yīng)的自動(dòng)化系統(tǒng)進(jìn)行支撐，都是靠人工去操作，那么微服務(wù)不但達(dá)不到快速交付的目的，甚至還不如一個(gè)大而全的系統(tǒng)效率高。例如：

• 沒有自動(dòng)化測試支撐，每次測試時(shí)需要測試大量接口。

• 沒有自動(dòng)化部署支撐，每次部署6~7個(gè)服務(wù)，幾十臺(tái)機(jī)器，運(yùn)維人員敲shell命令逐臺(tái)部署，手都要敲麻。

• 沒有自動(dòng)化監(jiān)控，每次故障定位都需要人工查幾十臺(tái)機(jī)器幾百個(gè)微服務(wù)的各種狀態(tài)和各種日志文件。

• 沒有服務(wù)治理，微服務(wù)數(shù)量多了后管理混亂

信奉微服務(wù)理念的設(shè)計(jì)人員總是強(qiáng)調(diào)微服務(wù)的lightweight特性，并舉出ESB的反例來證明微服務(wù)的優(yōu)越之處。但具體實(shí)踐后就會(huì)發(fā)現(xiàn)，隨著微服務(wù)種類和數(shù)量越來越多，如果沒有服務(wù)治理系統(tǒng)進(jìn)行支撐，微服務(wù)提倡的lightweight就會(huì)變成問題。主要問題如下。

• 服務(wù)路由：假設(shè)某個(gè)微服務(wù)有60個(gè)節(jié)點(diǎn)，部署在20臺(tái)機(jī)器上，那么其他依賴的微服務(wù)如何知道這個(gè)部署情況呢？

• 服務(wù)故障隔離：假設(shè)上述例子中的60個(gè)節(jié)點(diǎn)有5個(gè)節(jié)點(diǎn)發(fā)生故障了，依賴的微服務(wù)如何處理這種情況呢？

• 服務(wù)注冊(cè)和發(fā)現(xiàn)：同樣是上述的例子，現(xiàn)在我們決定從60個(gè)節(jié)點(diǎn)擴(kuò)容到80個(gè)節(jié)點(diǎn)，或者將60個(gè)節(jié)點(diǎn)縮減為40個(gè)節(jié)點(diǎn)，新增或減少的節(jié)點(diǎn)如何讓依賴的服務(wù)知道呢？

  
  

如果以上場景都依賴人工去管理，整個(gè)系統(tǒng)將陷入一片混亂，最終的解決方案必須依賴自動(dòng)化的服務(wù)管理系統(tǒng)，這時(shí)我們就會(huì)發(fā)現(xiàn)，微服務(wù)所推崇的“lightweight”，最終也發(fā)展成和ESB幾乎一樣的復(fù)雜程度。

本文節(jié)選自《從零開始學(xué)架構(gòu)：照著做，你也能成為架構(gòu)師》一書，電子工業(yè)出版社出版。

作者李運(yùn)華，互聯(lián)網(wǎng)資深技術(shù)專家，十多年技術(shù)老兵，目前帶領(lǐng)多個(gè)研發(fā)團(tuán)隊(duì)，承擔(dān)架構(gòu)設(shè)計(jì)、架構(gòu)重構(gòu)、技術(shù)團(tuán)隊(duì)管理、技術(shù)培訓(xùn)等職責(zé)；專注于開源技術(shù)、系統(tǒng)分析、架構(gòu)設(shè)計(jì)，對(duì)互聯(lián)網(wǎng)技術(shù)的特點(diǎn)和發(fā)展趨勢有較深入的研究，對(duì)系統(tǒng)解耦、高性能、高可用架構(gòu)有豐富的經(jīng)驗(yàn)。

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計(jì)算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！

推薦閱讀：

• 邊緣計(jì)算將吞掉云計(jì)算！
  

• ARM 發(fā)布新一代 CPU 和 GPU，實(shí)現(xiàn) 20% 性能提升！

• 前端開發(fā) 20 年變遷史
  

• 北漂杭漂的程序員，是如何買到第一套房子？
  

• “愛裝X”開源組織：“教科書級(jí)”AI知識(shí)樹究竟長什么樣？

• 500行Python代碼打造刷臉考勤系統(tǒng)

• 權(quán)游播完了, 你在罵爛尾, 有人卻悄悄解鎖了新操作……
  

真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的微服务的历史与陷阱的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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