**

不要迷信微服務(wù)，微服務(wù)就是個傳說

**
自微服務(wù)架構(gòu)興起以來，它已經(jīng)被大大小小的科技公司所采用。但是，這些公司真的達到了期望嗎，微服務(wù)的表現(xiàn)真的比以前的架構(gòu)更優(yōu)秀嗎，微服務(wù)真的無所不能嗎？在這篇文章中，我將盡可能地揭示微服務(wù)的本質(zhì)，來客觀地看待微服務(wù)，了解它的作用和局限，不要被“亂花”迷了眼。

申明一下，我僅僅是一個工作時間較長的技術(shù)人員，不敢自詡為“架構(gòu)師”，當然，也不屑于冒充“架構(gòu)師”。但我曾主持過幾個微服務(wù)架構(gòu)的產(chǎn)品設(shè)計，也見證過幾個朋友在轉(zhuǎn)型“微服務(wù)”時的歡樂，當然，更多的是沮喪，有的甚至陷入了泥潭。基于所見、所聞、所歷，從而有所感悟，一家之言，信疑由己。

一、 微服務(wù)是一項很偉大的技術(shù)，它能引領(lǐng)公司走向成功？

誰說的？來來來，看我不打死你！我猜這一定是所謂的“咨詢師”、“分析師”、或“講師”，用來忽悠非專業(yè)人士的。

微服務(wù)只是分布式架構(gòu)發(fā)展的一個階段，從軟件業(yè)的發(fā)展歷史來看，它遠沒有C/S架構(gòu)（客戶機-服務(wù)器架構(gòu)，劃時代的）、SOA（Service Oriented Architecture，面向服務(wù)的架構(gòu)，革命性的）等的歷史地位高。

微服務(wù)是SOA的一個分支，其核心思想繼承自SOA，但SOA的巔峰期與ERP軟件的發(fā)展相重合，更多地應(yīng)用于企業(yè)管理軟件，不為大眾所熟知，而微服務(wù)的誕生正值互聯(lián)網(wǎng)發(fā)展到巔峰的時段，伴隨著互聯(lián)網(wǎng)的成功而廣為人知，以至于很多不明真相的吃瓜群眾把這些互聯(lián)網(wǎng)公司的成功歸功于微服務(wù)。
殊不知，阿里、騰訊、百度，乃至Google、微軟件等公司，在其關(guān)鍵的發(fā)展期，微服務(wù)還沒有誕生呢，淘寶第一次雙十一（2009年），還沒有微服務(wù)的影子呢，QQ的用戶突破1億時，離微服務(wù)的誕生還有4年，百度市值在達到中國第一時，微服務(wù)還處于啟蒙狀態(tài)。這充分說明了，微服務(wù)絕非成功的關(guān)鍵因素，更不可能是決定因素，它頂多起到了“錦上添花”的作用。

一個公司的成功是由其產(chǎn)品的價值決定的，絕非技術(shù)，至于微服務(wù)，對公司成功的貢獻率絕對不會超過5%。客觀地說，微服務(wù)確實有它的價值所在，但也要看到，它起的作用主要是戰(zhàn)術(shù)上的，而非戰(zhàn)略上的。它也有著相應(yīng)的局限和使用場景，不能盲目地使用，要結(jié)合自身的業(yè)務(wù)和產(chǎn)品特色來使用它。

決策者也無須為微服務(wù)而煩惱，如果你的開發(fā)人員少于100人，或者活躍用戶數(shù)低于1000萬，你根本無須考慮微服務(wù)，你應(yīng)該更多地關(guān)注市場和客戶，相信我，即使你現(xiàn)在花了很大代價精心設(shè)計了很多微服務(wù)（這就是俗稱的技術(shù)過剩），在你的規(guī)模擴大以后你依然需要重新設(shè)計。

你也無須擔心將來向微服務(wù)轉(zhuǎn)型有很大的成本，只要你的軟件遵從了“組件化”、“平臺化”、“SOA”等思想，微服務(wù)的改造就會比較順利，至少技術(shù)方面不會有太大代價，主要的工作量來自應(yīng)用的整合和拆分。

二、 微服務(wù)架構(gòu)很難，需要聘請專業(yè)的人士來設(shè)計？

回答這個問題前，要區(qū)分“微服務(wù)架構(gòu)”和“微服務(wù)”，“微服務(wù)架構(gòu)”并不是很難，但在微服務(wù)架構(gòu)下，設(shè)計出合理的“微服務(wù)”確實需要經(jīng)驗和能力。

