一、首先談談傳統系統架構和微服務架構
傳統的系統架構是單一架構模式。這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用采用的語言，如果采用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用服務器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包。
微服務架構則是將單個的整體應用程序分割成更小的項目關聯的獨立的服務。一個服務通常實現一組獨立的特性或功能，包含自己的業務邏輯和適配器。各個微服務之間的關聯通過暴露api來實現。這些獨立的微服務不需要部署在同一個虛擬機，同一個系統和同一個應用服務器中。
二、為什么需要微服務架構？
單一架構模式在項目初期很小的時候開發方便，測試方便，部署方便，運行良好。可是當應用隨着時間的推進，加入的功能越來越多，最終會變得巨大，一個項目中很有可能數百萬行的代碼，互相之間繁瑣的jar包。
1、 不再適用敏捷開發，過於復雜，任何開發者都不能夠完全理解，修復漏洞和實現新功能變得困難和耗時。
2、 規模越大，啟動時間越長，自然會拖慢開發進度，一個小功能的修改部署起來變得困難，必須重新部署整個應用。
3、 系統的不同的模塊的需要不同的特定的虛擬機環境時，由於是整體應用，那么只能折中選擇。
4、 任意模塊的漏洞或者錯誤都會影響這個應用，降低系統的可靠性
5、 還有一個如果想整體應用采用新的技術，新的框架或者語言，那是不可能的。
如果采用微服務架構模式，則可以解決單一架構模式帶來的系統復雜性。主要包括以下幾個好處：
1、 由於每個服務都是獨立並且微小的，由單獨的團隊負責，仍然可以采用敏捷開發模式，自由的選擇合適的技術，甚至可以重寫老服務，當然都要遵守統一的API約定。
2、 每一個微服務都是獨立部署的，可以進行快速迭代部署，根據各自服務需求選擇合適的虛擬機和使用最匹配的服務資源要求的硬件。
3、 整體應用程序被分解成可管理的模塊和服務，單個的服務可以更快的開發、更簡單的理解和維護。
4、 一些需要進行負載均衡的服務可以部署在多個雲虛擬機上，加入NGINX這樣的負載均衡器在多個實例之間分發請求，這樣不需要整個應用進行負載均衡了。
每個后端服務暴露一套REST API，大部分服務調用其他服務提供的API。每個服務都有自己的數據庫模式，而不是共享單個數據庫模式。盡管這會造成某些數據的冗余，但是對於微服務架構這個獨立數據庫模式是必要的，確保了獨立服務之間的松散耦合。
以上介紹的微服務架構模式表面上類似於SOA，兩種架構都包含一組服務。可以認為微服務架構是不包括Web服務規范（WS-）、企業服務總線（ESB）的SOA。基於微服務的應用傾向於使用更簡單輕量級的協議，比如 REST 而不是 WS-。微服務自己實現類似 ESB 的功能並且拒絕 SOA 的其他部分，比如規范模式的概念。
三、不可否認的微服務缺點
1、 微服務應用作為分布式系統帶來了復雜性。當應用是整體應用程序時，模塊之間調用都在應用之內，即使進行分布式部署，依然在應用內調用。可是微服務是多個獨立的服務，當進行模塊調用的時候，分布式將會麻煩。
2、 多個獨立數據庫，事務的實現更具挑戰性。
3、 測試微服務變得復雜，當一個服務依賴另外一個服務時，測試時候需要另外一個服務的支持。
4、 部署基於微服務的應用也很復雜，整體應用程序部署只需要部署在一組相同的服務器上，在這些服務前面加入傳統的負載均衡器即可。獨立服務的不是講變得復雜，需要更高的自動化形式。
總結：以上就是微服務的基礎介紹，那么如何實現微服務架構，Spring Cloud將起到什么作用，敬請期待。
最后推薦學習微服務的相關基礎知識:
PS:剛開始寫博客，不定期更新，記錄學習Spring Cloud的學習過程