寫好的代碼越來越滿足不了需求，因為需求總是在不斷的變化。在技術選型時，實在是心有餘而力不足。思來想去，就考慮了使用微服務架構來實作，功能子產品化。今天主要講講為什麼需要微服務架構。還是以故事的形式呈現。
一、認識微服務
階段一：單體服務
話說小張閑着沒事，就想着掙點錢，于是開了一家餐館。店鋪剛剛開張，顧客還不多。這時候就小張一個人，是以收銀、做飯、洗碗、打掃衛生的任務全在小張一個人身上。
階段二：微服務
小張做的飯真的是越來越好吃了，客人也越來越多，這可把小張累壞了，于是考慮着顧上幾個人，跟他一塊幹，每個人負責一個子產品。這就是微服務。分布式是什麼呢？分布式和微服務的差別在于：
分布式是從部署的層面考慮的，微服務是從設計的角度來分析，
階段三：分布式+微服務+叢集
随着手藝的不斷進步，人數那是超級多了，小李、小王和小紅都忙不過來了，于是呢一個活分給幾個人幹，這樣不就輕松了嘛。
是不是好了很多了，随着小張事業的不斷上升，于是把功能不斷地細分，一個部分的人數也不斷的飙升來滿足客戶的需求。這就是微服務的整體進化。
總結：
單體結構：一個人把事全做了
分布式+微服務：幾個人合夥做事
叢集：每個人負責不同的事
當然分布式和微服務的先後順序可能和你了解的不一樣，不過大體的流程是這樣的。我們舉了這個例子是想讓你從宏觀上認識一下微服務的功能。現在注意了，我們把目光轉移，轉移到微服務上來。
二、為什麼選用Springcloud
我們先理清楚pringcloud和springMVC，springBoot，spring的關系：
spring的主要作用就是IOC和AOP的實作，springmvc是一個底層基于servlet的mvc架構。前兩個開發起來配置啥了一大堆，是以有了springboot，大大地簡化了我們的開發工作，但是系統的不斷複雜化，又想結合springboot的優點，是以出現了springcoud。既然springcloud能解決複雜系統出現的一些問題。那我們看看是如何解決的。
這張圖從上往下看，你會發現，一個複雜系統出現的各個方面都有着相應的子產品元件來實作。具體的使用細節在今後會退出我自己的微服務體系。結合我自己正在做的項目來實作。
微服務的架構那麼多比如：dubbo、istio，為什麼就要使用Spring Cloud的呢？
(1)spring家族的，他的威力就不強調了。學java的一定都會學習spring家族的架構。
(2)基于Spring Boot 可以減少我們的開發工作量。
(3)功能太齊全了。
(4)資料多，遇到問題很容易找到解決方案
而dubbo雖然使用者量很大，但是由于停止維護了一段時間，給了springcloud的可乘之機。内部還有很多問題需要處理，從時間經濟等等各個條件篩選，覺得還是springcloud比較好。
這篇文章是我的微服務系列的第一篇文章，算是熱身文章吧。