springCloud-分析+總結(jié)
一.Eureka
eureka是一個(gè)分布式微服務(wù)的架構(gòu)一個(gè)框架,eureka是netflix的一個(gè)開源框架,主要用于服務(wù)注冊與發(fā)現(xiàn).
當(dāng)項(xiàng)目啟動(dòng)時(shí),生產(chǎn)者服務(wù)會將自己的服務(wù)信息注冊到注冊中心,然后消費(fèi)者又會從注冊中心再拉取最新的服務(wù)列表,
什么是注冊中心?
1.在啟動(dòng)每一個(gè)服務(wù)的時(shí)候,會把自己的信息注冊到注冊中心中,并且會拉取一份最新的服務(wù)列表
2.每隔30秒會給注冊中心發(fā)送心跳包,確保它還活著,并且會拉取一份最新的服務(wù)列表
3.如果連續(xù)3次,注冊中心都沒有接收到心跳包,那么它會把這個(gè)節(jié)點(diǎn)從注冊中心的服務(wù)列表中去掉
Eureka Server 在運(yùn)行期間會去統(tǒng)計(jì)心跳失敗比例在 15 分鐘之內(nèi)是否低于 85%难衰，如果低于 85%浸剩，Eureka Server 會將這些實(shí)例保護(hù)起來竿报，讓這些實(shí)例不會過期，但是在保護(hù)期內(nèi)如果服務(wù)剛好這個(gè)服務(wù)提供者非正常下線了，此時(shí)服務(wù)消費(fèi)者就會拿到一個(gè)無效的服務(wù)實(shí)例辙纬，此時(shí)會調(diào)用失敗生兆，對于這個(gè)問題需要服務(wù)消費(fèi)者端要有一些容錯(cuò)機(jī)制，如重試拴还，斷路器等.
在真實(shí)環(huán)境當(dāng)中,基本不會出現(xiàn)大批量的服務(wù)器宕機(jī),
比如:網(wǎng)絡(luò)波動(dòng),注冊中心連續(xù)3次都沒有接受到心跳包,如果沒喲自我保護(hù)機(jī)制,那么這些節(jié)點(diǎn)就直接被踢出了
但是這些節(jié)點(diǎn)僅僅是因?yàn)榫W(wǎng)絡(luò)波動(dòng)導(dǎo)致,并不是真的是服務(wù)器的問題,所以不應(yīng)該去除至少在15分鐘之內(nèi)這些節(jié)點(diǎn)都是安全的,如果這時(shí)有消費(fèi)者訪問這些有問題的節(jié)點(diǎn),可以通過后臺設(shè)置重試次數(shù)或者降級處理,一旦網(wǎng)絡(luò)恢復(fù)了就可以恢復(fù)正常運(yùn)行了
二.Ribbon
Spring Cloud Ribbon是一個(gè)基于HTTP和TCP的客戶端負(fù)載均衡工具跨晴，它基于Netflix Ribbon實(shí)現(xiàn)。通過Spring Cloud的封裝片林，可以讓我們輕松地將面向服務(wù)的REST模版請求自動(dòng)轉(zhuǎn)換成客戶端負(fù)載均衡的服務(wù)調(diào)用端盆。Spring Cloud Ribbon雖然只是一個(gè)工具類框架，它不像服務(wù)注冊中心费封、配置中心焕妙、API網(wǎng)關(guān)那樣需要獨(dú)立部署，但是它幾乎存在于每一個(gè)Spring Cloud構(gòu)建的微服務(wù)和基礎(chǔ)設(shè)施中弓摘。
自己的理解:
首先ribbon是netflix的一個(gè)開源框架,主要是用來做遠(yuǎn)程調(diào)用的,使用的是restTemplate的方式進(jìn)行遠(yuǎn)程調(diào)用(URLconnection),使用時(shí)需要引入依賴,(如果已經(jīng)引入eureka的依賴,這個(gè)則不用引入了,因?yàn)閑ureka的依賴自帶ribbon的依賴)
其次,在消費(fèi)者的服務(wù)的啟動(dòng)類中將restTemplate這個(gè)對象交給spring管理,同時(shí)貼上@loadBalanced這個(gè)注解,表示使用ribbon的負(fù)載均衡
最后在消費(fèi)者的controller中使用Resttemplate的方式將生產(chǎn)者的服務(wù)名稱作為url的一部分傳進(jìn)參數(shù)中,ribbon底層會從本地列表服務(wù)中找到或者匹配到url中所寫生產(chǎn)者的服務(wù)名稱.然后替換成對應(yīng)的ip和端口,最后根據(jù)拼接好的url地址發(fā)送get異步請求,獲取數(shù)據(jù)
三:Feign
由于ribbon使用起來比較麻煩,需要建restTemplate,使用拼接url的方式進(jìn)行遠(yuǎn)程調(diào)用,不方便,現(xiàn)在出現(xiàn)了feign,feign的出現(xiàn)完美的解決了這個(gè)問題,(feign只是對了ribbon進(jìn)行了封裝,然后加入了自己的一些東西,feign的底層還是ribbon)feign采用的方式通過注入一個(gè)接口的方式來實(shí)現(xiàn)的,具體如下:
1.引入feign的依賴,spring集成好的依賴openFeign這個(gè)依賴
2.需要在生產(chǎn)者的api中新建一個(gè)接口feign的接口,在這個(gè)接口上貼上@FeignClient注解,表示這個(gè)一個(gè)feign的客戶端,寫上需要遠(yuǎn)程調(diào)用的服務(wù)的名稱
3.在這個(gè)接口的方法上貼上@RequestMapping("/get")這個(gè)注解
4.在方法的參數(shù)中貼上@RequestParam("id")這個(gè)注解
5.在生成者的服務(wù)中新建一個(gè)類實(shí)現(xiàn)剛才新建的feign的接口,這個(gè)類需要貼上@restController這個(gè)注解,里面所寫的方法和內(nèi)容和這個(gè)服務(wù)中的controller類中寫的是一樣的,因此controller可以不需要寫了.
6.在消費(fèi)者服務(wù)中的啟動(dòng)類中需要貼上@EnableFeignClients這個(gè)注解,貼上這個(gè)注解表示告訴spring框架要掃描所有貼上@FeignClient注解的類或者feign的客戶端,注意:掃描的是當(dāng)前包及其子包下面的類,因此要想@feignClient這個(gè)注解被掃描到,需要@FeignClient和@EnableFeignClient這個(gè)注解所在的包名是相同的,這樣當(dāng)消費(fèi)者服務(wù)啟動(dòng)時(shí)才可以掃描到生產(chǎn)者服務(wù)中的feign客戶端
7.在消費(fèi)者服務(wù)中的業(yè)務(wù)層注入feign接口依賴,然后通過feign接口調(diào)用方法時(shí),feign底層是通過jdk動(dòng)態(tài)代理的方式(使用反射)創(chuàng)建一個(gè)代理對象,這個(gè)對象根據(jù)反射獲取接口上注解以及方法上的注解及方法參數(shù)中的注解,根據(jù)這些注解就可以獲取對應(yīng)的值,比如:服務(wù)名稱,路徑,參數(shù),然后將獲取到這些值拼接成一個(gè)路徑,然后根據(jù)參數(shù)名稱去本地服務(wù)列表中拿到對應(yīng)的ip和端口,然后替換到url中,然后這個(gè)代理對象根據(jù)這個(gè)url使用HttpUrlConnection發(fā)送http請求.
8.請求最終會到生產(chǎn)者服務(wù)中實(shí)現(xiàn)了feign接口的實(shí)現(xiàn)類中(和以前寫的controller是一樣的,區(qū)別就是添加了這個(gè)類實(shí)現(xiàn)了自定義的feign接口),然后調(diào)用業(yè)務(wù)方法,獲取數(shù)據(jù),返回給調(diào)用者或者消費(fèi)者
9.消費(fèi)者服務(wù)中的feign接口的代理對象獲取生產(chǎn)者服務(wù)返回的數(shù)據(jù)封裝到product對象中.
四.Ribbon和Feign的超時(shí)時(shí)間和超時(shí)重試次數(shù)的設(shè)置
使用ribbon做遠(yuǎn)程調(diào)用時(shí),默認(rèn)超時(shí)時(shí)間是60s
源碼中默認(rèn)options中配置的是6000毫秒焚鹊，但是Feign默認(rèn)加入了Hystrix,此時(shí)默認(rèn)是1秒超時(shí).
我們可以通過設(shè)置修改feign的超時(shí)時(shí)間:
feign:
? client:
?? config:
? ?? default:
? ? ?? connectTimeout: 5000 #等待連接時(shí)間設(shè)置為5秒 表示連接的時(shí)間如果超過了5s則報(bào)錯(cuò)或降級
? ? ?? readTimeout: 5000 #相當(dāng)于通話時(shí)間設(shè)置為5s,連接上了讀的時(shí)候超過了5秒則報(bào)錯(cuò)或降級
feign的默認(rèn)重試次數(shù)為1次:表示第一次連接不成功的話,會在連接一次
可以進(jìn)行修改設(shè)置:無論是超時(shí)時(shí)間設(shè)置還是超時(shí)重試次數(shù)設(shè)置都是在消費(fèi)者服務(wù)的配置文件中進(jìn)行設(shè)置的
product-server:? #表示對哪一個(gè)服務(wù)進(jìn)行超時(shí)時(shí)間重試次數(shù)的設(shè)置
? ? ribbon:? #ribbon的負(fù)載均衡策略的設(shè)置RandomRule表示隨機(jī)策略,RoundRobinRule表示輪詢策略
? ? NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #表示隨機(jī)
? ? MaxAutoRetries: 0? #表式相同的服務(wù)最大超時(shí)重試次數(shù),設(shè)置為0,表示不重試
? ? MaxAutoRetriesNextServer: 0 #如果生產(chǎn)者服務(wù)有多個(gè),表示不同的服務(wù)的最大超時(shí)重試次數(shù)
通過以上也可以看出,feign底層使用的就是ribbon.因此ribbon的相關(guān)配置在feign中也是生效的
遠(yuǎn)程調(diào)用時(shí),超時(shí)時(shí)間重試一定是要保證業(yè)務(wù)是等冪性操作,:比如如果是添加操作,有可能會造成重復(fù)執(zhí)行
所謂等冪性操作就是無論重試多少次不會造成數(shù)據(jù)庫的改變
五.Hystrix服務(wù)熔斷和降級
所謂熔斷就是當(dāng)某個(gè)服務(wù)出現(xiàn)故障時(shí),可能會造成大批量訪問,導(dǎo)致資源被耗盡,會造成一些好的服務(wù)也無法放訪問,為了避免這種情況的出現(xiàn),要對這個(gè)服務(wù)進(jìn)行熔斷處理,即熔斷表示為了防止整個(gè)系統(tǒng)故障,保護(hù)自己以及下游的一些服務(wù),而實(shí)施一種策略,也就是這個(gè)服務(wù)出現(xiàn)故障,只熔斷這服務(wù),其他正常的服務(wù)不受影響,可以正常運(yùn)行
所謂降級就是拋棄非核心業(yè)務(wù),保障核心業(yè)務(wù)不受影響,例如:雙11那一天,訂單業(yè)務(wù)非常多,為了保證核心業(yè)務(wù)訂單能夠正常運(yùn)行,將會停掉一些非核心業(yè)務(wù)的服務(wù)(比如:修改密碼,修改收貨地址等等),將這些停掉的服務(wù)器專門用來執(zhí)行訂單業(yè)務(wù),這樣就是所謂的降級,整個(gè)功能會降一級,但是核心業(yè)務(wù)不會受影響...
二者區(qū)別:觸發(fā)原因不太一樣:服務(wù)熔斷一般是某個(gè)服務(wù)（下游服務(wù)）故障引起，而服務(wù)降級一般是從整體負(fù)荷考慮韧献；
二者相同點(diǎn):
1)目的很一致: 都是從可用性可靠性著想末患，為防止系統(tǒng)的整體緩慢甚至崩潰研叫，采用的技術(shù)手段；
2)最終表現(xiàn)類似: 對于兩者來說璧针，最終讓用戶體驗(yàn)到的是某些功能暫時(shí)不可達(dá)或不可用嚷炉；
什么是服務(wù)雪崩效應(yīng)
由于某一個(gè)服務(wù)的不可用,導(dǎo)致資源被耗盡(tomcat的線程被耗盡),而進(jìn)而導(dǎo)致其他所有服務(wù)都不可以調(diào)用
如何解決:引入超時(shí)機(jī)制,引入限流機(jī)制,引入熔斷機(jī)制(當(dāng)訪問服務(wù)失敗多次以后就可以打開熔斷機(jī)制.不讓在訪問的),引入降級機(jī)制,(當(dāng)用戶訪問錯(cuò)誤的時(shí)候或者熔斷的時(shí)候,返回一個(gè)頁面或者默認(rèn)數(shù)據(jù)給用戶)
超時(shí)機(jī)制盡量不超過2秒,否則高并發(fā)下會導(dǎo)致資源被耗盡
hystrix的作用
提供了熔斷、隔離探橱、Fallback申屹、cache、監(jiān)控等功能
如何操作
ribbon集成hystrix
1.引入hystrix的依賴,netflix的hystrix的一個(gè)框架.
2.在消費(fèi)者服務(wù)的啟動(dòng)類中貼上@EnableHystrix注解或者@EnableCircuitBreaker 注解(這兩個(gè)注解是一樣的,在@EnableHystrix注解上貼有@EnableCircuitBreaker 這個(gè)注解),表示項(xiàng)目啟動(dòng)時(shí)開啟斷路器功能或者開啟服務(wù)熔斷和降級功能,
3.在消費(fèi)者服務(wù)中的controller中需要執(zhí)行熔斷降級的方法上面貼上@HystrixCommand注解,并在這個(gè)注解中配上屬性fallbackMethod="自定義的降級的方法名字",然后自定義的降級方法需要和這個(gè)原方法有一樣的參數(shù)和返回值
上面那樣就配置hystrix的熔斷降級處理,默認(rèn)超時(shí)時(shí)間是1s,只要1s內(nèi)沒有返回?cái)?shù)據(jù)則執(zhí)行降級處理,即會執(zhí)行自定義的降級方法,返回一個(gè)自定義的數(shù)據(jù),這是最外層的降級處理
feign集成hystrix
1.在生產(chǎn)者api中以前我們自定義了一個(gè)feign的接口上面貼了一個(gè)注解@feignClient,現(xiàn)在要在使用feign中的hystrix降級功能,需要在這個(gè)注解中添加一個(gè)屬性fallback="我們自定義的一個(gè)feignHystrix降級類.Class"
2.既然要使用feign的降級,那就需要自定義一個(gè)降級方法,因此在api中自定義個(gè)降級類,也就是上面說的feignHystix降級類,這個(gè)類實(shí)現(xiàn)feign的接口,然后貼上@componet注解交給spring管理
3.在這個(gè)類中我們實(shí)現(xiàn)接口的這個(gè)方法,這個(gè)方法就是我們要寫的降級的方法,里面可以寫當(dāng)出現(xiàn)降級以后返回的數(shù)據(jù)
4.要使用feign中的hystix的降級處理,必須要開啟hystix,默認(rèn)是關(guān)閉的
#開啟feign中的hystrix,默認(rèn)是關(guān)閉的,需要手動(dòng)打開
#一般feign降級和hystrix降級只需打開一個(gè)即可,兩個(gè)都可以實(shí)現(xiàn)降級處理
feign:
? hystrix:
?? enabled: true? #開啟feign的hystirx熔斷降級
? client:
?? config:
? ?? default:
? ? ?? connectTimeout: 5000 #等待連接時(shí)間設(shè)置為5秒 表示連接的時(shí)間如果超過了5s則報(bào)錯(cuò)或降級
? ? ?? readTimeout: 5000 #相當(dāng)于通話時(shí)間設(shè)置為5s,連接上了讀的時(shí)候超過了5秒則報(bào)錯(cuò)或降級
#設(shè)置hystrix的超時(shí)時(shí)間
hystrix:
? command:
?? default:
? ?? execution:
? ? ?? isolation:
? ? ? ?? thread:
? ? ? ? ?? timeoutInMilliseconds: 6000
hystix的默認(rèn)超時(shí)時(shí)間是1s,可以通過配置進(jìn)行修改這個(gè)時(shí)間,feign的降級默認(rèn)是關(guān)閉的,需要手動(dòng)打開,當(dāng)feign的超時(shí)時(shí)間到了之后要執(zhí)行降級處理
hystrixCommand的超時(shí)時(shí)間需要比配置feign遠(yuǎn)程調(diào)用的時(shí)間要大才有意義
真實(shí)開發(fā)環(huán)境中,超時(shí)的時(shí)間的不能超過2s.如果需要大于2s需要使用異步或線程處理
六.如何理解feign中hystrix降級和最外層的Hystrix的降級處理
分為以下幾種情況:
情況一:假如消費(fèi)者服務(wù)hystix降級開啟,默認(rèn)1s超時(shí),feign沒有開啟hystix降級,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s導(dǎo)致hystix降級,執(zhí)行hystix降級方法,用戶接收hystix降級方法的返回?cái)?shù)據(jù)
情況二:假如消費(fèi)者服務(wù)hystix降級開啟,默認(rèn)1s超時(shí),feign開啟hystix降級,.默認(rèn)超時(shí)時(shí)間為1s,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s導(dǎo)致hystix降級,feign也會降級,執(zhí)行hystix降級方法,feign的降級方法也會執(zhí)行,但是用戶接收hystix降級方法的返回?cái)?shù)據(jù)
情況三:假如消費(fèi)者服務(wù)hystix降級開啟,默認(rèn)1s超時(shí),feign開啟hystix降級,.修改超時(shí)時(shí)間為2s,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s導(dǎo)致hystix降級,feign不會降級(因?yàn)榈?s時(shí)沒有返回?cái)?shù)據(jù)就會執(zhí)行hystix的降級方法),執(zhí)行hystix降級方法,用戶接收hystix降級方法的返回?cái)?shù)據(jù)
情況四:假如消費(fèi)者服務(wù)hystix降級開啟,默認(rèn)1s超時(shí),feign開啟hystix降級,.修改超時(shí)時(shí)間為4s,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s導(dǎo)致hystix降級,feign不會降級,執(zhí)行hystix降級方法,用戶接收hystix降級方法的返回?cái)?shù)據(jù)
情況五:假如消費(fèi)者服務(wù)hystix降級開啟,修改超時(shí)時(shí)間為4s超時(shí),feign開啟hystix降級,.修改超時(shí)時(shí)間為4s,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s后還未到超時(shí)時(shí)間,則不會執(zhí)行feign的降級處理,但是由于feign返回?cái)?shù)據(jù)到消費(fèi)者服務(wù)接收數(shù)據(jù)時(shí)間如果大于4s則會執(zhí)行hystix降級方法,返回hysrix數(shù)據(jù),如果不大于4s,則都不會進(jìn)行降級處理,返回feign返回的數(shù)據(jù)
情況六:假如消費(fèi)者服務(wù)hystix降級開啟,修改超時(shí)時(shí)間為5s超時(shí),feign開啟hystix降級,.修改超時(shí)時(shí)間為4s,生產(chǎn)者業(yè)務(wù)執(zhí)行睡眠3s
則:由于睡眠3s后還未到超時(shí)時(shí)間,則不會執(zhí)行feign的降級處理,但是由于feign返回?cái)?shù)據(jù)到消費(fèi)者服務(wù)接收數(shù)據(jù)時(shí)間不足5s,因此不會執(zhí)行降級方法,正常返回?cái)?shù)據(jù)
七.zuul微服務(wù)網(wǎng)關(guān)
引入依賴:Netflix開源的微服務(wù)網(wǎng)關(guān)隧膏，和Eureka,Ribbon,Hystrix等組件配合使用.
在啟動(dòng)類上貼上@EnableZuulProxy注解
配置zuul網(wǎng)關(guān)服務(wù)信息
server:? port: 9000spring:? application:? ? name: zuul-servereureka:? client:? ? serviceUrl:? ? ? defaultZone: http://localhost:8761/eureka/
自定義路由規(guī)則
#zuul網(wǎng)關(guān)的自定義路由配置zuul:? ignoredPatterns: /*-server/**? #這個(gè)配置表示忽略默認(rèn)配置? routes:? ? order-server-route:? ? ? path: /order/**? #這個(gè)配置表示使用order的路徑則會訪問order的服務(wù)? ? ? serviceId: order-server? ? product-server-route:? ? ? path: /product/**? #這個(gè)配置表示使用product的路徑則會訪問product的服務(wù)? ? ? serviceId: product-server? sensitive-headers:? ? #給一個(gè)空值表示不會過濾到cookie的信息
cookie請求頭問題
sensitiveHeaders:? ? #配置這個(gè)表示不讓cookie請求頭被攔截
八.鏈路追蹤Sleuth和Zipkin
1.在需要進(jìn)行日志追蹤的服務(wù)中引入依賴sleuth和zipkin的依賴,不過zipkin已經(jīng)包含了sleuth依賴,因此只需引入zipkin這一個(gè)依賴集合
2.在需要使用鏈路追蹤的服務(wù)的配置文件中添加zipkin的地址
spring:
zipkin:
?? base-url: http://localhost:9411
? sleuth:
?? sampler:
? ?? probability: 1
九.分布式配置中心
Spring Cloud Config用來為分布式系統(tǒng)中的基礎(chǔ)設(shè)施和微服務(wù)應(yīng)用提供集中化的外部配置支持哗讥，分為服務(wù)端和客戶端兩個(gè)部分。其中服務(wù)端又稱為分布式配置中心私植，是一個(gè)獨(dú)立的微服務(wù)應(yīng)用忌栅，用來連接配置倉庫并為客戶端提供獲取配置信息；而客戶端則是微服務(wù)架構(gòu)中的各個(gè)微服務(wù)應(yīng)用或基礎(chǔ)設(shè)施曲稼，它們通過指定配置中心來管理應(yīng)用資源和業(yè)務(wù)相關(guān)的配置內(nèi)容索绪。服務(wù)器存儲后端的默認(rèn)實(shí)現(xiàn)使用git，也可以使用SVN倉庫或者本地文件系統(tǒng)贫悄。
關(guān)于git配置信息如下：
spring.cloud.config.server.git.uri: 配置Git倉庫位置
spring.cloud.config.server.git.search-paths: 配置倉庫路徑下的相對搜索位置瑞驱，默認(rèn)是只在根目錄下尋找，配置相對位置后窄坦，除了根目錄還回去配置的位置下尋找唤反。
spring.cloud.config.server.git.username: 訪問Git倉庫的用戶名
spring.cloud.config.server.git.password: 訪問Git倉庫的密碼
配置中心的作用和好處
安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏時(shí)效性：修改配置鸭津，需要重啟服務(wù)才能生效局限性：無法支持動(dòng)態(tài)調(diào)整：例如日志開關(guān)彤侍、功能開關(guān)
如何操作:
1.創(chuàng)建config-server服務(wù),并引入依賴spring-cloud-config-server
2.配置文件
server:
? port: 9100
spring:
? application:
?? name: config-server
? cloud:
?? config:
? ?? server:
? ? ?? git:
? ? ? ?? uri: https://gitee.com/d.git
? ? ? ?? username: 自己的gitte賬號
? ? ? ?? password: 自己gitee密碼
eureka:
? client:
?? serviceUrl:
? ?? defaultZone: http://localhost:8761/eureka/? #eureka的地址
3.啟動(dòng)類上貼注解@EnableConfigServer
4.創(chuàng)建碼云倉庫，并把倉庫的地址添加到y(tǒng)ml文件中逆趋，添加Eureka注冊中心的配置到application.yml中盏阶。注意如果使用的git的倉庫地址是http協(xié)議的 那么必須在后面繼續(xù)追加賬號和密碼，如果使用是ssh的就不用闻书。
5.在其他需要將配置文件上傳到碼云交給配置中心管理的服務(wù)中添加配置中心客戶端依賴spring-cloud-config-client
6.將原來的配置文件application.yml改為bootstrap.yml
boostrap.yml如下:
spring:
? application:
?? name: order-server
? cloud:
?? config:
? ?? discovery:
? ? ?? service-id: config-server
? ? ?? enabled: true
? ? ?? label: master
eureka:
? client:
?? serviceUrl:
? ?? defaultZone: http://localhost:8761/eureka/
7.將原來的application.yml的中心移到碼云上進(jìn)行管理
由配置中心進(jìn)行統(tǒng)一管理,流程如下:
1>項(xiàng)目啟動(dòng)時(shí),商品服務(wù)會從注冊中心拉取最新的配置中心的config-server的ip地址
2>根據(jù)config-server的ip地址發(fā)起請求,根據(jù)product-server的名字從配置中心獲取對應(yīng)的配置文件
3>項(xiàng)目讀取獲取到的配置文件product-server.yml.啟動(dòng)服務(wù)
bootstrap.yml是先讀取,優(yōu)先級是大于application.yml的,因此先從bootstrap.yml中進(jìn)行讀取
配置中心由于配置了遠(yuǎn)程倉庫的地址,用戶名和密碼,則會自動(dòng)從碼云上將配置文件緩存到本地服務(wù)列表中,項(xiàng)目啟動(dòng)時(shí)進(jìn)行讀取
