什麼是微服務？
微服務沒有一個標準統一的概念，個人理解爲：微服務是一種可以讓軟件職責單一、鬆耦合、自包含、可以獨立運行和部署的架構思想。
關鍵思想就是：拆分、單一、獨立、組件化。把原本一個龐大、複雜的項目按業務邊界拆分一個一個獨立運行的小項目，通過接口的方式組裝成一個大的項目。
微服務解決了什麼問題？
微服務的出現及流行，一定有它的過人之處，既解決了非微服務項目的部分問題或缺點。
相對於微服務，普通的項目都會包含很多功能的，是一個大而全的“超級”工程。比如：以普通架構方式實現的電商平臺會是一個包含：登錄、權限、會員、商品庫存、訂單、收藏、關注、購物車等功能的單一項目。隨着項目業務越來越複雜、開發人員越來越多相應開發、編譯、部署、技術擴展、水平擴展都會受到限制。
開發
太多功能在一個項目中，可能會讓代碼複雜、結構混亂、業務關聯混亂、技術單一。過多的功能，讓整個項目結構複雜，業務相互交織，可能導致開發人員對業務的理解和代碼實現相互交織，最後沒人能完全理解整個項目。而且也很難控制每個開發人員能“合法合規”的編碼，可能會把兩個本來鬆耦合、互不影響的功能因爲實現“簡單”就偷懶強關聯在一起。
技術單一
單一的項目爲了技術的統一和管理的簡單方便，一般都會採用統一的技術實現。但是超大型業務如電商平臺，不可能只採用一種技術（如：java），可能會結合業務及不同技術優缺點和技術團隊優執採用不同的技術。如果把項目拆分成不同的小項目，每個小項目可以根據自己的特點採用不同技術，只需要提供統一的接口實現對接即可，最大化技術的優勢。
編譯
過於龐大的代碼也會導致整個項目編譯時間過長，一次簡單的修改或一個簡單的單元測試需要漫長的編譯和啓動。
版本控制
過多的開發人員在同一個項目中共同開發不同業務模塊，也會大大增加版本衝突。
部署
一個簡單的修改需要部署整個項目。當多個功能同時上線，但僅僅因爲一個小功能失敗，就會導致其它所有功能一起回滾。
擴展
互聯網的飛速發展，用戶和請求量急劇增加，傳統的項目很難擴展（水平、垂直），即集羣和分佈式擴展的問題。
微服務如何解決上面問題？
以上就是單個（單體）大項目的問題，微服務就是要解決上面的問題。
核心思路很簡單，就是拆分，即然是單體項目的問題，那麼直接把項目拆分成一個個小項目是不是就可以完美解決。
微服務有哪些缺點？
然而，這並不是銀彈，也不是最完美的解決方案。微服務有自己的優點，也帶來了相應的劣勢。具體如下：
如何拆分：微服務的核心就是拆分項目，把整個項目模塊化、組件化；職責更單一，精中力量做好一件事。但是如何拆分纔是合理的？通常的作法是，按業務拆分，功能從業務上分類，非常耦合的分在同一個微服務中；反之，耦合性非常低的則放到不同的微服務。
事務：原本在同一個項目中的兩個操作，如果拆分到不同的項目中，那麼就可能會遇到分佈式事務的問題。這是一個棘手但沒有完美解決方案的問題。基本原則是，需要在同一事務中實現的兩個操作屬於強耦合業務，最好拆分到同一個微服務。如果確實是兩個微服務（如：減庫存、扣款）則通過其它方式（如：消息隊列、分佈式事務鎖、重試機制、對賬）來解決
spring cloud
微服務是一個架構思想，並不是一種實現，它指明瞭解決單體應該缺點的方向，但並沒有給定相應的實現和解決方案以及細節。
spring cloud是spring提供的，基於spring boot以及結合Netflix 相關思想和代碼對微服務理念的java實現。spring cloud本質上是分佈式解決方案，但微服務最終也落實到分佈式，因此也是對微服務的實現方案。
Spring Cloud 爲開發人員提供了一些可以用於快速構建分佈式系統通用模式的工具（例如：配置管理、服務註冊與發現、斷路器、智能路由、微代理、控制總線）。分佈式系統的協調趨於一些模版模式， 並且，使用Spring Cloud使開發人員可以快速創建實現了這些模式的服務和應用。 他們可以在任何的分佈式環境中良好運行，這些環境包括開發人員自己的筆記本、裸機上的數據中心、像Cloud Foundry這樣的託管平臺（雲平臺）。
spring cloud主要提供了分佈系統中以下幾個開箱即用的功能：
分佈式/版本化/集中化配置 - spring cloud config 服務註冊發現 - Netflix Eureka 路由 - Netflix Zuul 服務之間的點對點調用（Service-to-service calls）負載均衡-Netflix Ribbon 斷路器 - Netflix Hystrix 分佈式消息
五大核心組件：
服務註冊發現 - Netflix Eureka
配置中心 - spring cloud config
負載均衡-Netflix Ribbon
斷路器 - Netflix Hystrix
路由(網關) - Netflix Zuul