至從ThoughtWorks的 Martin Fowler 喊出來“微服務”，IT業(yè)界仿佛打了一陣強心劑，從互聯(lián)網(wǎng)行業(yè)，到相對保守的電信，金融業(yè)，都在對著自己的系統(tǒng)，拿著拆遷大錘躍躍欲試，想一拆為快。微服務到底給我們帶來了什么，用微服務真的就是萬能解藥嗎？今天就來侃侃這個話題。

這文章本來計劃要寫一篇就搞定，后來發(fā)現(xiàn)內(nèi)容還是比較多，就拆成幾部分來寫，這樣可以寫的更加透徹。
本文假定的讀者是那些已經(jīng)對微服務有了一點兒了解，并且已經(jīng)計劃要按照微服務風格進行系統(tǒng)改造了的拆遷預備隊們。

1. 為什么要拆，單片系統(tǒng)的七宗罪

說到傳統(tǒng)系統(tǒng)，大致可以想象成這個樣子，系統(tǒng)在橫向功能上按照模塊分開，在縱向上分成控制層，業(yè)務層，數(shù)據(jù)訪問層等幾層。無論是模塊間的調(diào)用，還是功能層次間的調(diào)用，幾乎都是代碼級調(diào)用。一個系統(tǒng)代碼動輒10萬行起步，極其龐大，我曾經(jīng)用瑞士軍刀來形容這種系統(tǒng)。

單片系統(tǒng)如瑞士軍刀一樣，功能齊全

過去幾十年我們一直在開發(fā)這樣的系統(tǒng)，我們謹慎的建立業(yè)務模型，梳理業(yè)務流程，做好每一個模塊的設計，并嘗試做好通用模塊。然后經(jīng)過數(shù)月甚至經(jīng)年的開發(fā)，再花費更長的時間進行各種測試，最后交付給客戶。這種系統(tǒng)集所有功能于一身，什么都能干，用瑞士軍刀來形容一點兒也不為過。

以下單片系統(tǒng)的這些問題會隨著代碼量的增大而變得嚴重，大就是原罪。

當今環(huán)境下，單片系統(tǒng)暴露出的不足：

• 代碼規(guī)模龐大，難于讀懂，難于修改，難于維護，甚至修改幾行代碼，要做超過預想的大規(guī)模測試。
• 開發(fā)周期長，很多系統(tǒng)都需要以半年為單位來計算上線時間，對于業(yè)務更新頻繁的系統(tǒng)，單片系統(tǒng)模式更是難以應對，尤其是互聯(lián)網(wǎng)產(chǎn)品。
• 技術(shù)棧單一，通常一個技術(shù)棧能夠解決整個系統(tǒng)90%的問題，但是總有那么些特例，讓架構(gòu)師，讓開發(fā)人員費盡腦筋去找一些折衷方案，不能用最合適的技術(shù)棧去解決問題。
• 難以部署，一個單片系統(tǒng)功能眾多，配置文件有時真的如滿天繁星，上線那幾天徹夜的日子想必大家都經(jīng)歷過，上線之前燒柱香，祈禱疏通測試順利通過這是常例吧。
• 某些bug會搞垮整個系統(tǒng)，單片系統(tǒng)內(nèi)部功能模塊通常共享一個進程空間，如果某個處理破壞了整體運行環(huán)境（比如內(nèi)存泄漏），那系統(tǒng)就會崩潰，影響極其巨大。
• 對客戶反饋慢，從筆者的經(jīng)驗來講，客戶第一次碰到能動的系統(tǒng)，常常是CUT結(jié)束的那個階段，我們叫它 alpha版，但那通常已經(jīng)是三個月以后的事情了。如果這個時候客戶說這不是我想要的，就需要大返工，將影響后面的結(jié)合測試，系統(tǒng)測試，最終影響上線時間。而很明顯的，修改時機拖的越晚，風險越大。
• 高可用要求下，通常以整個系統(tǒng)為單位，進行冗余擴張，也就是完全一樣的系統(tǒng)拷貝一份兒留著當備份，極其浪費資源。而且當系統(tǒng)真正面對客戶使用量潮汐壓力的時候，又很難快速的擴張實例來進行擴容，靈活性差。

其實還可以寫很多，但是為了切題，就不大批特批了，畢竟用了單片系統(tǒng)好多年，不能太過分。

2. 拆分時代的罪與罰

