微服務(wù)是近幾年非臣裥酰火熱的架構(gòu)設(shè)計理念熬芜，大部分人認為是 Martin Fowler 提出了微服務(wù)概念，但事實上微服務(wù)概念的歷史要早得多福稳，也不是 Martin Fowler 創(chuàng)造出來的涎拉，Martin 只是將微服務(wù)進行了系統(tǒng)的闡述（原文鏈接：https://martinfowler.com/articles/microservices.html）。不過不能否認 Martin 在推動微服務(wù)起到的作用的圆，微服務(wù)能火鼓拧，Martin 功不可沒。

微服務(wù)的定義相信你早已耳熟能詳越妈，參考維基百科季俩，我就來簡單梳理一下微服務(wù)的歷史吧（https://en.wikipedia.org/wiki/Microservices#History）：

2005 年：Dr. Peter Rodgers 在 Web Services Edge 大會上提出了“Micro-Web-Services”的概念。

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

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

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

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

由于微服務(wù)的理念中也包含了“服務(wù)”的概念且叁，而 SOA 中也有“服務(wù)”的概念都哭，我們自然而然地會提出疑問：微服務(wù)與 SOA 有什么關(guān)系？有什么區(qū)別逞带？為何有了 SOA 還要提微服務(wù)欺矫？這幾個問題是理解微服務(wù)的關(guān)鍵，否則如果只是跟風拿來就用展氓，既不會用穆趴，也用不好，用了不但沒有效果带饱，反而還可能有副作用毡代。

今天我們就來深入理解微服務(wù)阅羹，到底是銀彈還是焦油坑勺疼。

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

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

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

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

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

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

如下圖所示躏结，這種觀點認為傳統(tǒng) SOA 架構(gòu)最廣為人詬病的就是龐大却盘、復雜、低效的 ESB媳拴，因此將 ESB 去掉黄橘，改為輕量級的 HTTP 實現(xiàn)，就是微服務(wù)屈溉。

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

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

以上觀點看似都有一定的道理廉羔，但都有點差別，到底哪個才是準確的呢僻造？單純從概念上是難以分辨的憋他，我來對比一下 SOA 和微服務(wù)的一些具體做法，再來看看到底哪一種觀點更加符合實際情況髓削。

服務(wù)粒度

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

服務(wù)通信

SOA 采用了 ESB 作為服務(wù)間通信的關(guān)鍵組件框往，負責服務(wù)定義鳄抒、服務(wù)路由、消息轉(zhuǎn)換椰弊、消息傳遞许溅，總體上是重量級的實現(xiàn)。微服務(wù)推薦使用統(tǒng)一的協(xié)議和格式秉版，例如贤重，RESTful 協(xié)議、RPC 協(xié)議清焕，無須 ESB 這樣的重量級實現(xiàn)并蝗。Martin Fowler 將微服務(wù)架構(gòu)的服務(wù)通訊理念稱為“Smart endpoints and dumb pipes”，簡單翻譯為“聰明的終端耐朴，愚蠢的管道”借卧。之所以用“愚蠢”二字，其實就是與 ESB 對比的筛峭，因為 ESB 太強大了铐刘，既知道每個服務(wù)的協(xié)議類型（例如，是 RMI 還是 HTTP）影晓，又知道每個服務(wù)的數(shù)據(jù)類型（例如镰吵，是 XML 還是 JSON），還知道每個數(shù)據(jù)的格式（例如挂签，是 2017-01-01 還是 01/01/2017）疤祭，而微服務(wù)的“dumb pipes”僅僅做消息傳遞，對消息格式和內(nèi)容一無所知饵婆。

服務(wù)交付

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

應(yīng)用場景

SOA 更加適合于龐大炉奴、復雜、異構(gòu)的企業(yè)級系統(tǒng)功偿，這也是 SOA 誕生的背景盆佣。這類系統(tǒng)的典型特征就是很多系統(tǒng)已經(jīng)發(fā)展多年往堡，采用不同的企業(yè)級技術(shù)械荷，有的是內(nèi)部開發(fā)的，有的是外部購買的虑灰，無法完全推倒重來或者進行大規(guī)模的優(yōu)化和重構(gòu)吨瞎。因為成本和影響太大，只能采用兼容的方式進行處理穆咐，而承擔兼容任務(wù)的就是 ESB颤诀。

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

綜合上述分析爽室，我將 SOA 和微服務(wù)對比如下：

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

其實缘滥，Martin Fowler 在他的微服務(wù)文章中艾扮，已經(jīng)做了很好的提煉：

In short, the microservice architectural style is an approach to developing a single 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.

（https://martinfowler.com/articles/microservices.html）

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

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

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

微服務(wù)的陷阱

