在開聊微服務之前，先要介紹下單體應用。如果你不知道單體應用的痛，那也不會深刻理解微服務的價值。
傳統的it架構的缺陷：認識單體應用的弊端，再談微服務
什麼是單體應用？
所謂的單體應用就是指一個war包包含了項目的所有功能。
① 單體應用的優點
不管是什麼樣的架構模式都會有其優點所在，單體應用的優點如下所示：
容易部署：這個不容置疑，整個項目就一個war包，部署特別方便。
容易運行/測試：這個也上面也類似,我們在測試階段只需要啓動一個war包即可。
但是相比優點缺點反而更加明顯，下面講述一下單體應用的缺點。
② 單體應用的缺點
複雜性高：隨着業務的不斷迭代，項目的代碼量會急劇的增多，項目模塊也會隨着而增加，模塊與模塊之間的關係就會變成的很複雜，整個項目就會變成的非常複雜，在新增和修改代碼的時候都會做很多的測試，很容易會由於一處的變動影響之前業務的功能。
部署評率低:隨便代碼的增多，首先部署會越來越消耗時間，還有我們在修復一個很小很小的bug的時候整個項目都要重新部署，所以我們會集中一個時間點部署多個需求。
可靠性差：這個很容易理解，假如某個影響出現了死循環，導致內存溢出，會影響整個項目掛掉。
擴展性差:我們在新增業務的時候，代碼層面會考慮在不影響現有的業務基礎上編寫代碼，提高了代碼的複雜性。
單體應用架構（左）和微服務架構（右）對比，一圖勝千言（圖片來自網絡，侵權聯繫必刪）：
早些年，各大互聯網公司的應用技術棧大致可分爲 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）兩大流派。無論是 LAMP 還是 MVC，都是爲單體應用架構設計的，其優缺點如上，以 MVC 架構爲例，業務通常是通過部署一個 WAR 包到 Tomcat 中，然後啓動 Tomcat，監聽某個端口即可對外提供服務。早期在業務規模不大、開發團隊人員規模較小的時候，採用單體應用架構，團隊的開發和運維成本都可控。但單體應用架構(Monolithic Architecture也叫一體化架構、整體式架構)開發的應用系統，如CRM、ERP等大型應用，隨着新需求的不斷增加、業務規模的不斷擴大，團隊開發人員的不斷擴張，企業更新和修復大型整體式應用（單體應用）變得越來越困難，單體應用架構就會開始出現問題。於是服務化的思想也就應運而生。
什麼是服務化？
這裏我就不談一些官方的、教條主義的概念了。用通俗的話來講，服務化就是把傳統的單機應用中通過 JAR 包依賴產生的本地方法調用，改造成通過 RPC 接口產生的遠程方法調用。一般在編寫業務代碼時，對於一些通用的業務邏輯，我會盡力把它抽象並獨立成爲專門的模塊，因爲這對於代碼複用和業務理解都大有裨益。
在過去的項目經歷裏，我對此深有體會。以微博系統爲例，微博既包含了內容模塊，也包含了消息模塊和用戶模塊等。其中消息模塊依賴內容模塊，消息模塊和內容模塊又都依賴用戶模塊。當這三個模塊的代碼耦合在一起，應用啓動時，需要同時去加載每個模塊的代碼並連接對應的資源。一旦任何模塊的代碼出現 bug，或者依賴的資源出現問題，整個單體應用都會受到影響。
爲此，首先可以把用戶模塊從單體應用中拆分出來，獨立成一個服務部署，以 RPC 接口的形式對外提供服務。微博和消息模塊調用用戶接口，就從進程內的調用變成遠程 RPC 調用。這樣，用戶模塊就可以獨立開發、測試、上線和運維，可以交由專門的團隊來做，與主模塊不耦合。進一步的可以再把消息模塊也拆分出來作爲獨立的模塊，交由專門的團隊來開發和維護。
可見通過服務化，可以解決單體應用膨脹、團隊開發耦合度高、協作效率低下的問題。
什麼是微服務？
從 2014 年開始，得益於以 Docker 爲代表的容器化技術的成熟以及 DevOps 文化的興起，服務化的思想進一步演化，演變爲今天我們所熟知的微服務。
微服務（ Microservice ）微服務並非什麼新的概念。實際上，很多 SOA 實施成熟度比較好的企業，已經在使用和實施微服務了。只不過，它們只是在悶聲發大財，並不介意是否有一個比較時髦的名詞來明確表述 SOA 的這個發展演化趨勢罷了。微服務其實就是服務化思路的一種最佳實踐方向，遵循 SOA 的思路，各個企業在服務化治理的道路上走的時間長了，踩的坑多了，整個軟件交付鏈路上各個環節的基礎設施逐漸成熟了，微服務自然而然就誕生了。當然，之所以叫微服務，是與之前的服務化思路和實踐相比較而來的。早些年的服務實現和實施思路是將很多功能從開發到交付都打包成一個很大的服務單元（一般稱爲 Monolith ) ，而微服務實現和實施思路則更強調功能趨向單一，服務單元小型化和微型化。如果用“茶壺煮餃子”來打比方的話，原來我們是在一個茶壺裏煮很多個餃子，現在（微服務化之後）則基本上是在一個茶壺裏煮一個餃子，而這些餃子就是服務的功能，茶壺則是將這些服務功能打包交付的服務單元。如圖：
所以，從思路和理念上來講，微服務就是要倡導大家盡呈將功能進行拆分，將服務粒度做小，使之可以獨立承擔對外服務的職責，沿着這個思路開發和交付的軟件服務實體就叫作“微服務”，而圍繞着這個思路和理念構建的一系列基礎設施和指導思想，筆者將它稱爲“微服務體系”。
那麼微服務相比於服務化又有什麼不同呢？
繼續以前面舉的微博系統爲例，可以進一步對內容模塊的功能進行拆分，比如內容模塊又包含了 feed 模塊、評論模塊和個人頁模塊。通過微服務化，將這三個模塊變成三個獨立的服務，每個服務依賴各自的資源，並獨立部署在不同的服務池中，可以由不同的開發人員進行維護。當評論服務需求變更時，只需要修改評論業務相關的代碼，並獨立上線發佈；而 feed 服務和個人頁服務不需要變更，也不會受到發佈可能帶來的變更影響。
由此可見，微服務化給服務的發佈和部署，以及服務的保障帶來了諸多好處。
總結來說，微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分，每個拆分出來的服務各自獨立打包部署，並交由小團隊進行開發和運維，從而極大地提高了應用交付的效率，並被各大互聯網公司所普遍採用。
微服務中的spring-cloud
Spring Cloud是一個相對比較新的微服務框架，2016n年推出1.0的release版本. 雖然Spring Cloud時間最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案。
Spring Cloud 爲開發者提供了在分佈式系統（配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全居瑣，leader選舉，分佈式session，集羣狀態）中快速構建的工具，使用Spring Cloud的開發者可以快速的啓動服務或構建應用、同時能夠快速和雲平臺資源進行對接。
以下是微服務架構主要的一個技術棧:
推薦幾篇不錯的文章：
文章2:https://blog.csdn.net/qinaye/article/details/82840625