今天這篇文章我們繼續說架構師大劉的故事，

故事純屬虛構，別對號入座哈，

前言

大劉日子最近還不錯，經常午睡醒來，就繼續拿著手機看小說摸魚，大劉對當前所在的這家公司比較滿意，大部分系統已經成熟穩定，用戶量也中規中矩，雖然有些專案技術陳舊，但好處是沒啥幺蛾子技術問題冒出來等著解決，

只是有時候大劉心里會打鼓，公司盈利在下降，巔峰不在，也不知道這家公司能撐多久，除了偶然會冒出些對作業穩定的擔憂以外，大部分時候，大劉心情都是愉快的，直到他被領導叫到辦公室分派新任務的那一刻……

大劉的領導 CTO 老李，這些日子心情不是很好，他在的這家公司原本是個以傳統業務為主的公司，為了跟上互聯網時代，大老板拍腦袋成立了個技術部門搞互聯網，雖說公司已經號稱觸網了，但是公司盈利基本還是靠傳統業務，技術部門只是打輔助的，沒有業務主動權，沒有盈利點，部門員工的工資卻都不低，老李的地位就可見一般了，經常受些冷言冷語的夾板氣，再加上，最近公司的效益也有所下降，眼見技術部門面臨著裁員的危險，老李危機意識被極大的刺激到了，

老李是個技術出身，但是離開一線編碼已經快十年了，每天的作業其實就是管理加玩概念，這幾年微服務的概念非常火爆，老李一直想著能搞點這種熱門東西，然后再拿著這些做出來的新概念技術，給那個不懂技術的大老板展示下自己的兩把刷子，同時也能打響在業界的名聲，對自己的職業發展也大有好處，趁著構思部門前途這時當，老李認為這也是搞微服務的好時機，同時也想到了有微服務經驗的大劉，于是，大劉就被召喚進了辦公室……

經過了幾個小時的討論，大劉面帶無奈的接下了這個任務，這個任務是這樣的：

把公司里幾套運行多年的核心系統改造成微服務，

這些個老系統當初是按照幾萬用戶量的目標去設計開發的，雖然現在跑著沒問題，但是眼光要看長遠，產品和技術們將搞一套更高級的東西，目標是這套系統會被幾百萬人使用，

OK，微服務使用的前提出現了，

大劉來這家公司之前，在某電商大廠干了多年，對微服務在電商系統中的應用這塊有實踐、有經驗，對微服務這塊，大劉是吃過豬肉、也見過豬跑，還被豬咬過……嗯，對，還被咬過不止一口兩口，所以，對改造微服務這個任務，大劉是硬著頭皮接下來的，

大劉雖然無奈，但是看在工資的份上活還得干，不過槽還是要吐的，于是下班后大劉用了幾小時碼出了下面這堆心里話，

正文開始（以下是大劉的第一人稱）：

0

最近，經常有同事和我聊微服務，也屢屢期望對公司已有專案進行改造，希望能把所有專案改造成微服務方式，我對此經常很無語，也屢屢對這些人進行勸阻，

我認為，勸我改造微服務的人之中，有一些人純粹的對技術癡迷太深，更甚些，我甚至可以說這些人中的某些人就是純粹的自私自利，搞微服務難道不是為了蹭熱點，為自己的簡歷增色，為下一步跳槽漲薪做準備？何嘗想過微服務為公司帶來的各種壞處和因此而來的成本提升？另外有些人，則純粹是被外面鋪天蓋地的微服務概念給打暈了頭，被各種微服務成功故事洗了腦，這些人，把微服務當成了萬能藥，純粹就是腦袋犯了糊涂，陷入了唯技術論，

為了說明微服務不是萬能藥，這里我們就先要說明下微服務的概念，同時呢，我們也需要詮釋清楚微服務的優缺點，看看什么時候用微服務，什么時候不用，

什么是微服務？對于微服務的定義，網上眾說紛紜，并沒有一個權威的定義，但是在這些紛繁復雜，云山霧罩的各種微服務洗腦文和說明文之后，總是有一個統一的基本面在：即微服務是一種利用分治法的思想，去把一整套非常復雜的業務邏輯給切分成多個簡單的業務問題，并采用模塊化方法去實作組合的一種架構方法，

這么說是不是還很抽象呢？好，咱們再更深入的解釋下，并順便把微服務的優缺點也全部一并說清楚，

1

首先，微服務是采用分治法思想，需要對業務邏輯做分解，做完分解后，還需要多個對應的實作模塊去實作分解后的業務問題，這些模塊的開發和維護，是都需要成本的，如果我們要搞微服務，考慮過開發維護成本嗎？

