微服務怎麼搭本地配置中心-九游会j9娱乐平台
a. 使用 idea 從 0 開始搭建 spring cloud 微服務
以下內容均來源於一個微服務初學者的實踐，僅供參考。
首先啟動 spring cloud eureka 注冊中心，其他部分都作為服務注冊到 eureka ，並通過注冊的服務名互相訪問。spring cloud config 提供統一的配置信息，供其他服務讀取。provider 生產者服務不直接對外暴露，僅供 consumer 消費者服務調用。用戶通過 spring cloud gateway 統一訪問消費者服務。
首先創建一個空 maven 項目，然後右鍵項目 -> new mole ，選擇繼續創建空 maven 模塊或者使用 spring initializr 構建 spring cloud 模塊。common模塊用於存放公共的 lib ，如 、model 、util 等。config-dev 存放配置文件，上傳到 git 之後供 spring cloud config 讀取。
除了少數像 spring cloud config 、spring cloud gateway 這種獨立應用，大部分非空模塊都需要添加 spring-boot-starter-web 構建 web 應用。下圖是使用 idea 的 spring initializr 快速構建新模塊。
下面貼上詳細的配置文件和註解，bootstrap.yml 具有高優先順序，會提前載入並且不會被 application.yml 覆蓋，spring.cloud.config 需要配置在 bootstrap.yml 中，否則不能正常從配置中心獲取配置信息。
application.yml
hobbyeurekaapplication.java
application.yml
application-dev.yml
hobbyconfigapplication.java
bootstrap.yml
config-dev/gateway.yml
hobbygatewayapplication.java
在 spring cloud gateway 的配置中已經展示過如何從 config-dev 配置倉庫中讀取配置文件。spring.cloud.config 和 eureka.client 都已經在 bootstrap.yml 中配置過，接下來不做贅述。多模塊項目中掃描其他模塊的 mybatis 文件需要做額外的配置。
application.yml
hobbyprovidertestapplication.java
消費者調用生產者可以使用 feign 聲明式服務調用。
hobbyconsumertestapplication.java
testfeignservice.java
testserviceimpl.java
spring cloud eureka >> spring cloud config >> spring cloud gateway >> 其他服務
微服務架構能夠將各種服務解耦，單獨部署，配合 devops 才能展現出真正的威力，否則運維的工作會苦不堪言。gitlab 目前已經集成了 devops 功能，只要在項目中添加 .gitlab-ci.yml ，push 到 gitlab 之後就會自動執行配置的命令，這里簡單介紹一下 gitlab 的安裝部署。
centos7 自帶的 git 版本號是 1.8.3.1 ，需要更新，否則 gitlab runner 在進行自動構建的時候會報錯 fatal: git fetch-pack: expected shallow list ，更新步驟如下：
gitlab 安裝官方文檔
gitlab runner 安裝官方文檔
配置文件的地址 /etc/gitlab/gitlab.rb
修改配置文件的操作：
常用配置：
b. 微服務架構：基於微服務和docker容器技術的paas雲平台架構設計
基於微服務架構和docker容器技術的paas雲平台建設目標是給我們的開發人員提供一套服務快速開發、部署、運維管理、持續開發持續集成的流程。平台提供基礎設施、中間件、數據服務、雲伺服器等資源，開發人員只需要開發業務代碼並提交到平台代碼庫，做一些必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，paas雲平台主要分為微服務架構、docker容器技術、dveops三部分，這篇文章重點介紹微服務架構的實施。
如果想學習java工程化、高性能及分布式、深入淺出。微服務、spring，mybatis，netty源碼分析的朋友可以加我的java高級交流：854630135，群里有阿里大牛直播講解技術，以及java大型互聯網技術的視頻免費分享給大家。
實施微服務需要投入大量的技術力量來開發基礎設施，這對很多公司來說顯然是不現實的，別擔心，業界已經有非常優秀的開源框架供我們參考使用。目前業界比較成熟的微服務框架有netflix、spring cloud和阿里的dubbo等。spring cloud是基於spring boot的一整套實現微服務的框架，它提供了開發微服務所需的組件，跟spring boot一起使用的話開發微服務架構的雲服務會變的很方便。spring cloud包含很多子框架，其中spring cloud netflix是其中的一套框架，在我們的微服務架構設計中，就使用了很多spring cloud netflix框架的組件。spring cloud netflix項目的時間還不長，相關的文檔資料很少，博主當時研究這套框架啃了很多英文文檔，簡直痛苦不堪。對於剛開始接觸這套框架的同學，要搭建一套微服務應用架構，可能會不知道如何下手，接下來介紹我們的微服務架構搭建過程以及 需要那些 框架或組件來支持微服務架構。
為了直接明了的展示微服務架構的組成及原理，畫了一張系統架構圖，如下：
從上圖可以看出，微服務訪問大致路徑為：外部請求 → 負載均衡 → 服務網關（gateway）→ 微服務 → 數據服務/消息服務。服務網關和微服務都會用到服務注冊和發現來調用依賴的其他服務，各服務集群都能通過配置中心服務來獲得配置信息。
服務網關（gateway）
網關是外界系統（如：客戶端瀏覽器、移動設備等）和企業內部系統之間的一道門，所有的客戶端請求通過網關訪問後台服務。為了應對高並發訪問，服務網關以集群形式部署，這就意味著需要做負載均衡，我們採用了亞馬遜ec2作為虛擬雲伺服器，採用elb(elastic load balancing)做負載均衡。ec2具有自動配置容量功能，當用戶流量達到尖峰，ec2可以自動增加更多的容量以維持虛擬主機的性能。elb彈性負載均衡，在多個實例間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行ssl卸載,使用nginx對加密請求進行卸載處理。外部請求經過elb負載均衡後路由到gateway集群中的某個gateway服務，由gateway服務轉發到微服務。服務網關作為內部系統的邊界，它有以下基本能力：
1、動態路由：動態的將請求路由到所需要的後端服務集群。雖然內部是復雜的分布式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了後端服務的復雜性。
2、限流和容錯：為每種類型的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後台服務不被大流量沖垮；黨內部服務出現故障時直接在邊界創建一些響應，集中做容錯處理，而不是將請求轉發到內部集群，保證用戶良好的體驗。
3、身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現反爬蟲功能。
4、監控：網關可以收集有意義的數據和統計，為後台服務優化提供數據支持。
5、訪問日誌：網關可以收集訪問日誌信息，比如訪問的是哪個服務？處理過程（出現什麼異常）和結果？花費多少時間？通過分析日誌內容，對後台系統做進一步優化。
我們採用spring cloud netflix框架的開源組件zuul來實現網關服務。zuul使用一系列不同類型的過濾器（filter），通過重寫過濾器，使我們能夠靈活的實現網關（gateway）的各種功能。
如果想學習java工程化、高性能及分布式、深入淺出。微服務、spring，mybatis，netty源碼分析的朋友可以加我的java高級交流：854630135，群里有阿里大牛直播講解技術，以及java大型互聯網技術的視頻免費分享給大家。
服務注冊與發現
由於微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間通過輕量機制進行通信，這就引入了服務注冊與發現的問題，服務的提供方要注冊報告服務地址，服務調用放要能發現目標服務。我們的微服務架構中使用了eureka組件來實現服務的注冊與發現。所有的微服務（通過配置eureka服務信息）到eureka伺服器中進行注冊，並定時發送心跳進行 健康 檢查，eureka默認配置是30秒發送一次心跳，表明服務仍然處於存活狀態，發送心跳的時間間隔可以通過eureka的配置參數自行配置，eureka伺服器在接收到服務實例的最後一次心跳後，需要等待90秒（默認配置90秒，可以通過配置參數進行修改）後，才認定服務已經死亡（即連續3次沒有接收到心跳），在eureka自我保護模式關閉的情況下會清除該服務的注冊信息。所謂的自我保護模式是指，出現網路分區、eureka在短時間內丟失過多的服務時，會進入自我保護模式，即一個服務長時間沒有發送心跳，eureka也不會將其刪除。自我保護模式默認為開啟，可以通過配置參數將其設置為關閉狀態。
eureka服務以集群的方式部署（在博主的另一篇文章中詳細介紹了eureka集群的部署方式），集群內的所有eureka節點會定時自動同步微服務的注冊信息，這樣就能保證所有的eureka服務注冊信息保持一致。那麼在eureka集群里，eureka節點是如何發現其他節點的呢？我們通過dns伺服器來建立所有eureka節點的關聯，在部署eureka集群之外還需要搭建dns伺服器。
當網關服務轉發外部請求或者是後台微服務之間相互調用時，會去eureka伺服器上查找目標服務的注冊信息，發現目標服務並進行調用，這樣就形成了服務注冊與發現的整個流程。eureka的配置參數數量很多，多達上百個，博主會在另外的文章里詳細說明。
微服務部署
微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務（也叫邊緣服務）和後端服務（也叫中間服務），前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的設備（pc、phone等），所有的服務啟動時都會到eureka伺服器進行注冊，服務之間會有錯綜復雜的依賴關系。當網關服務轉發外部請求調用前端服務時，通過查詢服務注冊表就可以發現目標服務進行調用，前端服務調用後端服務時也是同樣的道理，一次請求可能涉及到多個服務之間的相互調用。由於每個微服務都是以集群的形式部署，服務之間相互調用的時候需要做負載均衡，因此每個服務中都有一個lb組件用來實現負載均衡。
微服務以鏡像的形式，運行在docker容器中。docker容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每台伺服器上安裝運行環境，如果我們的伺服器數量龐大，在每台伺服器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用docker容器技術，我們只需要將所需的基礎鏡像（jdk等）和微服務生成一個新的鏡像，將這個最終的鏡像部署在docker容器中運行，這種方式簡單、高效，能夠快速部署服務。每個docker容器中可以運行多個微服務，docker容器以集群的方式部署，使用docker swarm對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。
服務容錯
微服務之間存在錯綜復雜的依賴關系，一次請求可能會依賴多個後端服務，在實際生產中這些服務可能會產生故障或者延遲，在一個高流量的系統中，一旦某個服務產生延遲，可能會在短時間內耗盡系統資源，將整個系統拖垮，因此一個服務如果不能對其故障進行隔離和容錯，這本身就是災難性的。我們的微服務架構中使用了hystrix組件來進行容錯處理。hystrix是netflix的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。
1、熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務調用方會主動啟動熔斷，執行fallback邏輯直接返回，不會繼續調用服務進一步拖垮系統。熔斷器默認配置服務調用錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然調用失敗，則回到熔斷狀態，如果調用成功，則關閉熔斷模式。
2、隔離模式：hystrix默認採用線程隔離，不同的服務使用不同的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其他的服務正常運行不受影響，達到隔離的效果。例如我們通過andthreadpoolkey配置某個服務使用命名為testthreadpool的線程池，實現與其他命名的線程池隔離。
3、回退（fallback）：fallback機制其實是一種服務故障時的容錯方式，原理類似java中的異常處理。只需要繼承hystixcommand並重寫getfallback()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或預設值，也可以返回備份數據等。當服務調用出現異常時，會轉向執行getfallback()。有以下幾種情況會觸發fallback：
1）程序拋出非hystrixbadrequestexcepption異常，當拋出hystrixbadrequestexcepption異常時，調用程序可以捕獲異常，沒有觸發fallback，當拋出其他異常時，會觸發fallback；
2）程序運行超時；
3）熔斷啟動；
4）線程池已滿。
4、限流： 限流是指對服務的並發訪問量進行限制，設置單位時間內的並發數，超出限制的請求拒絕並fallback，防止後台服務被沖垮。
hystix使用命令模式hystrixcommand包裝依賴調用邏輯，這樣相關的調用就自動處於hystrix的彈性容錯保護之下。調用程序需要繼承hystrixcommand並將調用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（非同步非阻塞）來觸發執行run()。
動態配置中心
微服務有很多依賴配置，某些配置參數在服務運行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。傳統的實現信息配置的方法，比如放在xml、yml等配置文件中，和應用一起打包，每次修改都要重新提交代碼、打包構建、生成新的鏡像、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支持微服務動態配置。我們使用spring cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務代碼都存放在git伺服器私有倉庫裡面，所有需要動態配置的配置文件存放在git伺服器下的configserver（配置中心，也是一個微服務）服務中，部署到docker容器中的微服務從git伺服器動態讀取配置文件的信息。當本地git倉庫修改代碼後push到git伺服器倉庫，git服務端hooks(post-receive，在服務端完成代碼更新後會自動調用)自動檢測是否有配置文件更新，如果有，git服務端通過消息隊列給配置中心（configserver，一個部署在容器中的微服務）發消息，通知配置中心刷新對應的配置文件。這樣微服務就能獲取到最新的配置文件信息，實現動態配置。
以上這些框架或組件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的組件，比如日誌服務組件、消息服務組件等等，根據業務需要自行選擇使用。在我們的微服務架構實施案例中，參考使用了很多spring cloud netflix框架的開源組件，主要包括zuul（服務網關）、eureka（服務注冊與發現）、hystrix（服務容錯）、ribbon（客戶端負載均衡）等。這些優秀的開源組件，為我們實施微服務架構提供了捷徑。
如果想學習java工程化、高性能及分布式、深入淺出。微服務、spring，mybatis，netty源碼分析的朋友可以加我的java高級交流：854630135，群里有阿里大牛直播講解技術，以及java大型互聯網技術的視頻免費分享給大家。
c. 基於docker部署的微服務架構（二）： 服務提供者和調用者
前一篇 基於docker部署的微服務架構（一）：服務注冊中心 已經成功創建了一個服務注冊中心，現在我們創建一個簡單的微服務，讓這個服務在服務注冊中心注冊。然後再創建一個調用者，調用此前創建的微服務。
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
這里eureka的注冊地址為上一篇中設置的defaultzone。
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 addserviceapplication.java
在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。
在服務注冊中心已經運行的情況下，運行 addserviceapplication.java 中的 main 方法，啟動微服務。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了 add-service-demo 服務。
啟動第二個實例，修改埠為 8101 ，修改 addcontroller.java 中的輸出信息為
再次運行 addserviceapplication.java 中的 main 方法。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了兩個 add-service-demo 服務，埠分別為 8100 和 8101 。
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 ribbonclientapplication.java
這里配置了一個可以從服務注冊中心讀取服務列表，並且實現了負載均衡的 resttemplate 。
在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。
可以看到這里的請求url用了服務注冊中心對應的 application 。
運行 ribbonclientapplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8200/add?a=1&b=2 ，得到返回結果：
多次訪問，查看 addserviceapplication 的控制台，可以看到兩個 add-service-demo 被負載均衡的調用。
demo源碼 spring-cloud-1.0/ribbon-client-demo
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 feignclientapplication.java
在demo包下新建一個子包service，在service子包下創建一個介面 addservice.java 調用之前創建的微服務 add-service-demo 。
這里 @feignclient 註解中的參數為服務注冊中心對應的 application 。
在demo包下再新建一個子包controller，在controller子包下創建一個 feigncontroller.java 對外提供介面。
feigncontroller 里注入了剛才創建的 addservice 介面。
運行 feignclientapplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8300/add?a=1&b=2 ，得到返回結果：
多次訪問，查看 addserviceapplication 的控制台，可以看到兩個 add-service-demo 被負載均衡的調用。
demo源碼 spring-cloud-1.0/feign-client-demo
以 add-service-demo 為例，
復制 application.yml ，重命名為 application-docker.yml ，修改 defaultzone 為：
這里修改了 defaultzone 的訪問url，如何修改取決於部署docker容器時的 --link 參數， --link 可以讓兩個容器之間互相通信。
修改 application.yml 中的 spring 節點為：
這里增加了 profiles 的配置，在maven打包時選擇不同的profile，載入不同的配置文件。
在pom.xml文件中增加：
選擇 docker profile，運行 mvn install -p docker ，打包項目並生成docker鏡像， 注意docker-maven-plugin中的
運行成功後，登錄docker節點，運行 docker images 應該可以看到剛才打包生成的鏡像了。
在前一篇中，已經創建了一個 service-registry-demo 的docker鏡像，這里先把這個鏡像運行起來。
對這條命令做個簡單說明， -d 指定當前容器運行在後台， --name 指定容器名稱， --publish 指定埠映射到宿主機， --volume 這個掛載是為了解決容器內的時區和宿主機不一致的問題，讓容器使用宿主機設置的時區，最後指定使用的docker鏡像，鏡像名稱和標簽需要根據自己的情況做修改。
運行這條命令之後， service-registry-demo 的容器就啟動了。訪問 http://宿主機ip:8000 ，打開注冊中心的頁面。
下邊啟動 add-service-demo 容器，
這條命令和上一條差不多，只是增加了一個 --link 參數， --link 指定容器間的連接，命令格式 --link 容器名:別名 ，這里連接了之前創建的名為 service-registry-demo 的容器，這里的別名和 application-docker.yml 文件中配置的 defaultzone 一致。其實就是通過別名找到了對應的容器ip，進到容器里查看 hosts 文件就明白了，其實就是加了條hosts映射。
add-service-demo 容器啟動成功之後，刷新配置中心的頁面，發現已經注冊到配置中心了。
d. 微服務初體驗（二）：使用nacos作為配置中心並集成dubbo
首先啟動nacos，按照上篇文章的步驟，啟動nacos服務和項目，訪問nacos的web頁面。確保項目中的服務都注冊到注冊中心當中了。在application.yml同級目錄下添加bootstrap.yml，在spring boot項目中bootstrap.yml會比application.yml優先初始化，所以我們需要在bootstrap.yml中引入nacos官方指定的配置文件即可（上篇文章中已經把nacos作為配置中心的配置寫入了application.yml，現在只需要把它從applicaiton.yml中剪切出來即可， 其中的spring:application:name會作為nacos中新增配置時的data id，需要留意 ），再新增屬性gorup進行分組測試，如下圖
接著打開nacos的服務的web頁面，打開配置管理->配置列表，點擊右側新增按鈕，進行新增。
data id： bootstrap.yml配置文件中spring:application:name對應的名稱 ；
group：指定分組（便於不同環境下的項目配置管理，因為筆者這里屬於測試，所以填寫的是和上文中的配置文件中group對應的test一致）；
描述：針對於該配置的描述；
配置格式：配置文件的格式，要和data id中的後綴格式一致（這里筆者用的是yml，那麼下面就選擇yaml，注意該位置也可以選擇properties，但是必須和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置內容：具體的配置內容（這里筆者將項目中的application.yml中的配置全部拷貝至其中）；
測試啟動consumer服務，在application.yml中為空的時候，項目啟動埠還是如nacos配置中的9011，說明項目依賴nacos的配置中心成功，其他服務如法炮製即可：
新增一個測試controller，然後加上@refreshscope註解，表明該controller中的配置數據為自動刷新 。
編輯nacos中的配置文件consumer新增相關參數type: test，訪問controller，返回test。效果如下圖：
將nacos中consumer.yml文件的type: test修改為type: prod，在不重啟項目的情況下重新訪問對應的controller，效果如下圖：
因為dubbo是屬於各個服務之間都要公用的依賴，所以將其引入cloud-common當中，詳細的版本可以去 mvnrepository 搜索合適自己項目的
引入依賴後需要編寫消費者服務中的配置文件，將dubbo服務注冊至nacos，新增如下內容，其中subscribed-services指的是生產者服務，prot：-1指的是埠隨機，registry:address:指的是dubbo對應的注冊中心那這里就應該設置為nacos
接下來新增介面服務，項目類型為maven項目，在項目中新增一個介面。並在cloud-provider（生產者）和cloud-consumer（消費者）pom.xml文件中都引入該模塊
在生產者實際服務中實現該介面對應的方法
在服務消費者的controller中引入該service，並在該service上加入@reference註解，注意在引入jar包的時候選擇帶有dubbo的，不要使用jdk原生的
編寫消費者服務中測試dubbo調用的介面，進行測試，測試結果如下圖：
e. 微服務架構系列之–最全配置中心對比（面試隨便裝）
本文從社區活躍度、產品特點、成功案例、產品缺點等維度，全方位對比spring cloud config、apollo、nacos、disconf、spring cloud consul、spring cloud zookeeper等幾款spring cloud生態的配置伺服器，幫助你選擇合適的配置伺服器。
一、spring cloud config
github地址
https://github.com/spring-cloud/spring-cloud-config ，star數1178，官方組件，社區較活躍
開源廠商
pivotal（spring官方團隊）
產品特點
演示環境
暫無
成功案例
n多，目前用spring cloud的大多團隊都是用的spring cloud config
缺點
二、apollo
github地址
https://github.com/ctripcorp/apollo ，star數11169，社區很活躍
開源廠商
攜程
產品特點
成功案例
攜程、網易蜂巢、中國平安等，更多公司詳見https://github.com/ctripcorp/apollo
演示環境
http://106.12.25.204:8070/
賬號/密碼：apollo/admin
缺點
暫未發現
三、nacos
github地址
https://github.com/alibaba/nacos ，star數3820，社區非常活躍
開源廠商
阿里巴巴
產品特點
成功案例
阿里巴巴、虎牙直播、工商銀行軟體開發中心、愛奇藝等，更多公司詳見https://github.com/alibaba/nacos/issues/273
演示環境
http://console.nacos.io/nacos/index.html
缺點
暫未發現明顯缺點
四、disconf
github地址
https://github.com/knightliao/disconf ，start數4505，社區活躍度一般
開源廠商
原網路員工，現在螞蟻金服
產品特點
成功案例
網路、滴滴出行、順豐、網易等，更多公司詳見https://github.com/knightliao/disconf
缺點
最新的版本發布於兩年前，有點久了。
五、spring cloud consul
github地址
https://github.com/spring-cloud/spring-cloud-consul ，star數493，官方組件，社區較活躍
開源廠商
pivotal（spring官方團隊）
產品特點
成功案例
暫未發現
演示環境
暫無
缺點
六、spring cloud zookeeper
github地址
https://github.com/spring-cloud/spring-cloud-zookeeper ，star數330，官方組件，社區較活躍
開源廠商
pivotal（spring官方團隊）
產品特點
演示環境
暫無
成功案例
暫未發現
缺點
其他
如果使用的是spring cloud kubernetes，或者將spring cloud應用部署在kubernetes環境中，還可以選擇configmap，這種方式就筆者了解，業界這么玩的還不多，暫時不分析了。已經將spring cloud kubernetes列入博客19年更新名單中了，敬請期待。
結論