寫好的代碼越來越滿足不了需求，因為需求總是在不斷的變化。在技術選型時，實在是心有餘而力不足。思來想去，就考慮了使用微服務架構來實現，功能模塊化。今天主要講講為什麼需要微服務架構。還是以故事的形式呈現。
一、認識微服務
階段一：單體服務
話說小張閒著沒事，就想著掙點錢，於是開了一家餐館。店鋪剛剛開張，顧客還不多。這時候就小張一個人，所以收銀、做飯、洗碗、打掃衛生的任務全在小張一個人身上。
階段二：微服務
小張做的飯真的是越來越好吃了，客人也越來越多，這可把小張累壞了，於是考慮著顧上幾個人，跟他一塊幹，每個人負責一個模塊。這就是微服務。分佈式是什麼呢？分佈式和微服務的區別在於：
分佈式是從部署的層面考慮的，微服務是從設計的角度來分析，
階段三：分佈式+微服務+集群
隨著手藝的不斷進步，人數那是超級多了，小李、小王和小紅都忙不過來了，於是呢一個活分給幾個人幹，這樣不就輕鬆了嘛。
是不是好了很多了，隨著小張事業的不斷上升，於是把功能不斷地細分，一個部分的人數也不斷的飆升來滿足客戶的需求。這就是微服務的整體進化。
總結：
單體結構：一個人把事全做了
分佈式+微服務：幾個人合夥做事
集群：每個人負責不同的事
當然分佈式和微服務的先後順序可能和你理解的不一樣，不過大體的流程是這樣的。我們舉了這個例子是想讓你從宏觀上認識一下微服務的功能。現在注意了，我們把目光轉移，轉移到微服務上來。
二、為什麼選用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比較好。
這篇文章是我的微服務系列的第一篇文章，算是熱身文章吧。
閱讀更多 Java的架構師技術棧 的文章