上面這圖表明了，從專案一開始，微服務的代碼開發和維護每行平均成本就不少，隨著專案規模和系統復雜度的上升，代碼的開發和維護平均成本才會緩慢下降并逐漸收斂到某一個值左右恒定，

而單體專案正好相反，一開始，單體專案的每行代碼平均成本是比較低的，隨著專案規模和系統復雜度的上升，代碼開發和維護成本會慢慢上漲，后續可能復雜度和開發成本會越來越高，一直沖上天際，

這時候，就不得不迫使人們去找到一種比較合適的方法，能把開發和維護成本降低到專案團隊可以承受的程度，

這就是引入微服務的意義所在，

但是，所有的專案會一直發展下去嗎？所有的專案會永遠運行并擴展嗎？

有很多的架構師或者技術人員，在一開始做架構和系統設計的時候，不考慮實際情況，在公司給出一項很緊迫的任務之后，不去考慮實作時間和開發成本，上來就搞高大上，起手就是微服務，這現實嗎？

我們這些技術人員看過許多鼓吹微服務的技術書籍，也看到過很多微服務的“成功學”，但是他們的前提是什么？他們對微服務的說法統統是建立在一個只有技術存在的完美世界里，把現實世界他們認為的一切雜音都摒除在外，這合適嗎？

我們在做架構師之前，第一個考慮的應該是投入和產出，固然，我們從技術角度考慮，一定會要考慮可擴展性，可維護性之類的技術指標，但是，我們也需要根據當前專案的重要程度，盈利前景，還有可用服務器資源等，作出自己的平衡來，

2

第二，微服務的另一個優勢是彈性化，什么意思呢？就是我們在業務邏輯改變時，那些對應業務邏輯改變的功能的增刪改，開發和部署成本很低，可以像彈簧一樣，自由的縮減和增加，

并且，微服務里最佳實踐是每個分出的模塊應該都有自己的資料庫，和別的微服務并不共享任何資料庫，所以微服務本身認為，每個微服務模塊的資料庫都可以不一樣，

比如我們開發一個電商網站，如果搞成微服務，大概如下:

如果我們的業務邏輯做了一些調整，比如，我們想要增加一個積分功能，那么，我們只需要再增加一個叫做積分的微服務即可，

這就是微服務的便利之處，

但是，我們承認吧，并不是我們所做的每個系統都足夠大，都大到需要分解成更多更小的服務，那些不是太復雜的系統，它們憑什么需要彈性化？憑什么需要切分業務，從而搞出一大堆的專案出來呢？

另外，微服務的彈性化帶來的問題就是，我們需要管理因為彈性化所切分的許多小專案，需要搞出一套易用的自動化管理系統，需要把公司的底層基礎設定打造好，請問，這些成本，你準備付出了嗎？

在這個現實的世界里，并不是一切圍繞著技術打轉的，固然，技術欠債會讓我們這些技術從業者感到分外的困擾和難受，可是，假如我們超前超度的使用了我們可能并不需要的超前概念和超前架構，同樣會使我們感到痛苦，

如果我們控制住了自己的技術欲望，我們是不是從自身也控制了一部分技術欠債呢？這是一個架構師應該要思考的地方，也是我們不應該濫用微服務的原因之一，

3

第三，微服務起手就是分布式，分布式我承認有各種各樣的優點，但是，分布式引發的各種問題和因此需要引入的各種技術解決方案本身也有自身的問題，

比如，分布式事務，在引入微服務前，我們作為架構師，一定要思考后續是不是可能出現跨服務的事務，兄弟，分布式事務大家都知道有多困難的，

按照微服務的標準，服務之間的通訊應該盡量采用簡單的 RESTFUL 協議，那么，根據這種規范，如果我們采用了微服務方式架構，我們的每個專案都應該搞成 REST 服務，REST 服務本身就是無狀態的，現在，如果業務里出現了嚴重依賴狀態的跨服務事務，想想吧，你會面臨什么：

分布式鎖方案你是不是要考慮下？分布式互鎖后，出現了死鎖，你的追蹤策略是什么？如果出現了競爭資源，導致服務狀態不一致了，你怎么去快速恢復？資料腐蝕你有辦法嗎？

什么？你告訴我我說市面上有很多成熟的分布式事務解決方案？別自欺欺人了，咱們都是搞技術的，請問，你說的是兩階段提交（2PC）嗎？好吧，大家都知道 2PC 那可憐兮兮的性能，

好吧，那三階段提交（3PC）呢？它的不一致問題曾經讓我們徹夜難眠，

搞 TCC 或者 SAGA 呢？對不起，因為最終一致性所添加的業務緊耦合的各種訊息和通知，會直接猶如 24 小時的夢魘，可能會是壓垮你的最后一根稻草，

