尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

精品學習資料獲取通道，參見文末

目錄

一、Eureka官宣2.x版本再也不開源

二、互聯網大廠的基礎架構：自研服務註冊中心

三、中小公司的其餘選擇：Consul

一、Eureka官方宣佈2.x再也不開源

以前寫過一篇文章：拜託！面試請不要再問我Spring Cloud底層原理！，文章介紹了Spring Cloud微服務技術體系的一些基礎知識和架構原理。

若是對Spring Cloud微服務技術體系有必定了解了以後，確定就知道Spring Cloud最開始原生支持和推薦的服務註冊中心是國外的一個視頻網站Netflix開源的Eureka。

這個Eureka呢，又分紅了所謂的1.x版本和2.x版本，以前在國內比較經常使用在生產環境中的都是Eureka的1.x版本。

而後Netflix這個公司自己一直在作Eureka 2.x版本，結果作着作着，你們萬衆矚目很期待的時候。。。

2018年7月，人家官方就忽然宣佈Eureka 2.x中止開源計劃了，具體以下：

用中文給你們翻譯一下，這裏的意思就是說：Eureka 2.0的開源工做已經中止了，若是你要用Eureka 2.x版本的代碼來部署到生產環境的話，一切後果請自負。

大概就是這個意思，就是不打算把這個事兒作大作強下去了。

固然如今其實Eureka 1.x的版本也有很多公司在生產環境用，並且基本也還算能用的狀態，基本功能還算正常，應付不少常規的場景也足夠了。

可是現實就是這個聲明發出來，讓大夥都內心一涼，怎麼感受這個這個Eureka有點不太靠譜了呢，咱還敢繼續用麼，沒錯，不少小夥伴就是這感受。

二、互聯網大廠的基礎架構：自研服務註冊中心

這裏給你們說一句題外話，BAT、TMD等一線互聯網公司，包括一些有必定研發實力的中大型互聯網公司，都是自研了微服務技術架構中的服務註冊中心。或者是基於開源的Eureka之類的項目來作二次開發，自行優化裏面的架構，解決遇到的問題。

因此對於有基礎架構團隊的公司而言，這個問題相對來講還沒那麼嚴重。

由於大廠的基礎架構團隊，徹底能夠把常見的開源服務註冊中心的源碼都深刻看一遍，而後通過大量嚴謹的測試找到各個開源技術的優勢和缺點。最後決定是從0開始自研一個服務註冊中心，仍是說基於某個開源的技術來進行二次開發和優化。

好比說Eureka 1.x做爲一個服務註冊中心，有一個很是典型的架構問題。

雖然他能夠部署集羣架構，可是集羣中每一個Eureka實例都是對等的。每一個Eureka實例都包含了所有的服務註冊表，每一個Eureka實例接收到了服務註冊/下線等請求的時候，會同步轉發給集羣中其餘的Eureka實例，實現集羣數據同步。

你們看下面的圖，大概就是一個示意。

那麼這裏就有一個問題了：若是是支持超大規模的服務集羣，這樣的模式能行麼？

每臺機器的內存是有限的，集羣裏的服務數量愈來愈多，可能有幾十萬個服務實例在運行，那麼服務註冊表愈來愈大，最後超過單機內存支撐的極限怎麼辦？

這個時候若是本身研發服務註冊中心，就能夠參考大數據領域的Hadoop的架構思想。

Hadoop的設計思想是把註冊表分片存儲，分佈式存儲在多臺機器上，每臺機器存儲部分註冊表數據。

而後每一個Server能夠加上一個從節點作熱備份，避免單機掛掉致使註冊 表數據丟失。

咱們來看看架構圖，以下所示：

實際在生產環境使用Eureka的時候，你還會碰到不少現實的問題。

好比說上面講了，Eureka自己是基於簡單的同步機制實現集羣架構的，可是這裏在集羣之間進行同步的時候，實際上是異步進行的，採用的是最終一致性的協議。

這就可能會致使說，你某個服務註冊到了一個Eureka Server實例上去，可是他須要異步複製到其餘的Eureka Server，這中間是須要時間的。

因此可能致使其餘的Eureka Server是看不到那個剛新註冊的服務實例的。

