歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
精品學習資料獲取通道，參見文末
目錄
1、Eureka官宣2.x版本不再開源
2、網際網路大廠的基礎架構：自研服務註冊中心
3、中小公司的其他選擇：Consul
1、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有點不太靠譜了呢，我們還敢繼續用麼，沒錯，很多小夥伴就是這感覺。
2、網際網路大廠的基礎架構：自研服務註冊中心
這裡給大家說一句題外話，BAT、TMD等一線網際網路公司，包括一些有一定研發實力的中大型網際網路公司，都是自研了微服務技術架構中的服務註冊中心。或者是基於開源的Eureka之類的專案來做二次開發，自行優化裡面的架構，解決遇到的問題。
所以對於有基礎架構團隊的公司而言，這個問題相對來說還沒那麼嚴重。
因為大廠的基礎架構團隊，完全可以把常見的開源服務註冊中心的原始碼都深入看一遍，然後經過大量嚴謹的測試找到各個開源技術的優點和缺點。最後決定是從0開始自研一個服務註冊中心，還是說基於某個開源的技術來進行二次開發和優化。
比如說Eureka 1.x作為一個服務註冊中心，有一個非常典型的架構問題。
雖然他可以部署叢集架構，但是叢集中每個Eureka例項都是對等的。每個Eureka例項都包含了全部的服務登錄檔，每個Eureka例項接收到了服務註冊/下線等請求的時候，會同步轉發給叢集中其他的Eureka例項，實現叢集資料同步。
大家看下面的圖，大概就是一個示意。
那麼這裡就有一個問題了：如果是支援超大規模的服務叢集，這樣的模式能行麼？
每臺機器的記憶體是有限的，叢集裡的服務數量越來越多，可能有幾十萬個服務例項在執行，那麼服務登錄檔越來越大，最後超過單機記憶體支撐的極限怎麼辦？
這個時候如果自己研發服務註冊中心，就可以參考大資料領域的Hadoop的架構思想。
Hadoop的設計思想是把登錄檔分片儲存，分散式儲存在多臺機器上，每臺機器儲存部分登錄檔資料。
然後每個Server可以加上一個從節點做熱備份，避免單機掛掉導致註冊 表資料丟失。
我們來看看架構圖，如下所示：
實際在生產環境使用Eureka的時候，你還會碰到很多現實的問題。
比如說上面講了，Eureka本身是基於簡單的同步機制實現叢集架構的，但是這裡在叢集之間進行同步的時候，其實是非同步進行的，採用的是最終一致性的協議。
這就可能會導致說，你某個服務註冊到了一個Eureka Server例項上去，但是他需要非同步複製到其他的Eureka Server，這中間是需要時間的。
所以可能導致其他的Eureka Server是看不到那個剛新註冊的服務例項的。
大家看下面的圖，就示意了這個問題：
但是如果是採取了類似Hadoop的那種資料分片思想的話，一個登錄檔資料分片就在一臺機器上，由這臺機器負責提供服務的註冊和發現，那麼此時就可以實現強一致的效果。
也就是說，只要你註冊了，立馬就會被別人發現，如下圖。
這裡只是說其中幾個例子罷了，改造開源系統的思路是很多的，實際上大廠完全可以對開源技術做很多的自研、定製和改造，解決線上的生產問題，讓服務註冊中心朝著他們心裡期望的效果去發展，所以對他們來說其實問題並不大。
3、中小公司的其他選擇：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架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告，純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件？
47、如果20萬使用者同時訪問一個熱點快取，如何優化你的快取架構？
48、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？
50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備？
51、【offer收割機必備】我簡歷上的Java專案都好low，怎麼辦？
52、【offer去哪了】我一連面試了十個Java崗，統統石沉大海！
作者：石杉的架構筆記
連結：https://juejin.im/post/5c6a9f25518825787e69e70a
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。