單體應(yīng)用這種傳統(tǒng)開發(fā)思維已經(jīng)難以在新時代站住腳了。

一個簡單的應(yīng)用會隨著時間推移逐漸變大。在每次的sprint中，開發(fā)團隊都會面對新“故事”，然后開發(fā)許多新代碼。幾年后，這個小而簡單的應(yīng)用會變成了一個巨大的怪物。

一旦你的應(yīng)用變成一個又大又復(fù)雜的怪物，那開發(fā)團隊肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個應(yīng)用太復(fù)雜，以至于任何單個開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時。另外，團隊士氣也會走下坡路。

最后，單體式應(yīng)用使得采用新架構(gòu)和語言非常困難。比如，設(shè)想你有兩百萬行采用XYZ框架寫的代碼。如果想改成ABC框架，無論是時間還是成本都是非常昂貴的，即使ABC框架更好。因此，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。

相對于單體(Monolithic)應(yīng)用而言，微服務(wù)是采用一組服務(wù)的方式來構(gòu)建一個應(yīng)用，服務(wù)獨立部署在不同的進程中，不同服務(wù)通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務(wù)可獨立擴展伸縮，每個服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。

比喻來講，單點服務(wù)是把所有的東西放在一個大盒子里，這個大盒子里什么都有。微服務(wù)更像是車箱，每個箱子里包含特定的功能模塊和物品，所有東西可以很靈活地拆分出來。換言之，在單點服務(wù)中，所有的部件都在一個巨大的軟件包中。在微服務(wù)架構(gòu)下，有很多獨立存在的小服務(wù)，通過 API 接口連接成龐大的系統(tǒng)。

表面上看來，微服務(wù)架構(gòu)模式有點像SOA，他們都由多個服務(wù)構(gòu)成。但是，可以從另外一個角度看此問題，微服務(wù)架構(gòu)模式是一個不包含Web服務(wù)(WS-)和ESB服務(wù)的SOA。微服務(wù)應(yīng)用樂于采用簡單輕量級協(xié)議，比如REST，而不是WS-，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能。微服務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。

微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個團隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單，當(dāng)需要對技術(shù)棧進行升級時所面臨的風(fēng)險較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。當(dāng)某一組建發(fā)生故障時，在單一進程的傳統(tǒng)架構(gòu)下，故障很有可能在進程內(nèi)擴散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機制實現(xiàn)應(yīng)用層面的容錯。

使用微服務(wù)構(gòu)建適合云的新型應(yīng)用是很有意義的，因為它讓你既利用了橫向擴展架構(gòu)，也利用了縱向擴展架構(gòu)，還額外得到API的組合，且在整個業(yè)務(wù)中可重復(fù)利用。可能在每一分鐘都在交付新服務(wù)，這樣你就會擁有一個敏捷的且即時響應(yīng)的應(yīng)用程序平臺，當(dāng)然這一平臺一直在不斷改進中，微服務(wù)架構(gòu)也在前進著。