恕我直言，微服務(wù)挺好，但不適合你……

今天這篇文章我們繼續(xù)說架構(gòu)師大劉的故事。

故事純屬虛構(gòu)，別對號入座哈。

前言

大劉日子最近還不錯，經(jīng)常午睡醒來，就繼續(xù)拿著手機看小說摸魚。大劉對當(dāng)前所在的這家公司比較滿意。大部分系統(tǒng)已經(jīng)成熟穩(wěn)定，用戶量也中規(guī)中矩。雖然有些項目技術(shù)陳舊，但好處是沒啥幺蛾子技術(shù)問題冒出來等著解決。

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

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

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

經(jīng)過了幾個小時的討論，大劉面帶無奈的接下了這個任務(wù)。這個任務(wù)是這樣的：

把公司里幾套運行多年的核心系統(tǒng)改造成微服務(wù)。

這些個老系統(tǒng)當(dāng)初是按照幾萬用戶量的目標(biāo)去設(shè)計開發(fā)的，雖然現(xiàn)在跑著沒問題，但是眼光要看長遠(yuǎn)，產(chǎn)品和技術(shù)們將搞一套更高級的東西，目標(biāo)是這套系統(tǒng)會被幾百萬人使用。

OK，微服務(wù)使用的前提出現(xiàn)了。

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

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

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

— 0 —

最近，經(jīng)常有同事和我聊微服務(wù)，也屢屢期望對公司已有項目進(jìn)行改造，希望能把所有項目改造成微服務(wù)方式。我對此經(jīng)常很無語，也屢屢對這些人進(jìn)行勸阻。

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

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

什么是微服務(wù)？對于微服務(wù)的定義，網(wǎng)上眾說紛紜，并沒有一個權(quán)威的定義。但是在這些紛繁復(fù)雜，云山霧罩的各種微服務(wù)洗腦文和說明文之后，總是有一個統(tǒng)一的基本面在：即微服務(wù)是一種利用分治法的思想，去把一整套非常復(fù)雜的業(yè)務(wù)邏輯給切分成多個簡單的業(yè)務(wù)問題，并采用模塊化方法去實現(xiàn)組合的一種架構(gòu)方法。

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

— 1 —

首先，微服務(wù)是采用分治法思想，需要對業(yè)務(wù)邏輯做分解。做完分解后，還需要多個對應(yīng)的實現(xiàn)模塊去實現(xiàn)分解后的業(yè)務(wù)問題。這些模塊的開發(fā)和維護(hù)，是都需要成本的。如果我們要搞微服務(wù)，考慮過開發(fā)維護(hù)成本嗎？

上面這圖表明了，從項目一開始，微服務(wù)的代碼開發(fā)和維護(hù)每行平均成本就不少，隨著項目規(guī)模和系統(tǒng)復(fù)雜度的上升，代碼的開發(fā)和維護(hù)平均成本才會緩慢下降并逐漸收斂到某一個值左右恒定。

而單體項目正好相反，一開始，單體項目的每行代碼平均成本是比較低的，隨著項目規(guī)模和系統(tǒng)復(fù)雜度的上升，代碼開發(fā)和維護(hù)成本會慢慢上漲，后續(xù)可能復(fù)雜度和開發(fā)成本會越來越高，一直沖上天際。

這時候，就不得不迫使人們?nèi)フ业揭环N比較合適的方法，能把開發(fā)和維護(hù)成本降低到項目團(tuán)隊可以承受的程度。

這就是引入微服務(wù)的意義所在。

但是，所有的項目會一直發(fā)展下去嗎？所有的項目會永遠(yuǎn)運行并擴展嗎？

有很多的架構(gòu)師或者技術(shù)人員，在一開始做架構(gòu)和系統(tǒng)設(shè)計的時候，不考慮實際情況，在公司給出一項很緊迫的任務(wù)之后，不去考慮實現(xiàn)時間和開發(fā)成本，上來就搞高大上，起手就是微服務(wù)，這現(xiàn)實嗎？

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

我們在做架構(gòu)師之前，第一個考慮的應(yīng)該是投入和產(chǎn)出。固然，我們從技術(shù)角度考慮，一定會要考慮可擴展性，可維護(hù)性之類的技術(shù)指標(biāo)。但是，我們也需要根據(jù)當(dāng)前項目的重要程度，盈利前景，還有可用服務(wù)器資源等，作出自己的平衡來。

—?2?—

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

并且，微服務(wù)里最佳實踐是每個分出的模塊應(yīng)該都有自己的數(shù)據(jù)庫，和別的微服務(wù)并不共享任何數(shù)據(jù)庫。所以微服務(wù)本身認(rèn)為，每個微服務(wù)模塊的數(shù)據(jù)庫都可以不一樣。

比如我們開發(fā)一個電商網(wǎng)站，如果搞成微服務(wù)，大概如下:

如果我們的業(yè)務(wù)邏輯做了一些調(diào)整，比如，我們想要增加一個積分功能，那么，我們只需要再增加一個叫做積分的微服務(wù)即可。

這就是微服務(wù)的便利之處。