你們看下面的圖，就示意了這個問題：

可是若是是採起了相似Hadoop的那種數據分片思想的話，一個註冊表數據分片就在一臺機器上，由這臺機器負責提供服務的註冊和發現，那麼此時就能夠實現強一致的效果。

也就是說，只要你註冊了，立馬就會被別人發現，以下圖。

這裏只是說其中幾個例子罷了，改造開源系統的思路是不少的，實際上大廠徹底能夠對開源技術作不少的自研、定製和改造，解決線上的生產問題，讓服務註冊中心朝着他們內心指望的效果去發展，因此對他們來講其實問題並不大。

三、中小公司的其餘選擇：Consul

只是對於不少中小型公司而言，可能自己沒有基礎架構團隊的支撐，或者是沒有過多的人力物力投入到自研中間件、開源系統二次開發中去。

那麼此時就能夠考慮選擇其餘的開源服務註冊中心的技術了，好比Spring Cloud一樣支持的Consul就是目前不少公司的選擇。

這兒我們簡單介紹一下Consul，後面能夠考慮再寫文章介紹介紹Consul的架構原理和使用什麼的，你們看一下，能夠做爲一個服務註冊中心技術選型的參考：

• 服務註冊與發現
• Consul固然是能夠做爲服務註冊中心的了，能夠用作微服務架構的服務註冊和發現。
• 同時這裏能夠先給你們說一下，Consul的服務註冊機制選擇的是基於Daft協議的強一致，沒有像Eureka那樣使用最終一致的效果。

• 健康檢查
• Consul能夠支持很是強大的健康檢查的功能，啥叫健康檢查？
• 簡單來講就是不停的發請求給你的服務檢查他到底死了沒有，目前是否還健康，這個就是叫作健康檢查。

• kv存儲
• Consul不光支持服務註冊和發現，竟然還能夠支持簡單的kv存儲。
• 他可讓你用key-value對的形式存放一些信息以及提取查詢，是否是很神奇？

• 安全的服務通訊
• Consul支持讓你的服務之間進行受權來限制哪些服務能夠通訊和鏈接

• 多數據中心支持

其實說實話，在作技術選型的時候，很是關鍵的一點，就是看社區是否活躍。

因此雖然上面說了不少，可是其實你們徹底能夠看一眼下面的Eureka Github和Consul Github的更新活躍度的對比。

咱們明顯會發現，Eureka 1.x版本最近的更新都在幾個月前甚至幾年前，可是Consul最近的更新不少都是幾天前的。

因此自己Spring Cloud官方技術棧也是支持Consul的，Eureka開源社區慢慢再也不活躍以後，天然不少中小公司開始選擇使用功能更增強大，並且社區更新也更加活躍的Consul做爲服務註冊中心了，這也是一個不錯的選擇。

End

（封面圖源網絡，侵權刪除）

掃描下方二維碼，備註：「資料」，獲取更多「祕製」 精品學習資料

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

3八、億級流量系統架構之如何保證百億流量下的數據一致性（中）？

3九、億級流量系統架構之如何保證百億流量下的數據一致性（下）？

40、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（1）

4一、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（2）

4二、面試大殺器：消息中間件如何實現消費吞吐量的百倍優化？

4三、高併發場景下，如何保證生產者投遞到消息中間件的消息不丟失？

4四、兄弟，用大白話給你講小白都能看懂的分佈式系統容錯架構

4五、從團隊自研的百萬併發中間件系統的內核設計看Java併發性能優化

4六、【非廣告，純乾貨】英語差的程序員如何才能無障礙閱讀官方文檔？

4七、若是20萬用戶同時訪問一個熱點緩存，如何優化你的緩存架構？

4八、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？

4九、拜託，面試請不要再問我分佈式搜索引擎的架構原理！

50、【金三銀四跳槽季】Java工程師如何在1個月內作好面試準備？

5一、【offer收割機必備】我簡歷上的Java項目都好low，怎麼辦？

5二、【offer去哪了】我一連面試了十個Java崗，通通石沉大海！

5三、高階Java開發必備：分佈式系統的惟一id生成算法你瞭解嗎？

5四、支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c6a9f25518825787e69e70a 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。