前者是個純技術(shù)問題，微服務(wù)架構(gòu)已經(jīng)形成了一定的模式，世界各地的工程師們也貢獻了大量的開源框架，像Spring Cloud、Dubbo、Thrift、Redis、MQ等等，依賴這些框架和技術(shù)工具，一個有豐富經(jīng)驗的高級設(shè)計人員很快就能搭建出一套微服務(wù)架構(gòu)的框架來，事實上，很多中小互聯(lián)網(wǎng)公司的微服務(wù)架構(gòu)搭建并沒有花費多少時間，這些微服務(wù)架構(gòu)也完全滿足微服務(wù)的特征和要求。

但是，搭建好微服務(wù)架構(gòu)就如同蓋房子時蓋好了框架，這只是第一步，更復(fù)雜的是，每個單元如何劃分房間，每個房間承載什么功能，每個房間的家具家電如何布置，地板用什么類型的，墻壁是貼壁紙還是刷漆…。

也就是說，針對你的產(chǎn)品，哪些不使用微服務(wù)，哪些使用微服務(wù)，劃分成多少個微服務(wù)，每個微服務(wù)做什么，不同的微服務(wù)之間如何協(xié)作，每個微服務(wù)又如何跟外部程序協(xié)作，這才是微服務(wù)的核心。這不是簡單的技術(shù)問題，這其中90%的工作要依賴于你對客戶、業(yè)務(wù)、產(chǎn)品的深刻理解，再對資源、成本、工期、運維等進行多方權(quán)衡后，才能夠設(shè)計出合理的微服務(wù)來。

至于需要的人才，我相信大多數(shù)的CTO或者高級設(shè)計師都能輕松完成微服務(wù)架構(gòu)的設(shè)計和搭建。你最需要的應(yīng)該是兩類人才，一類是純技術(shù)的，熟練掌握相應(yīng)的技術(shù)棧，如HFS、Zookeeper、Docker、Restful等，能夠進行開發(fā)層面的落地；另一類是懂業(yè)務(wù)的設(shè)計人員，對客戶、業(yè)務(wù)場景、產(chǎn)品功能等了如指掌，這樣才能設(shè)計出合理的微服務(wù)。

三、 所有產(chǎn)品都要微服務(wù)化？

這肯定是半懂不懂的“磚家“們說的，真正有經(jīng)驗的CTO肯定會嗤之以鼻，當然，真正的大佬都很忙，沒時間聽他們瞎扯蛋，也只有我這種”閑人“看不下去，呵呵幾聲后，優(yōu)雅地說一句：請你圓潤的離開（GUN）。

微服務(wù)的核心價值是把不同產(chǎn)品中重復(fù)的模塊獨立出來，成為一個公共的服務(wù)，從而減少重復(fù)開發(fā)和維護。這也是為什么老師講課時總喜歡拿“用戶管理“、”支付管理“舉例子，因為這兩個模塊用途最廣、重復(fù)度最高。把它們變成標準的微服務(wù)后，購物可以用、游戲可以用、交易可以用、教育也可以用…。
你可曾聽過老師拿“MRP“、”庫存優(yōu)化“、”運輸排程“來舉例，沒有，因為，如果一個模塊只在一個產(chǎn)品中使用，沒有其他的產(chǎn)品使用，外部也用不到，那把它包裝成微服務(wù)的意義是什么呢？總不能為了微服務(wù)而微服務(wù)吧！

正確的做法是，梳理你的所有產(chǎn)品、所有模塊，抽離出那些重復(fù)率高的模塊，這些模塊是需要微服務(wù)化的。根據(jù)我的經(jīng)驗，這個比例通常不會超過20%，這是針對互聯(lián)網(wǎng)產(chǎn)品而言的，對于某些企業(yè)級應(yīng)用而言，甚至低于10%。至于其他模塊，let be，原來是什么樣，就還怎么樣吧，別浪費那些個臭氧層次了，它不會有任何的問題。當然，如果您有強迫癥，非得追求形式上的統(tǒng)一，也可以把這些模塊變成“宏服務(wù)”，把它們對外的接口封裝一下，變成Restful的，但沒必要拆分得那么細，那么精致。

四、 微服務(wù)要多“微”？

很多人會說，微服務(wù)要盡可能的小，越抽象越好，越標準越好。這種脫離了具體的應(yīng)用場景、脫離了公司的資源、脫離了工期和成本的說法根本就是在耍流氓。

