今天這篇文章咱們繼續說架構師大劉的故事。程序員
故事純屬虛構，別對號入座哈。數據庫
前言
大劉日子最近還不錯，常常午睡醒來，就繼續拿着手機看小說摸魚。大劉對當前所在的這家公司比較滿意。大部分系統已經成熟穩定，用戶量也中規中矩。雖然有些項目技術陳舊，但好處是沒啥幺蛾子技術問題冒出來等着解決。安全
只是有時候大劉內心會打鼓，公司盈利在降低，巔峯不在，也不知道這家公司能撐多久。除了偶然會冒出些對工做穩定的擔心之外，大部分時候，大劉心情都是愉快的。直到他被領導叫到辦公室分派新任務的那一刻……服務器
大劉的領導 CTO 老李，這些日子心情不是很好。他在的這家公司本來是個以傳統業務爲主的公司。爲了跟上互聯網時代，大老闆拍腦殼成立了個技術部門搞互聯網。雖然說公司已經號稱觸網了，可是公司盈利基本仍是靠傳統業務，技術部門只是打輔助的。沒有業務主動權，沒有盈利點，部門員工的工資卻都不低，老李的地位就可見通常了，常常受些冷言冷語的夾板氣。再加上，最近公司的效益也有所降低，眼見技術部門面臨着裁人的危險。老李危機意識被極大的刺激到了。網絡
老李是個技術出身，可是離開一線編碼已經快十年了，天天的工做其實就是管理加玩概念。這幾年微服務的概念很是火爆，老李一直想着能搞點這種熱門東西，而後再拿着這些作出來的新概念技術，給那個不懂技術的大老闆展現下本身的兩把刷子，同時也能打響在業界的名聲，對本身的職業發展也大有好處。趁着構思部門前途這時當，老李認爲這也是搞微服務的好時機，同時也想到了有微服務經驗的大劉。因而，大劉就被召喚進了辦公室……架構
通過了幾個小時的討論，大劉面帶無奈的接下了這個任務。這個任務是這樣的：運維
把公司裏幾套運行多年的核心繫統改形成微服務。分佈式
這些個老系統當初是按照幾萬用戶量的目標去設計開發的，雖然如今跑着沒問題，可是眼光要看長遠，產品和技術們將搞一套更高級的東西，目標是這套系統會被幾百萬人使用。模塊化
OK，微服務使用的前提出現了。微服務
大劉來這家公司以前，在某電商大廠幹了多年，對微服務在電商系統中的應用這塊有實踐、有經驗。對微服務這塊，大劉是吃過豬肉、也見過豬跑，還被豬咬過……嗯，對，還被咬過不止一口兩口。因此，對改造微服務這個任務，大劉是硬着頭皮接下來的。
大劉雖然無奈，可是看在工資的份上活還得幹。不過槽仍是要吐的，因而下班後大劉用了幾小時碼出了下面這堆內心話。
正文開始（如下是大劉的第一人稱）：
—0—
最近，常常有同事和我聊微服務，也屢屢指望對公司已有項目進行改造，但願能把全部項目改形成微服務方式。我對此常常很無語，也屢屢對這些人進行勸阻。
我認爲，勸我改造微服務的人之中，有一些人純粹的對技術癡迷太深。更甚些，我甚至能夠說這些人中的某些人就是純粹的自私自利。搞微服務難道不是爲了蹭熱點，爲本身的簡歷增色，爲下一步跳槽漲薪作準備？未嘗想過微服務爲公司帶來的各類壞處和所以而來的成本提高？另外有些人，則純粹是被外面鋪天蓋地的微服務概念給打暈了頭，被各類微服務成功故事洗了腦。這些人，把微服務當成了萬能藥，純粹就是腦殼犯了糊塗，陷入了惟技術論。
爲了說明微服務不是萬能藥，這裏咱們就先要說明下微服務的概念。同時呢，咱們也須要詮釋清楚微服務的優缺點，看看何時用微服務，何時不用。
什麼是微服務？對於微服務的定義，網上衆說紛紜，並無一個權威的定義。可是在這些紛繁複雜，雲山霧罩的各類微服務洗腦文和說明文以後，老是有一個統一的基本面在：即微服務是一種利用分治法的思想，去把一整套很是複雜的業務邏輯給切分紅多個簡單的業務問題，並採用模塊化方法去實現組合的一種架構方法。
這麼說是否是還很抽象呢？好，我們再更深刻的解釋下，並順便把微服務的優缺點也所有一併說清楚。
—1—
首先，微服務是採用分治法思想，須要對業務邏輯作分解。作完分解後，還須要多個對應的實現模塊去實現分解後的業務問題。這些模塊的開發和維護，是都須要成本的。若是咱們要搞微服務，考慮過開發維護成本嗎？
上面這圖代表了，從項目一開始，微服務的代碼開發和維護每行平均成本就很多，隨着項目規模和系統複雜度的上升，代碼的開發和維護平均成本纔會緩慢降低並逐漸收斂到某一個值左右恆定。
而單體項目正好相反，一開始，單體項目的每行代碼平均成本是比較低的，隨着項目規模和系統複雜度的上升，代碼開發和維護成本會慢慢上漲，後續可能複雜度和開發成本會愈來愈高，一直衝上天際。
這時候，就不得不迫令人們去找到一種比較合適的方法，能把開發和維護成本下降到項目團隊能夠承受的程度。
這就是引入微服務的意義所在。
可是，全部的項目會一直髮展下去嗎？全部的項目會永遠運行並擴展嗎？
有不少的架構師或者技術人員，在一開始作架構和系統設計的時候，不考慮實際狀況，在公司給出一項很緊迫的任務以後，不去考慮實現時間和開發成本，上來就搞高大上，起手就是微服務，這現實嗎？
咱們這些技術人員看過許多鼓吹微服務的技術書籍，也看到過不少微服務的「成功學」，可是他們的前提是什麼？他們對微服務的說法通通是創建在一個只有技術存在的完美世界裏，把現實世界他們認爲的一切雜音都摒除在外，這合適嗎？
咱們在作架構師以前，第一個考慮的應該是投入和產出。當然，咱們從技術角度考慮，必定會要考慮可擴展性，可維護性之類的技術指標。可是，咱們也須要根據當前項目的重要程度，盈利前景，還有可用服務器資源等，做出本身的平衡來。
—2—
第二，微服務的另外一個優點是彈性化。什麼意思呢？就是咱們在業務邏輯改變時，那些對應業務邏輯改變的功能的增刪改，開發和部署成本很低，能夠像彈簧同樣，自由的縮減和增長。
而且，微服務裏最佳實踐是每一個分出的模塊應該都有本身的數據庫，和別的微服務並不共享任何數據庫。因此微服務自己認爲，每一個微服務模塊的數據庫均可以不同。
好比咱們開發一個電商網站，若是搞成微服務，大概以下:
若是咱們的業務邏輯作了一些調整，好比，咱們想要增長一個積分功能，那麼，咱們只須要再增長一個叫作積分的微服務便可。
這就是微服務的便利之處。
可是，咱們認可吧，並非咱們所作的每一個系統都足夠大，都大到須要分解成更多更小的服務。那些不是太複雜的系統，它們憑什麼須要彈性化？憑什麼須要切分業務，從而搞出一大堆的項目出來呢？
另外，微服務的彈性化帶來的問題就是，咱們須要管理由於彈性化所切分的許多小項目，須要搞出一套易用的自動化管理系統，須要把公司的底層基礎設置打造好，請問，這些成本，你準備付出了嗎？
在這個現實的世界裏，並非一切圍繞着技術打轉的。當然，技術欠債會讓咱們這些技術從業者感到分外的困擾和難受。但是，假如咱們超前超度的使用了咱們可能並不須要的超前概念和超前架構，一樣會使咱們感到痛苦。
若是咱們控制住了本身的技術慾望，咱們是否是從自身也控制了一部分技術欠債呢？這是一個架構師應該要思考的地方，也是咱們不該該濫用微服務的緣由之一。
—3—
第三，微服務起手就是分佈式。分佈式我認可有各類各樣的優勢，可是，分佈式引起的各類問題和所以須要引入的各類技術解決方案自己也有自身的問題。
好比，分佈式事務。在引入微服務前，咱們做爲架構師，必定要思考後續是否是可能出現跨服務的事務。兄弟，分佈式事務你們都知道有多困難的。
按照微服務的標準，服務之間的通信應該儘可能採用簡單的 RESTFUL 協議。那麼，根據這種規範，若是咱們採用了微服務方式架構，咱們的每一個項目都應該搞成 REST 服務。REST 服務自己就是無狀態的，如今，若是業務裏出現了嚴重依賴狀態的跨服務事務，想一想吧，你會面臨什麼：
分佈式鎖方案你是否是要考慮下？分佈式互鎖後，出現了死鎖，你的追蹤策略是什麼？若是出現了競爭資源，致使服務狀態不一致了，你怎麼去快速恢復？數據腐蝕你有辦法嗎？
什麼？你告訴我我說市面上有不少成熟的分佈式事務解決方案？別自欺欺人了，我們都是搞技術的，請問，你說的是兩階段提交（2PC）嗎？好吧，你們都知道 2PC 那可憐兮兮的性能。
好吧，那三階段提交（3PC）呢？它的不一致問題曾經讓咱們徹夜難眠。
搞 TCC 或者 SAGA 呢？對不起，由於最終一致性所添加的業務緊耦合的各類消息和通知，會直接猶如 24 小時的夢魘，可能會是壓垮你的最後一根稻草。
微服務的提倡者老馬丁本身也說，微服務引入了最終一致性問題。
對於原來單體項目很簡單的事務問題，在微服務中，是一個使人皺眉的困難問題。全部微服務的開發者，在開發微服務代碼以前，都須要考慮怎麼能探測到數據不一致的問題。不然，必定會萬分後悔。
那麼，分佈式事務會不會必定會出如今微服務中呢？從目前來看，幾乎沒法避免。爲了搞定這些問題，微服務實現每每還須要伴隨着實現一整套構建在無狀態服務之上的調用鏈。
對於這些額外的開發成本，咱們有必要嗎？是全部項目都須要的嗎？不是吧。這就是咱們架構師須要考慮的問題，也是咱們須要謹慎和妥協的地方。
—4—
第四，微服務互相之間是經過網絡通訊配合起來來對外提供服務的。這就會帶來一個依賴性問題，即微服務很是依賴底層網絡的健康。
若是網絡通訊之間出了問題，總體對外的服務質量就會下降到極其讓人難以接受的程度。
而且，網絡通訊自然就必定會帶來延遲。原本單體項目咱們好好的，你們都是在內部互相通訊，延遲基本能夠忽略不計。
如今，你們分開了，互相得遠距離打招呼，延遲動不動就來個幾十毫秒幾百毫秒延遲。這些延遲，咱們也須要考慮在內，必須通過嚴格的測試才能夠。
另外，網絡通訊出現問題後的各類容錯方案，也必須考慮完善。以上說的這些，也都是一個合格的架構師必須在微服務引入以前，所要進行的綜合的考量。
—5—
其餘：微服務的引入還有各類各樣的問題，包括:
-
額外引入的複雜性
微服務在上面我也說過了，會帶來各類各樣的成本的提高，也會引入各類各樣的技術問題。這些最終就會致使總體系統複雜性進一步的提升。當複雜性提升的時候，爲了保證系統的穩定，就須要總體技術團隊的靠譜，就須要技術人員的靠譜，就須要總體技術設施搭建的靠譜。在引入微服務以前，各位兄臺麻煩捫心自問下，這些貴公司有嗎？有這些團隊、這些設施、這些資源嗎？ -
分佈式自己帶來的成本
分佈式自己就須要一整套完整的技術體系和設施去支撐總體分佈式的建設。好比，之前單體項目只須要一個項目，直接人工上線就行了。如今呢，可能會出現幾十個上百個項目，這些項目若是全靠人工去作，會完全讓團隊人員瘋掉。因此，就須要把總體發佈，部署自動化起來。這裏還僅僅是發佈部署所須要的，尚未談維護問題，用《征服》劉華強裏的一句話說:」你有這個實力嗎？」 -
維護和監控微服務所須要的 DevOps 團隊
微服務自己須要維護和監控，以確保運行的穩定和可靠。在微服務的最佳實踐裏，是很是推薦搞 DevOps 的。我暫且不說 DevOps 須要的對人員水平的高要求，我就說 DevOps 自己所須要的工做態度和責任心問題，本身家的運維團隊搭建是個什麼鳥樣子，運維整天忙死了再幹嗎，誰還不清楚嗎？總體運維的平均水準加上開發水平的要求，這個團隊搭建下來要花多少錢？公司捨得這些投入嗎？ -
微服務自己所須要的經驗
微服務自己是很複雜的，從設計劃分模塊開始，就須要架構師必須對架構設計和微服務自己對應的 DDD 領域驅動設計很是有經驗，可以恰到好處的劃分出對應的模塊。不然，一旦設計完畢，不巧把一些緊耦合的服務給硬是解耦成了不一樣的服務，那麼，這個後果對整個技術團隊甚至對整個項目團隊都是災難性的。同時，對於微服務的開發、維護、運行、保障以及運維，都須要技術團隊成員要有很豐富的從業經驗能迅速發現，定位，解決可能隨時出現的問題才能夠。若是技術問題不能及時解決，那總體系統的體驗就可想而知了。可是，如今的經濟環境，如今的公司技術人員構成，肯定能有這些很豐富經驗的人員來搞微服務嗎？ -
鏈路測試的方法
咱們上面提到過，爲了快速追蹤定位死鎖或者共享資源的問題，微服務須要靠譜的調用鏈實現。那麼，這就引出的新的問題：咱們如何搞全鏈路測試？咱們是否是還得搞一套合適的全鏈路測試工具才能夠？這全鏈路測試工具開發又須要花多長時間，須要投入多少人力？測試人員的水平是否是也須要獲得必定的保證？ -
微服務日誌的爆炸
微服務自己有多個節點，這些節點爲了本身的安全運行和維護，須要不少本身獨有的日誌。這些日誌隨着微服務的增多，也愈來愈多，你如何存？如何查？如何刪？這些是否是都要考慮在內？
以上說的這些問題並非否定微服務。
我只是砸給那些勸我沒事兒就搞微服務的人。對於這些什麼都不考慮，上來就說微服務的人，我認爲都是非蠢既壞。
無論不顧現狀，沒事兒把微服務掛嘴邊動輒怎麼怎麼樣的人，我勸你悠着點。
最後
寫完以後，大劉感受長出了一口胸中的悶氣，過完嘴癮，內心也痛快了。如今大劉最擔憂的是，這些文字千萬別被領導看到……
最最後
大劉的故事講完了，我再囉嗦一下。微服務確定是先進的，可是都已經 2021 年了，不用我再和你們介紹微服務的優勢了，那也太俗了。
但願你們看完能明白，並非什麼新科技，熱概念都適合本身的團隊、本身的項目的。作一個合格的架構師、技術負責人，首先應該遵循的是 KISS 和 YAGNI 原則。
請各位技術人員永遠保持理智，咱們要作的是選擇正確適用的技術而不是選擇本身最喜好的技術。請不要作那種把簡單的事情往復雜裏作的技術瘋子。
你好，我是四猿外，一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把本身的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注個人公衆號，關注以後回覆「666」，送你一些珍藏的資料，幫助你提升技術、進大廠拿高薪。