但是，我們承認(rèn)吧，并不是我們所做的每個系統(tǒng)都足夠大，都大到需要分解成更多更小的服務(wù)。那些不是太復(fù)雜的系統(tǒng)，它們憑什么需要彈性化？憑什么需要切分業(yè)務(wù)，從而搞出一大堆的項目出來呢？

另外，微服務(wù)的彈性化帶來的問題就是，我們需要管理因為彈性化所切分的許多小項目，需要搞出一套易用的自動化管理系統(tǒng)，需要把公司的底層基礎(chǔ)設(shè)置打造好，請問，這些成本，你準(zhǔn)備付出了嗎？

在這個現(xiàn)實的世界里，并不是一切圍繞著技術(shù)打轉(zhuǎn)的。固然，技術(shù)欠債會讓我們這些技術(shù)從業(yè)者感到分外的困擾和難受?？墒?，假如我們超前超度的使用了我們可能并不需要的超前概念和超前架構(gòu)，同樣會使我們感到痛苦。

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

—?3?—

第三，微服務(wù)起手就是分布式。分布式我承認(rèn)有各種各樣的優(yōu)點，但是，分布式引發(fā)的各種問題和因此需要引入的各種技術(shù)解決方案本身也有自身的問題。

比如，分布式事務(wù)。在引入微服務(wù)前，我們作為架構(gòu)師，一定要思考后續(xù)是不是可能出現(xiàn)跨服務(wù)的事務(wù)。兄弟，分布式事務(wù)大家都知道有多困難的。

按照微服務(wù)的標(biāo)準(zhǔn)，服務(wù)之間的通訊應(yīng)該盡量采用簡單的 RESTFUL 協(xié)議。那么，根據(jù)這種規(guī)范，如果我們采用了微服務(wù)方式架構(gòu)，我們的每個項目都應(yīng)該搞成 REST 服務(wù)。REST 服務(wù)本身就是無狀態(tài)的，現(xiàn)在，如果業(yè)務(wù)里出現(xiàn)了嚴(yán)重依賴狀態(tài)的跨服務(wù)事務(wù)，想想吧，你會面臨什么：

分布式鎖方案你是不是要考慮下？分布式互鎖后，出現(xiàn)了死鎖，你的追蹤策略是什么？如果出現(xiàn)了競爭資源，導(dǎo)致服務(wù)狀態(tài)不一致了，你怎么去快速恢復(fù)？數(shù)據(jù)腐蝕你有辦法嗎？

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

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

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

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

對于原來單體項目很簡單的事務(wù)問題，在微服務(wù)中，是一個令人皺眉的困難問題。所有微服務(wù)的開發(fā)者，在開發(fā)微服務(wù)代碼之前，都需要考慮怎么能探測到數(shù)據(jù)不一致的問題。否則，一定會萬分后悔。

那么，分布式事務(wù)會不會一定會出現(xiàn)在微服務(wù)中呢？從目前來看，幾乎無法避免。為了搞定這些問題，微服務(wù)實現(xiàn)往往還需要伴隨著實現(xiàn)一整套構(gòu)建在無狀態(tài)服務(wù)之上的調(diào)用鏈。

對于這些額外的開發(fā)成本，我們有必要嗎？是所有項目都需要的嗎？不是吧。這就是我們架構(gòu)師需要考慮的問題，也是我們需要謹(jǐn)慎和妥協(xié)的地方。

— 4?—

第四，微服務(wù)互相之間是通過網(wǎng)絡(luò)通信配合起來來對外提供服務(wù)的。這就會帶來一個依賴性問題，即微服務(wù)非常依賴底層網(wǎng)絡(luò)的健康。

如果網(wǎng)絡(luò)通信之間出了問題，整體對外的服務(wù)質(zhì)量就會降低到極其讓人難以接受的程度。

并且，網(wǎng)絡(luò)通信天然就一定會帶來延遲。本來單體項目我們好好的，大家都是在內(nèi)部互相通信，延遲基本可以忽略不計。

現(xiàn)在，大家分開了，互相得遠(yuǎn)距離打招呼，延遲動不動就來個幾十毫秒幾百毫秒延遲。這些延遲，我們也需要考慮在內(nèi)，必須經(jīng)過嚴(yán)格的測試才可以。

另外，網(wǎng)絡(luò)通信出現(xiàn)問題后的各種容錯方案，也必須考慮完善。以上說的這些，也都是一個合格的架構(gòu)師必須在微服務(wù)引入之前，所要進(jìn)行的綜合的考量。

—?5?—

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

1. 額外引入的復(fù)雜性
   微服務(wù)在上面我也說過了，會帶來各種各樣的成本的提升，也會引入各種各樣的技術(shù)問題。這些最終就會導(dǎo)致整體系統(tǒng)復(fù)雜性進(jìn)一步的提高。當(dāng)復(fù)雜性提高的時候，為了保證系統(tǒng)的穩(wěn)定，就需要整體技術(shù)團(tuán)隊的靠譜，就需要技術(shù)人員的靠譜，就需要整體技術(shù)設(shè)施搭建的靠譜。在引入微服務(wù)之前，各位兄臺麻煩捫心自問下，這些貴公司有嗎？有這些團(tuán)隊、這些設(shè)施、這些資源嗎？

