一：什么是微服務？
微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。 系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。 每個微服務僅關注於完成一件任務並很好地完成該任務。 在所有情況下，每個任務代表着一個小的業務能力。
當然啦，關於微服務還有很多種定義，並沒有一個官方的標准，通常在解釋微服務的時候，通常會提起一種面向服務的架構——SOA，其核心的原則就是將應用組織成一獨立的功能單元，可遠程訪問並單獨進行操作和更新，簡單來說，就是每個單元都是一個獨立的服務，它可以實現業務的一個方面，並通過接口提供功能，雖然SOA清楚地指出服務應當是獨立的進程，但是並未強制使用哪種協議進行交互，對於部署和配置還是相當模糊的，SOA服務可以在同一個機器上使用socket通過IPC（進程間通信）方式進行交互，若要使用內存共享，間接消息隊列或遠程過程調用（RPC），這是一個非常廣泛的定義，只要沒用在單個進程中運行所有應用，SOA可以是任何東西。
二：傳統的單體架構
舉例來說：一個商城，除了要有靜態的HTML內容外，還必須要有相關的模塊，比如用戶模塊，訂單模塊，商品模塊，優惠券模塊等等，當用戶對應用進行操作的時候，會伴隨着針對數據庫的一些SQL操作，然后再經過渲染返回給HTML的頁面，整過過程都相當於在一個應用的整體內進行，較少的對外部服務進行網絡請求（比如注冊時需要請求第三方短信驗證），在經典的LAMP架構中，每個傳入的請求都會在數據庫生成關聯的SQL查詢，然后服務器再使用模板引擎生成相應的HTML進行響應。
這種架構有很明顯的優缺點，優點就是：1.我們可以很容易的開始一個項目；2.簡化了數據的設計和組織；3.部署應用也會相對簡單
但他也有很明顯的缺點：1.我們如果想增加一些功能的時候，修改代碼可能會影響到原來不相關的功能，對某部分代碼的錯誤修改可能導致整個應用的崩潰
2.擴展應用的解決方案存在的限制：可部署多個實例，但若期中一個特定的功能占用了所有資源，則會影響整個應用
3.隨着應用的迭代，代碼庫的增長，很難保證代碼的干凈和可控性。
三.微服務架構
如下圖所示：
如上圖所示，這些微服務，諸如電子郵件的外部服務，將提供和單體應用相同的功能集，這個架構中的每個 組件都使用HTTP協議進行通信，拖過REST風格的web接口提供服務，每個微服務都在內部處理自己的數據結構，不需要中心化數據庫，使用普遍的數據格式如JSON輸入輸出數據，任何語言都可生成和使用，最后通過HTTP請求和響應進行傳輸。總體來說，微服務是一個輕量級的應用，它可以通過良好的契約提供一組有限的功能，它是具有單一責任的組件，可獨立開發和部署。
微服務架構的優點：
1.分離開發團隊的注重點，每個微服務都可由一個團隊獨立開發，每一次版本迭代只會在服務的內部進行，不會影響其他的應用，低耦合的開發模式，加快項目的進程。
2.如果在現成的微服務應用中進行跨越式的迭代，比如說更換語言和框架，我們可以把它隔離在一個微服務中，使用獨立的數據庫，讓一小部分用戶去試驗這個方案，從而不影響整個應用的運行
3.更加靈活的擴展與部署，根據微服務的定義，我們可以將服務部署在不同性能的服務器上面，需要消耗CPU的放在性能優良的服務器上面，只消耗內存的（如Redis這種內存數據庫）我們可以部署在CPU稍微較差，而內存較大的服務器上，從而減少了部署的成本
有好肯定有壞：
1.微服務若出現不合理的拆分，當你重構一些業務邏輯時，你的代碼就會讓你搔首踟躕了，嘻嘻，如果你要實現一些功能，總是要部署兩個微服務，或者你改變了一個微服務總會影響另一個數據模型時，你就該考慮合並兩個微服務了
2.在微服務的構建過程中，使用了很多的網絡交互，這也帶來了問題，如有由於網絡隔離或服務延遲，“商城HTML”無法及時調用相關的服務，這會產生嚴重的后果
3.假如用戶添加的系統中來，進行某些數據操作時，是不是需要同步每一個服務，這樣做會不會產生冗余呢，保持微服務的隔離的同時又要盡量避免數據的重復
4.兼容性的問題，可能會出現版本的不一致
5.測試上的問題，眾所周知，產品要部署上線時肯定要經過相應的測試，但是微服務架構是一個分離的架構，不同於單體架構，他需要相應的工具才能進行測試，這也是限制微服務開發的一個難題。