當我們使用乙個新技術的時候，應該首先問的乙個問題就是why：為什麼要使用這個技術？或者問：這個技術是可以解決什麼問題。
我也想寫篇微服務的文章，以及微服務的優缺點
在微服務架構中，當乙個大型系統被拆分成微服務系統以後，不僅包括功能拆分，還包括系統拆分、**拆分、資料庫拆分、快取拆分等，多個系統的部署、維護、呼叫關係、排程、監控、fail over就會成為一系列問題。同時微服務系統劃分越多，呼叫鏈路可能會越長，呼叫鏈監控、全鏈路trace也會成為問題。
自然和自然的法則在黑夜中隱藏，上帝說讓牛頓誕生吧，於是一切都被照亮。spring cloud 就是這樣誕生的。spring cloud為服務治理而生。
舉個栗子，當乙個大型系統被拆分成5個小業務系統以後，最容易想到的後端架構是：
前端需要維持多個系統
各個子系統之間不具有強關聯關係
api gateway和各個業務系統之間通過負載均衡發生呼叫關係，client只需要呼叫api gateway。
看起來好像解決了拆分問題、呼叫問題和client端問題。但是因為負載均衡裝置的存在，各個子系統之間不再有強關聯關係，子系統看起來像是互不關聯的系統一樣，各提供各的服務，當某乙個子系統響應變慢時，可能會造成api gateway或者其他呼叫者系統也變慢，甚至會造成整個架構雪崩。自然，這種問題可以設定呼叫超時來一定程度上解決，但是spring cloud可以提供更優雅的方案。這種結構，要想解決排程、監控、fail over、全鏈路trace等問題，也需要接入其他第三方系統或工具，而spring cloud針對這些問題提供了一套完整的解決方案。
先來看一下spring cloud包含了什麼元件：
這6張圖來自
包括了spring cloud現在有的所有元件，以及每個元件的作用。我這裡粗淺介紹10個。
spring cloud config
spring cloud bus
eureka
consul
ribbon:
feign
hystrix
zuul
turbine
spring cloud starters
提問和看不懂
在之前和同學的問答中，我更加傾向於給同學乙個keyword，乙個鏈結，乙個方向，引導學生自己去解決問題 恩，是因為我懶 在這一過程中，有2個非常重要的問題需要強調 不知道大家是否還想回憶起自己小的時候，要多小呢？要非常小。當我們還在大約半歲的時候，餓了或者是睡覺的姿勢不那麼舒服，都會用哭這樣的形式表...
我有點看不懂了
這是在社群裡面看到的一位老師的簡歷 英文名 出版圖書 xx 特約講師 it168特邀職業發展顧問 審閱簡歷超過100萬次，面試技術候選人超過1萬，嗯，應該說，這位老師的簡歷還是蠻光彩的。不過，我是程式設計師，萬事用數字說話。感覺有點吹牛。這個審閱簡歷100萬次。我說看乙個人的簡歷，怎麼說，乙份簡歷看...
我有點看不懂了
這是在社群裡面看到的一位老師的簡歷 英文名 出版圖書 xx 特約講師 it168特邀職業發展顧問 審閱簡歷超過100萬次，面試技術候選人超過1萬，嗯，應該說，這位老師的簡歷還是蠻光彩的。不過，我是程式設計師，萬事用數字說話。感覺有點吹牛。這個審閱簡歷100萬次。我說看乙個人的簡歷，怎麼說，乙份簡歷看...