設(shè)計微服務(wù)時，最重要的工作是把所有產(chǎn)品中重復(fù)的模塊獨立出來并封裝，在內(nèi)部實現(xiàn)相關(guān)的業(yè)務(wù)邏輯，對外部提供相應(yīng)的接口，并且可以獨立部署，其他需要使用這個模塊的產(chǎn)品都通過標準的接口訪問，這個模塊就可以稱之為一個微服務(wù)。

不同的公司，不同的產(chǎn)品，其抽象出來的微服務(wù)是不同的，比如購物網(wǎng)站通常會把用戶、商品、支付等封裝成微服務(wù)，而管理軟件則把存貨檔案、流程引擎、日志管理等封裝成微服務(wù)。

微服務(wù)的大小（或者說邊界）取決于業(yè)務(wù)邏輯的耦合度，一般而言，互聯(lián)網(wǎng)公司由于業(yè)務(wù)邏輯較輕，因而可以拆分得細一些，每個微服務(wù)小一些，而管理軟件由于內(nèi)部業(yè)務(wù)邏輯的關(guān)聯(lián)非常密切，就不能分得太小，否則，各個微服務(wù)之間存在業(yè)務(wù)上的交叉，就達不到微服務(wù)“獨立性”的要求。

根據(jù)我的經(jīng)驗，一個成功的產(chǎn)品，通常是80%的宏服務(wù)加上20%的微服務(wù)，過于精細化的拆分會大大增加設(shè)計和管理的復(fù)雜度，在應(yīng)對變化方面的效率反而下降了，最終會變得越來越混亂。

五、 為什么轉(zhuǎn)向微服務(wù)后，成本反而提高了？工期也變長了？

一點不奇怪，沒有足夠的規(guī)模來分攤額外的成本，總成本肯定是上升的。這也是為什么小公司通常是淺嘗則止，而大公司總是大張其鼓的原因。

與傳統(tǒng)設(shè)計方式相對，微服務(wù)要建立單獨的工程，內(nèi)部功能要盡可能地完整，還要考慮通用性、冗余性、擴展性、分布式事務(wù)一致性等一系列的問題，大大增加了設(shè)計工作量，相應(yīng)的開發(fā)工作量、測試工作量、文檔工作量、部署工作量、運維工作量都會隨之增加，成本自然水漲船高。

還有一個不可忽視的原因，隨著環(huán)節(jié)的增多，需要的協(xié)作大大增加了，這也無形中增加了成本和工期，在有的項目中，差勁的協(xié)作導(dǎo)致的成本增加可能比其他因素加起來都要多。

據(jù)估計，相同的系統(tǒng)，采用微服務(wù)比不采用微服務(wù)至少要增加50%_{200%的成本（如果是宏服務(wù)，則只有10%}30%的增加）。

這還是建立在一切都順利的情況下，如果您把不應(yīng)該設(shè)計成微服務(wù)的產(chǎn)品變成了微服務(wù)，或者是微服務(wù)本身的標準化程度不高，或者拆分的過細，這簡單就是一場災(zāi)難，給企業(yè)造成的損失無法估計。而這種情況，每天都在發(fā)生著，發(fā)生的原因則非常可悲：無視公司所處的階段和產(chǎn)品特點、盲目追求時髦、急功近利、過于重視理論而忽略了工程層面的問題、缺乏對需求的深刻理解、外行指揮內(nèi)行！

綜上，微服務(wù)是建立在規(guī)模效應(yīng)之上的，當某個模塊在很多個產(chǎn)品中都需要時，你可以把它設(shè)計成微服務(wù)，從而節(jié)約重復(fù)開發(fā)的成本，微服務(wù)也就具有了經(jīng)濟價值。當你的規(guī)模不夠大時（參考前文所說的規(guī)模標準），一定要特別、特別地謹慎規(guī)劃微服務(wù)的數(shù)量和顆粒度。當然，如果您是土豪，只要貴的，不要對的，可另當別論。

六、 微服務(wù)降低了開發(fā)的復(fù)雜度？提高了開發(fā)效率？

理想很豐滿，現(xiàn)實很骨干！ 當你想主宰生活時，生活總是反過來給你一記響亮的耳光！

上圖來自Scott Rogowski所寫的一篇文章。左側(cè)是Uber設(shè)想的微服務(wù)架構(gòu)圖：簡單、優(yōu)雅、易于理解。右側(cè)是Uber 實際的微服務(wù)地圖。借用作者的一句評論：我敢說 Uber 的任何人都不知道這個架構(gòu)是如何工作的！