微服務的概念，特征，原則這些東西咱就不掰了。去中心化，各個服務協(xié)同，高內(nèi)聚，低耦合，獨立進化……天天的吹著交付快，部署快，修改快，性能伸縮快，耳朵磨一層繭子。好多人看完了馬丁那書，對著自己眼前那幾十萬行代碼，都躍躍欲試拿著錘子去過一把拆遷隊的癮，但是掄起你的錘子之前先等等，看看下面這一段再說。

微服務風格的架構(gòu)就像工具箱，擺放清晰，但是總體變得更加龐大

以下這些問題，會隨著拆分粒度變細而變得顯著，相對單片系統(tǒng)的大是原罪，微服務小也是原罪。

2.1.真的容易維護了嗎？

拆分以后，各個服務代碼規(guī)模變?。ㄒ苍S真的能夠達到數(shù)千行的級別），對于單個服務來講可能更容易維護，但是服務之間都使用MQ，RPC來進行通信，要弄懂全盤一樣要跟著調(diào)用鏈跑遍整個系統(tǒng)，調(diào)用鏈的增長，隨之而來的一樣是難于讀懂，難于修改，難于維護，出了bug難于調(diào)查，在這一點上，微服務和單片系統(tǒng)不分伯仲。

還有一點要說，就個人經(jīng)驗來講，微服務風格實現(xiàn)同樣一套功能，需要的代碼實際更多了（后面還會講哪些變多了），最簡單的例子，有些通用代碼例如StringUtils到處都要寫（你總不能把StringUtils也做成一個服務吧 ）。

2.2. 真的更加容易治理嗎？

SOA時代還有一個ESB，要治理服務只要順著ESB這條主線看過去就可以，到了微服務時代，ESB都被丟棄了，想在框架上做好治理，幾乎成為一件不可能的事情，甚至都無法預測將來這個服務要被多少個其他服務調(diào)用。

其實用西方的民主制度做比喻非常形象，他們推崇的是每個人都有權(quán)利做決定，每個人都應該參與其中，但是這里有一個大前提，那就是每個人都有判斷的能力，得“懂行”。西方的民主可以給自己選一個光明的未來，也可以讓英國脫歐。

2.3. 真的降低了系統(tǒng)復雜性嗎？

這個答案非常有可能是NO，微服務風格下，連數(shù)據(jù)庫都要給拆開，有些服務之間的技術(shù)差異非常大，要畫出系統(tǒng)圖的話，那真是能看到“百家爭鳴”，“百花齊放”的繁榮景象，最后連數(shù)據(jù)更新事務的一致性都保證不了，還得使用TCC，最終一致性之類的模式來替代。匯總報表要從各個服務數(shù)據(jù)庫中抽取數(shù)據(jù)去做統(tǒng)計，有時候連個最簡單的join都做不到了，“跨著數(shù)據(jù)庫呢大哥，想要數(shù)據(jù)？用接口來調(diào)！”

2.4. 真的節(jié)省系統(tǒng)資源了嗎？

單片系統(tǒng)通常部署在一個進程空間內(nèi)，或者是一個集群內(nèi)，代碼級別相對調(diào)用較多，這是比較節(jié)約資源的，雖然這種方式難以擴張，但是在其性能容量容許范圍之內(nèi)是最快的。微服務風格體系是靠著網(wǎng)絡通信來進行相互調(diào)用，從效率上來講，被單片系統(tǒng)甩了不止一條街，系統(tǒng)拆完了以后消耗網(wǎng)絡資源比以前大是肯定的事情。而且因為需要為每一個服務準備隔離運行環(huán)境（甚至要準備獨立的數(shù)據(jù)庫），因此和單片系統(tǒng)相比，CPU資源，內(nèi)存資源，磁盤資源的消耗也會更多。

2.5. 真的省了錢了嗎？

曾經(jīng)有一些文章提到過這樣的論點：“微服務降低開發(fā)成本?！?，但就我個人的實踐經(jīng)驗來講，并不是這樣，這里用吃飯這個事兒來說這個事兒，“以前做單片系統(tǒng)，就好像吃一頓飯，大家入座，端起碗筷，吃肉，吃菜，喝湯，放下碗筷，離席?！?/strong>，“如今做微服務，吃飯流程都變了，大家入座，端起碗筷，吃肉，放下碗筷，離席；大家再入座，吃菜，放下碗筷，離席；大家第三次入座，端起碗筷，喝湯，放下碗筷，離席?！?/strong>，很多項目初始化和收尾的工作都要重復的做，從工作的總量上來講，也是比之前多了，而絕對不是少了。