微服務的提倡者老馬丁自己也說，微服務引入了最終一致性問題，

對于原來單體專案很簡單的事務問題，在微服務中，是一個令人皺眉的困難問題，所有微服務的開發者，在開發微服務代碼之前，都需要考慮怎么能探測到資料不一致的問題，否則，一定會萬分后悔，

那么，分布式事務會不會一定會出現在微服務中呢？從目前來看，幾乎無法避免，為了搞定這些問題，微服務實作往往還需要伴隨著實作一整套構建在無狀態服務之上的呼叫鏈，

對于這些額外的開發成本，我們有必要嗎？是所有專案都需要的嗎？不是吧，這就是我們架構師需要考慮的問題，也是我們需要謹慎和妥協的地方，

4

第四，微服務互相之間是通過網路通信配合起來來對外提供服務的，這就會帶來一個依賴性問題，即微服務非常依賴底層網路的健康，

如果網路通信之間出了問題，整體對外的服務質量就會降低到極其讓人難以接受的程度，

并且，網路通信天然就一定會帶來延遲，本來單體專案我們好好的，大家都是在內部互相通信，延遲基本可以忽略不計，

現在，大家分開了，互相得遠距離打招呼，延遲動不動就來個幾十毫秒幾百毫秒延遲，這些延遲，我們也需要考慮在內，必須經過嚴格的測驗才可以，

另外，網路通信出現問題后的各種容錯方案，也必須考慮完善，以上說的這些，也都是一個合格的架構師必須在微服務引入之前，所要進行的綜合的考量，

5

其他：微服務的引入還有各種各樣的問題，包括:

額外引入的復雜性
微服務在上面我也說過了，會帶來各種各樣的成本的提升，也會引入各種各樣的技術問題，這些最終就會導致整體系統復雜性進一步的提高，當復雜性提高的時候，為了保證系統的穩定，就需要整體技術團隊的靠譜，就需要技術人員的靠譜，就需要整體技術設施搭建的靠譜，在引入微服務之前，各位兄臺麻煩捫心自問下，這些貴公司有嗎？有這些團隊、這些設施、這些資源嗎？
分布式本身帶來的成本
分布式本身就需要一整套完整的技術體系和設施去支撐整體分布式的建設，比如，以前單體專案只需要一個專案，直接人工上線就好了，現在呢，可能會出現幾十個上百個專案，這些專案如果全靠人工去做，會徹底讓團隊人員瘋掉，所以，就需要把整體發布，部署自動化起來，這里還僅僅是發布部署所需要的，還沒有談維護問題，用《征服》煉訓強里的一句話說:”你有這個實力嗎？”
維護和監控微服務所需要的 DevOps 團隊
微服務本身需要維護和監控，以確保運行的穩定和可靠，在微服務的最佳實踐里，是非常推薦搞 DevOps 的，我暫且不說 DevOps 需要的對人員水平的高要求，我就說 DevOps 本身所需要的作業態度和責任心問題，自己家的運維團隊搭建是個什么鳥樣子，運維成天忙死了再干嘛，誰還不清楚嗎？整體運維的平均水準加上開發水平的要求，這個團隊搭建下來要花多少錢？公司舍得這些投入嗎？
微服務本身所需要的經驗
微服務本身是很復雜的，從設計劃分模塊開始，就需要架構師必須對架構設計和微服務本身對應的 DDD 領域驅動設計非常有經驗，能夠恰到好處的劃分出對應的模塊，否則，一旦設計完畢，不巧把一些緊耦合的服務給硬是解耦成了不同的服務，那么，這個后果對整個技術團隊甚至對整個專案團隊都是災難性的，同時，對于微服務的開發、維護、運行、保障以及運維，都需要技術團隊成員要有很豐富的從業經驗能迅速發現，定位，解決可能隨時出現的問題才可以，如果技術問題不能及時解決，那整體系統的體驗就可想而知了，但是，現在的經濟環境，現在的公司技術人員構成，確定能有這些很豐富經驗的人員來搞微服務嗎？
鏈路測驗的方法
我們上面提到過，為了快速追蹤定位死鎖或者共享資源的問題，微服務需要靠譜的呼叫鏈實作，那么，這就引出的新的問題：我們如何搞全鏈路測驗？我們是不是還得搞一套合適的全鏈路測驗工具才可以？這全鏈路測驗工具開發又需要花多長時間，需要投入多少人力？測驗人員的水平是不是也需要得到一定的保證？
微服務日志的爆炸
微服務本身有多個節點，這些節點為了自己的安全運行和維護，需要很多自己獨有的日志，這些日志隨著微服務的增多，也越來越多，你如何存？如何查？如何刪？這些是不是都要考慮在內？