使用微服務(wù)架構(gòu)的大型公司的人都知道，Uber 的經(jīng)驗（或者更應(yīng)該說教訓(xùn)）不是特例，而是一個普遍現(xiàn)象（悄悄說一句，Uber的一個團隊正在把微服務(wù)改造成宏服務(wù)）。

這其中的重要原因在于，理論總是看上去很美好，但到了現(xiàn)實中，客戶和市場總是在變化的，總有新的業(yè)務(wù)模式，總有新的沒完沒了的需求，你以為你可以設(shè)計很多永遠不變的“微服務(wù)”，但實現(xiàn)上，過不了幾天，客戶和市場就會把你的夢想擊碎，你的微服務(wù)不斷地增加新的業(yè)務(wù)邏輯、新的接口、新的版本。很快，你初始狀態(tài)的優(yōu)美的架構(gòu)會變得越來越丑陋，越來越臃腫，直到某一天，你忍受不下去了，進行了一次徹底的重建。然后，一切都變得美好了？…，當然不可能，你只是開始了一輪新的循環(huán)。

這就是軟件行業(yè)的現(xiàn)狀，不管是系統(tǒng)開發(fā)還是應(yīng)用開發(fā)，不管是桌面開發(fā)還是移動開發(fā)，不管是ERP開發(fā)還是互聯(lián)網(wǎng)開發(fā)，無不如是。自從軟件業(yè)誕生以來，這種現(xiàn)象從未改變過，如果說改變過，那也是變得更糟糕！所以，你會發(fā)現(xiàn)，微軟、Google、Oracle、亞馬遜、阿里…等公司的開發(fā)人員總是在不斷增加，不僅僅是因為新的產(chǎn)品，老的產(chǎn)品線也沒有減人。

事物越是精巧，對技術(shù)、團隊、管理的要求就越高，所以，不要盲從于理論家，更不要聽那些半吊子的“專家”胡說八道，要依賴自己的技術(shù)團隊和管理團隊，找到適合自己的“度”！ 否則，很容易弄巧成拙，事與愿違，甚至自取滅亡！

至于開發(fā)速度的提高，有的時候確實會提高，在你需要用到的某個模塊或功能恰好原來的某個微服務(wù)可以提供時，恭喜你，你可以直接調(diào)用即可，不用自己開發(fā)了。這種情況下你確實提高了開發(fā)效率。
這個技巧實際上在很多年前就開始普遍使用了，比如說開發(fā)人員都在使用的“類庫”、“模板”、“框架”，比如說ERP廠商一直在使用的“公共模塊”、“主數(shù)據(jù)“、“應(yīng)用平臺”，無不如此，只不過在以前，它們是以別的形態(tài)（SOA或別的）存在的，現(xiàn)在則變成了“微服務(wù)”的形態(tài)而已。

從這個角度看，開發(fā)效率的提高主要來自于“組件化”的思想，來自于公共功能的“抽象”與“封裝”，微服務(wù)只是其中一個比較新的封裝形態(tài)而已。這些“框架“、“服務(wù)“或”微服務(wù)“，一部分是由開源的廠商、組織、個人提供的，另外一部分則是由貴公司的公共技術(shù)部門提供的。

真正能提高開發(fā)效率的是你的基礎(chǔ)能力，包括：合理的需求及需求變更、良好的設(shè)計、有效的測試、優(yōu)秀的開發(fā)管理，以及價值觀趨同、有能力、肯配合的團隊！

七、 我們應(yīng)該一開始就設(shè)計出一個完美的微服務(wù)系統(tǒng)?

這個問題可以用Gall定律來回答：正常運作的復(fù)雜系統(tǒng)一定是從一個正常運作的簡單系統(tǒng)演變而來的。從頭開始設(shè)計的復(fù)雜系統(tǒng)永遠無法正常工作，也無法靠打補丁來正常運作。你必須從一個簡單系統(tǒng)起步。

只所以有種種誤導(dǎo)，部分原因來自于大家對“最佳實踐“的信任和盲從。隨著阿里、京東、騰訊等互聯(lián)網(wǎng)企業(yè)的成功，有很多的內(nèi)部人、外部人總結(jié)出大量的”最佳實踐“，這些最佳實踐有的確實是干貨，有的卻是道聽途說、人云亦云，還有的干脆另有目的，只是為了向你推銷他們的云服務(wù)、培訓(xùn)、書籍，或者干脆兜售他們自己，以期吸引別人的投資或找到新的工作機會。

