這段時間嘗試搞了一下spring cloud，之前其實也搞過，不過時間太長，加上當時的demo早就被我刪掉了，已經沒有什麼印象了，這次重新搞一下spring cloud，其實感受挺深的，爲什麼要用spring cloud的呢？簡單來說就是解決三高問題，高併發，高可用，高性能的問題，聽着確實高大上，但是其實代價也是極爲高昂的，實際上spring cloud只解決了高可用的問題，高併發和高性能其實和它沒什麼關係，所以我們先談高可用
什麼是高可用呢？
說白了，高可用就是保證系統在任何時刻都可以使用，如果不能使用，也要儘量維持最低限度的運行，不能出現所謂宕機
那爲什麼傳統項目從來不談高可用呢？
兩方面原因，對於傳統項目，高可用基本就是對服務器燒香拜佛看，服務器比較爭氣，上線幾年一直沒掛，那就是高可用了，如果服務器不怎麼爭氣，老是藍屏，死機，如果不是項目本身的問題，那麼就只能換機器，或者請人來修了，所以傳統項目的高可用一般是一個玄學問題，完全看服務器心情，不過對於一些企業內部系統來說，其實影響也不大，最壞的情況，服務器徹底宕機，只能更換，最多手機羣發一條短信，告知全體員工，良心一點就放假一天，資本一點就人肉代替電腦，勉強維持運行，反正等新機器來再上線就行了，而且一般情況下也很少出現徹底涼涼的情況，最多重啓一波，對於傳統項目來說，5分鐘項目宕機而已，能有多大損失？
另外一方面，高可用的同時也代表高費用，在沒有明顯影響或影響有限的情況下，我是老闆，我也選擇低可用，額外的機器花費，額外的維護人員花費，還有系統本身設計的難度提升所帶來的更高技術需求，總結起來就一句話，爲了解決高可用，花費的錢太多了，不值得，即使對高可用要求較高的系統，解決方案也不需要對高可用本身進行處理，多買幾臺電腦，把項目多跑幾次，第一個項目掛了，就訪問第二個網址，用概率學打敗高可用，對不起，窮人的解決方式就是這麼樸實無華而且省錢
那爲什麼現在所有公司都開始談高可用了呢？
因爲現在是互聯網時代了，公司的項目不僅僅只是面向公司那一小撮人，而是全世界的用戶，你指望他們會去記住那麼多網址嗎？第一個進不去就直接溜了，加上人數規模之大，宕機的損失也是幾何數的往上翻，所以，爲了小錢錢，大家也開始追求高可用這個東西了
說了這麼多，那麼spring cloud是怎麼實現高可用呢？
那spring cloud本質上是個什麼東西呢？說白了就是一個傻子數數的遊戲，傻子（註冊中心），每隔一段時間，數一數自己的蘋果（服務），還在不在，使用的手段就是所謂的心跳檢測，心跳檢測是檢測人（服務）死沒死，而對於傻子來說，就是蘋果（服務）壞沒壞，壞了，就把這個壞蘋果扔掉（去除服務），保證自己手上的蘋果是好的，此時肚子餓了（請求來了），就趁蘋果不注意，偷偷咬一口（調用服務），這時候如果有人幫傻子把壞蘋果爛掉的地方挖掉，傻子就覺得這蘋果好了，就把蘋果搶回去（重新註冊）
那如果傻子實在太餓了（請求間隔時間較短），很多時候來不及去看蘋果（服務），壞沒壞，怎麼辦呢，喫到壞的吐出來就行了（斷路器），那傻子有一天突然好了（註冊中心宕機了），不傻了，溜走了怎麼辦呢？多找幾個傻子不就行了，大家推舉出一個傻子王，傻子王跑了，剩下的傻子就再推舉一個傻子王不就行了