**

不要迷信微服務，微服務就是個傳說

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

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

一、 微服務是一項很偉大的技術，它能引領公司走向成功？

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

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

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

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

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

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

二、 微服務架構很難，需要聘請專業的人士來設計？

回答這個問題前，要區分“微服務架構”和“微服務”，“微服務架構”并不是很難，但在微服務架構下，設計出合理的“微服務”確實需要經驗和能力。

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

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

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

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

三、 所有產品都要微服務化？

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

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

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

四、 微服務要多“微”？

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

設計微服務時，最重要的工作是把所有產品中重復的模塊獨立出來并封裝，在內部實現相關的業務邏輯，對外部提供相應的接口，并且可以獨立部署，其他需要使用這個模塊的產品都通過標準的接口訪問，這個模塊就可以稱之為一個微服務。

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

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

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

五、 為什么轉向微服務后，成本反而提高了？工期也變長了？

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

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

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

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

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

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

六、 微服務降低了開發的復雜度？提高了開發效率？

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

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

使用微服務架構的大型公司的人都知道，Uber 的經驗（或者更應該說教訓）不是特例，而是一個普遍現象（悄悄說一句，Uber的一個團隊正在把微服務改造成宏服務）。

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

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

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

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

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

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

七、 我們應該一開始就設計出一個完美的微服務系統?

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

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

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

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

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

八、 管理多個服務很容易？

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

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

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

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

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

系統好不容易運轉起來了，在數據分析時發現還是不夠，缺東少西，沒辦法，再重新回頭，開發下一個迭代版本吧…

總結

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。