微服務架構是一種將單個應用程序作為一套小型服務開發的方法，每種應用程序都在自己的進程中運行，采用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信的架構思路。
獨立性
在開發層面，每個微服務基本上都是各自獨立的項目（project），而對應各自獨立項目的研發團隊基本上也是獨立對應，這樣的結構保證了微服務的並行研發，並且各自快速迭代，不會因為所有研發都投入一個近乎單點的項目，從而造成開發階段的瓶頸。開發階段的獨立，保證了微服務的研發可以高效進行。
可擴展性
我們可以快速地添加服務集群的實例，提升整個微服務集群的服務能力，而在傳統 Monolith 模式下，為了能夠提升服務能力，很多時候必須強化和擴展單一結點的服務能力來達成。如果單結點服務能力已經擴展到了極限，再尋求擴展的話，就得從軟件到硬件整體進行重構。
隔離性
隔離性實際上是可擴展性的基礎，當我們將每個微服務都隔離為獨立的運行單元之后，任何一個或者多個微服務的失敗都將只影響自己或者少量其他微服務，而不會大面積地波及整個服務運行體系。
在架構設計上有一種實踐模式，即隔板模式（Bulkhead Pattern），這種架構設計模式的首要目的就是為了隔離系統中的各個功能單元和實體，使得系統不會因為一個單元或者服務的失敗而導致整體失敗。
服務獨立維護，分工明確
每個微服務都可以交由一個小團隊進行開發，測試維護部署，並對整個生命周期負責，當我們將每個微服務都隔離為獨立的運行單元之后，任何一個或者多個微服務的失敗都將只影響自己或者少量其他微服務，而不會大面積地波及整個服務。
當然，沒有完美無瑕的技術，微服務也有自身的不足：
微服務應用是分布式系統，由此會帶來固有的復雜性。開發者需要在RPC或者消息傳遞之間選擇並完成進程間通訊機制。他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這並不是什么難事，但相對於單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。