2. 分布式本身帶來的成本
   分布式本身就需要一整套完整的技術(shù)體系和設(shè)施去支撐整體分布式的建設(shè)。比如，以前單體項目只需要一個項目，直接人工上線就好了?，F(xiàn)在呢，可能會出現(xiàn)幾十個上百個項目，這些項目如果全靠人工去做，會徹底讓團(tuán)隊人員瘋掉。所以，就需要把整體發(fā)布，部署自動化起來。這里還僅僅是發(fā)布部署所需要的，還沒有談維護(hù)問題，用《征服》劉華強里的一句話說:”你有這個實力嗎？”

3. 維護(hù)和監(jiān)控微服務(wù)所需要的 DevOps 團(tuán)隊
   微服務(wù)本身需要維護(hù)和監(jiān)控，以確保運行的穩(wěn)定和可靠。在微服務(wù)的最佳實踐里，是非常推薦搞 DevOps 的。我暫且不說 DevOps 需要的對人員水平的高要求，我就說 DevOps 本身所需要的工作態(tài)度和責(zé)任心問題，自己家的運維團(tuán)隊搭建是個什么鳥樣子，運維成天忙死了再干嘛，誰還不清楚嗎？整體運維的平均水準(zhǔn)加上開發(fā)水平的要求，這個團(tuán)隊搭建下來要花多少錢？公司舍得這些投入嗎？

4. 微服務(wù)本身所需要的經(jīng)驗
   微服務(wù)本身是很復(fù)雜的，從設(shè)計劃分模塊開始，就需要架構(gòu)師必須對架構(gòu)設(shè)計和微服務(wù)本身對應(yīng)的 DDD 領(lǐng)域驅(qū)動設(shè)計非常有經(jīng)驗，能夠恰到好處的劃分出對應(yīng)的模塊。否則，一旦設(shè)計完畢，不巧把一些緊耦合的服務(wù)給硬是解耦成了不同的服務(wù)，那么，這個后果對整個技術(shù)團(tuán)隊甚至對整個項目團(tuán)隊都是災(zāi)難性的。同時，對于微服務(wù)的開發(fā)、維護(hù)、運行、保障以及運維，都需要技術(shù)團(tuán)隊成員要有很豐富的從業(yè)經(jīng)驗?zāi)苎杆侔l(fā)現(xiàn)，定位，解決可能隨時出現(xiàn)的問題才可以。如果技術(shù)問題不能及時解決，那整體系統(tǒng)的體驗就可想而知了。但是，現(xiàn)在的經(jīng)濟(jì)環(huán)境，現(xiàn)在的公司技術(shù)人員構(gòu)成，確定能有這些很豐富經(jīng)驗的人員來搞微服務(wù)嗎？

5. 鏈路測試的方法
   我們上面提到過，為了快速追蹤定位死鎖或者共享資源的問題，微服務(wù)需要靠譜的調(diào)用鏈實現(xiàn)。那么，這就引出的新的問題：我們?nèi)绾胃闳溌窚y試？我們是不是還得搞一套合適的全鏈路測試工具才可以？這全鏈路測試工具開發(fā)又需要花多長時間，需要投入多少人力？測試人員的水平是不是也需要得到一定的保證？

6. 微服務(wù)日志的爆炸
   微服務(wù)本身有多個節(jié)點，這些節(jié)點為了自己的安全運行和維護(hù)，需要很多自己獨有的日志。這些日志隨著微服務(wù)的增多，也越來越多，你如何存？如何查？如何刪？這些是不是都要考慮在內(nèi)？

以上說的這些問題并不是否認(rèn)微服務(wù)。

我只是砸給那些勸我沒事兒就搞微服務(wù)的人。對于這些什么都不考慮，上來就說微服務(wù)的人，我認(rèn)為都是非蠢既壞。

不管不顧現(xiàn)狀，沒事兒把微服務(wù)掛嘴邊動輒怎么怎么樣的人，我勸你悠著點。

最后

寫完之后，大劉感覺長出了一口胸中的悶氣，過完嘴癮，心里也痛快了。現(xiàn)在大劉最擔(dān)心的是，這些文字千萬別被領(lǐng)導(dǎo)看到……

最最后

大劉的故事講完了，我再啰嗦一下。微服務(wù)肯定是先進(jìn)的，但是都已經(jīng) 2020 年了，不用我再和大家介紹微服務(wù)的優(yōu)點了，那也太俗了。

希望大家看完能明白，并不是什么新科技，熱概念都適合自己的團(tuán)隊、自己的項目的。做一個合格的架構(gòu)師、技術(shù)負(fù)責(zé)人，首先應(yīng)該遵循的是 KISS 和 YAGNI 原則。

請各位技術(shù)人員永遠(yuǎn)保持理智，我們要做的是選擇正確適用的技術(shù)而不是選擇自己最喜愛的技術(shù)。請不要做那種把簡單的事情往復(fù)雜里做的技術(shù)瘋子。

END

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