單體應用這種傳統開發思維已經難以在新時代站住腳了。

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

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

[[207901]]

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

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

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

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

[[207902]]

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

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