單一職責

微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務
通過“管道”的方式靈活組合，從而構建出龐大的系統。

輕量級通訊

服務之間通過輕量級的通訊機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的互動方式。
對於輕量級通訊的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關、平臺無關的；對於通訊的協議而言，通
常基於 HTTP，能讓服務間的通訊變得標準化、無狀態化。目前大家熟悉的 REST（Representational State
Transfer）是實現服務間互相協作的輕量級通訊機制之一。使用輕量級通訊機制，可以讓團隊選擇更適合的語言、
工具或者平臺來開發服務本身。
問：REST是什麼和restful一樣嗎？
答：REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。

獨立性

每個服務在應用交付過程中，獨立地開發、測試和部署。
在單塊架構中所有功能都在同一個程式碼庫，功能的開發不具有獨立性；當不同小組完成多個功能後，需要經過整合和迴歸測試，測試過程也不具有獨立性；當測試完成後，應用被構建成一個包，如果某個功能存在 bug，將導致整個部署失敗或者回滾。

程序隔離

單塊架構中，整個系統執行在同一個程序中，當應用進行部署時，必須停掉當前正在執行的應用，部署完成後再重啟程序，無法做到獨立部署。
有時候我們會將重複的程式碼抽取出來封裝成元件，在單塊架構中，元件通常的形態叫做共享庫（如 jar 包或者DLL），但是當程式執行時，所有元件最終也會被載入到同一程序中執行。

微服務架構的缺點

運維要求較高
對於單體架構來講，我們只需要維護好這一個專案就可以了，但是對於微服務架構來講，由於專案是由多個微服務構成的，每個模組出現問題都會造成整個專案執行出現異常，想要知道是哪個模組造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
分散式的複雜性
對於單體架構來講，我們可以不使用分散式，但是對於微服務架構來說，分散式幾乎是必會用的技術，由於分散式本身的複雜性，導致微服務架構也變得複雜起來。
介面調整成本高比如，使用者微服務是要被訂單微服務和電影微服務所呼叫的，一旦使用者微服務的介面發生大的變動，那麼所有依賴它的微服務都要做相應的調整，由於微服務可能非常多，那麼調整介面所造成的成本將會明顯提高。重複勞動對於單體架構來講，如果某段業務被多個模組所共同使用，我們便可以抽象成一個工具類，被所有模組直接呼叫，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接呼叫的，從而我們便不得不在每個微服務上都建這麼一個工具類，從而導致程式碼的重複。