單純從上面的對比來看楣颠，似乎微服務(wù)大大優(yōu)于 SOA，這也導致了很多團隊在實踐時不加思考地采用微服務(wù)——既不考慮團隊的規(guī)模咐蚯，也不考慮業(yè)務(wù)的發(fā)展童漩，也沒有考慮基礎(chǔ)技術(shù)的支撐，只是覺得微服務(wù)很牛就趕緊來實施春锋，以為實施了微服務(wù)后就什么問題都解決了矫膨，而一旦真正實施后才發(fā)現(xiàn)掉到微服務(wù)的坑里面去了。

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

服務(wù)劃分過細看疙，服務(wù)間關(guān)系復雜

服務(wù)劃分過細豆拨，單個服務(wù)的復雜度確實下降了，但整個系統(tǒng)的復雜度卻上升了能庆，因為微服務(wù)將系統(tǒng)內(nèi)的復雜度轉(zhuǎn)移為系統(tǒng)間的復雜度了施禾。

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

粗粒度劃分服務(wù)時，系統(tǒng)被劃分為 3 個服務(wù)渠旁，雖然單個服務(wù)較大攀例，但服務(wù)間的關(guān)系很簡單；細粒度劃分服務(wù)時顾腊，雖然單個服務(wù)小了一些粤铭，但服務(wù)間的關(guān)系卻復雜了很多。

服務(wù)數(shù)量太多杂靶，團隊效率急劇下降

微服務(wù)的“微”字梆惯，本身就是一個陷阱酱鸭，很多團隊看到“微”字后，就想到必須將服務(wù)拆分得很細垛吗，有的團隊人員規(guī)模是 5 ~ 6 個人凹髓，然而卻拆分出 30 多個微服務(wù)，平均每個人要維護 5 個以上的微服務(wù)怯屉。

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

開發(fā)工程師要設(shè)計多個接口失受，打開多個工程，調(diào)試時要部署多個程序咏瑟，提測時打多個包拂到。

測試工程師要部署多個環(huán)境，準備多個微服務(wù)的數(shù)據(jù)码泞，測試多個接口兄旬。

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

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

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

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

系統(tǒng)拆分為微服務(wù)后喇聊，一次用戶請求需要多個微服務(wù)協(xié)同處理，任意微服務(wù)的故障都將導致整個業(yè)務(wù)失敗蹦狂。然而由于微服務(wù)數(shù)量較多誓篱，且故障存在擴散現(xiàn)象邻耕，快速定位到底是哪個微服務(wù)故障是一件復雜的事情。下面是一個典型樣例燕鸽。

Service C 的數(shù)據(jù)庫出現(xiàn)慢查詢兄世，導致 Service C 給 Service B 的響應(yīng)錯誤，Service B 給 Service A 的響應(yīng)錯誤啊研，Service A 給用戶的響應(yīng)錯誤御滩。我們在實際定位時是不會有樣例圖中這么清晰的，最開始是用戶報錯党远，這時我們首先會去查 Service A削解。導致 Service A 故障的原因有很多，我們可能要花半個小時甚至 1 個小時才能發(fā)現(xiàn)是 Service B 返回錯誤導致的沟娱。于是我們又去查 Service B氛驮，這相當于重復 Service A 故障定位的步驟……如此循環(huán)下去，最后可能花費了幾個小時才能定位到是 Service C 的數(shù)據(jù)庫慢查詢導致了錯誤济似。

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

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

沒有自動化支撐，無法快速交付

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

沒有自動化測試支撐嗓奢，每次測試時需要測試大量接口。

沒有自動化部署支撐胰挑，每次部署 6 ~ 7 個服務(wù)蔓罚，幾十臺機器，運維人員敲 shell 命令逐臺部署瞻颂，手都要敲麻豺谈。

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

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

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

服務(wù)路由：假設(shè)某個微服務(wù)有 60 個節(jié)點柜砾，部署在 20 臺機器上，那么其他依賴的微服務(wù)如何知道這個部署情況呢换衬？

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

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

如果以上場景都依賴人工去管理蝇完，整個系統(tǒng)將陷入一片混亂，最終的解決方案必須依賴自動化的服務(wù)管理系統(tǒng)矗蕊，這時就會發(fā)現(xiàn)短蜕，微服務(wù)所推崇的“l(fā)ightweight”，最終也發(fā)展成和 ESB 幾乎一樣的復雜程度拔妥。

小結(jié)

今天我為你講了微服務(wù)與 SOA 的關(guān)系以及微服務(wù)實踐中的常見陷阱忿危，希望對你有所幫助。

這就是今天的全部內(nèi)容没龙，留一道思考題給你吧，你們的業(yè)務(wù)有采用微服務(wù)么缎玫？談?wù)劸唧w實踐過程中有什么經(jīng)驗和教訓硬纤。

歡迎你把答案寫到留言區(qū)，和我一起討論赃磨。相信經(jīng)過深度思考的回答筝家，也會讓你對知識的理解更加深刻。（編輯亂入：精彩的留言有機會獲得豐厚福利哦Ａ诨浴）