即使是那些正確的最佳實踐，也只是別人的，是符合別人現(xiàn)在的市場地位、客戶價值、產(chǎn)品形態(tài)、能力現(xiàn)狀的，不見得適合你。這就如同組織架構(gòu)，一個初創(chuàng)公司，一定是老板兼銷售兼技術(shù)兼保安，老板娘任CHO兼CFO兼會計兼前臺兼行政，難道你要學(xué)習(xí)上市公司，建立董事會、聘請獨立董事、聘任CFO、CIO、CHO等專業(yè)崗位嗎？

當你是個窮小子時，你可以學(xué)習(xí)億萬富翁的創(chuàng)業(yè)精神，但你沒有賺到幾個小目標時，你無法承擔得起大宅、豪車、名酒、美人，你也無法自己出資拍電影，你無法像他們那樣生活，你負擔不起！你能做的是學(xué)習(xí)他們的為人之道、他們的客戶之心、他們的堅忍不拔，他們的永不放棄！

不好意思，跑題了。不管怎樣，我認為在某些情況下微服務(wù)是正確的選擇，尤其是你是Google、SAP、Salesforce那樣的企業(yè)，有著幾百種產(chǎn)品、有著億計的用戶，你確實需要精心設(shè)計的微服務(wù)，你也有實力、有時間來做詳細的規(guī)劃和設(shè)計。但如果你不是，你更應(yīng)該清醒地思考各種方案和假設(shè)，錯誤的決策可能會拖垮公司，還不如順其自然來的好一些。

八、 管理多個服務(wù)很容易？

如果你是產(chǎn)品經(jīng)理，你就會發(fā)現(xiàn)，軟件工程師的時間和其他人的時間不一樣，當他對你說“我這個周末可以完成“、”還差一點點“、”這個很簡單，只需要一個禮拜“時，你應(yīng)該把這個時間乘上一個系數(shù)，系數(shù)的范圍是2到無窮大。我猜，這可能就是相對論吧。

鼓吹微服務(wù)的人有著同樣的樂觀情緒，他們的鐘總是走得比其他人的要慢很多。事實上，實踐中總有兩個問題等著你去解決：這樣的問題、那樣的問題。

你設(shè)計好了微服務(wù)的內(nèi)部邏輯和外部接口，然后大家進行開發(fā)、測試，好不容易通過了，game over了？No，No，No，游戲剛開始，A調(diào)用者說缺了一個方法，B調(diào)用者說參數(shù)有問題，C調(diào)用者說希望你把結(jié)果再封裝一下，D調(diào)用者說他是移動端，希望你精減返回值以減少網(wǎng)絡(luò)傳輸…

測試人員成天抱怨，持續(xù)集成沒有有效工作，總有人忘記提交代碼，測試庫的數(shù)據(jù)被人改動甚至清空了，阻塞型的BUG導(dǎo)致測試舉步維艱，性能測試的資源不容易搶到，要測試的場景太多太多…

服務(wù)之間的依賴使得“獨立部署“毫無意義，你在線上環(huán)境中發(fā)現(xiàn)的問題永遠無法在測試環(huán)境中重現(xiàn)，前
端和后端總是在互相推卸責任，安全性和健壯性好像沒有以前好了，由于服務(wù)間互相調(diào)用的影響，單一的性能改進沒有反映到客戶端…

系統(tǒng)好不容易運轉(zhuǎn)起來了，在數(shù)據(jù)分析時發(fā)現(xiàn)還是不夠，缺東少西，沒辦法，再重新回頭，開發(fā)下一個迭代版本吧…

總結(jié)

在構(gòu)建大型應(yīng)用時，微服務(wù)確實是一種有效的模式，但是要謹慎地使用它，過度的細化設(shè)計會使你陷入進退維艱的境地。當你規(guī)模較小時，可以不使用微服務(wù)或者使用“微服務(wù)架構(gòu)“+”宏服務(wù)“+“小部分微服務(wù)”，千萬不要因為不可預(yù)知的未來在現(xiàn)在投入太多不必要的成本。

總而言之，不要過度迷信微服務(wù)，微服務(wù)就是個傳說！

總結(jié)

以上是生活随笔為你收集整理的不要迷信微服务，微服务就是个传说的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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