當前位置:首頁 » 數據倉庫 » zuul如何配置
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

zuul如何配置

發布時間: 2022-06-25 13:33:01

① springcloud執行流程

1.Servlet

zuul.servletPath默認配置為/zuul,故請求為/zuul開頭的會跳過dispatcherServlet直接進入ZuulServlet,該配置可以自定義配置,例如用於大文件上傳

2.ZuulServlet中service方法

public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
try {
this.init((HttpServletRequest)servletRequest, (HttpServletResponse)servletResponse);
RequestContext context = RequestContext.getCurrentContext();
context.setZuulEngineRan();

try {
//運行pre過濾器
this.preRoute();
} catch (ZuulException var12) {
//有異常,執行errorFilter
this.error(var12);
//再執行postFilter
this.postRoute();
return;
}

try {
//運行rote過濾器
this.route();
} catch (ZuulException var13) {
//有異常,執行errorFilter
this.error(var13);
//再執行postFilter
this.postRoute();
return;
}

try {
//運行post過濾器
this.postRoute();
} catch (ZuulException var11) {
//有異常,執行errorFilter
this.error(var11);
}
} catch (Throwable var14) {
this.error(new ZuulException(var14, 500, "UNHANDLED_EXCEPTION_" + var14.getClass().getName()));
} finally {
RequestContext.getCurrentContext().unset();
}
}

3.FilterProcessor

其運行交由FilterProcessor中的方法runFilters,根據service中的順序,取不同的filter類型,執行其中的run方法

public Object runFilters(String sType) throws Throwable {
if (RequestContext.getCurrentContext().debugRouting()) {
Debug.addRoutingDebug("Invoking {" + sType + "} type filters");
}

boolean bResult = false;
List<ZuulFilter> list = FilterLoader.getInstance().getFiltersByType(sType);
if (list != null) {
for(int i = 0; i < list.size(); ++i) {
ZuulFilter zuulFilter = (ZuulFilter)list.get(i);
Object result = this.processZuulFilter(zuulFilter);//見下面zuulFilter的runFilter()
if (result != null && result instanceof Boolean) {
bResult |= ((Boolean)result).booleanValue();
}
}
}

return bResult;
}

zuulFilter的runFilter方法,當filter的shouldFilter()返回true時才執行run()方法

public ZuulFilterResult runFilter() {
ZuulFilterResult zr = new ZuulFilterResult();
if (!this.isFilterDisabled()) {
if (this.shouldFilter()) {
Tracer t = TracerFactory.instance().startMicroTracer("ZUUL::" + this.getClass().getSimpleName());

try {
Object res = this.run();
zr = new ZuulFilterResult(res, ExecutionStatus.SUCCESS);
} catch (Throwable var7) {
t.setName("ZUUL::" + this.getClass().getSimpleName() + " failed");
zr = new ZuulFilterResult(ExecutionStatus.FAILED);
zr.setException(var7);
} finally {
t.stopAndLog();
}
} else {
zr = new ZuulFilterResult(ExecutionStatus.SKIPPED);
}
}

return zr;
}

4.獲取過濾器FilterRegistry

其中的屬性private final ConcurrentHashMap<String, ZuulFilter> filters = new ConcurrentHashMap();
保存所有的過濾器
例子中有12個(其中有兩個為自定義的):

[org.springframework.cloud.netflix.zuul.filters.route.SimpleHostRoutingFilter@3dc68586,
org.springframework.cloud.netflix.zuul.filters.pre.Servlet30WrapperFilter@4001d8c1,
org.springframework.cl

② zuul sentinel責任鏈模式如何實現

具體步驟如下:
責任鏈模式(Chain of Responsibility Pattern)為請求創建了一個接收者對象的鏈。這種模式給予請求的類型,對請求的發送者和接收者進行解耦。這種類型的設計模式屬於行為型模式。
意圖:避免請求發送者與接收者耦合在一起,讓多個對象都有可能接收請求,將這些對象連接成一條鏈,並且沿著這條鏈傳遞請求,直到有對象處理它為止。
主要解決:職責鏈上的處理者負責處理請求,客戶只需要將請求發送到職責鏈上即可,無須關心請求的處理細節和請求的傳遞,所以職責鏈將請求的發送者和請求的處理者解耦了。
何時使用:在處理消息的時候以過濾很多道。
如何解決:攔截的類都實現統一介面。
關鍵代碼:Handler 裡面聚合它自己,在 HandlerRequest 里判斷是否合適,如果沒達到條件則向下傳遞,向誰傳遞之前 set 進去。
優點: 1、降低耦合度。它將請求的發送者和接收者解耦。 2、簡化了對象。使得對象不需要知道鏈的結構。 3、增強給對象指派職責的靈活性。通過改變鏈內的成員或者調動它們的次序,允許動態地新增或者刪除責任。 4、增加新的請求處理類很方便。
缺點: 1、不能保證請求一定被接收。 2、系統性能將受到一定影響,而且在進行代碼調試時不太方便,可能會造成循環調用。 3、可能不容易觀察運行時的特徵,有礙於除錯。
使用場景: 1、有多個對象可以處理同一個請求,具體哪個對象處理該請求由運行時刻自動確定。 2、在不明確指定接收者的情況下,向多個對象中的一個提交一個請求。 3、可動態指定一組對象處理請求。

③ 有了sprint cloud的zuul還需要用nginx嗎

根據實際情況來選擇要不要增加nginx。

nginx是做負載均衡請求轉發,更多被用作負載均衡器使用的;

zuul是請求轉發,一般用來做網關的。

zuul配合eureka來使用,zuul功能也很強大,nginx要做這些功能也是可以,但是需要各種腳本語言來支持,比如lua腳本等,但是zuul來說的話開發成本就低很多,懂spring就夠了。

這塊還會設計到一些分布式原子化問題,我都是一個坑一個坑踩過來的,有什麼問題可以繼續探討,建議還是多了解一下spring cloud的核心思想,把整個分布式架構了解一下。

④ spring zuul配置映射9000 為oauth認證訪問http://localhost:9090/9000/oauth/token報Full authentication

會不會是zuul映射地址寫錯了,或者沒有注冊到注冊中心。

⑤ 分布式系統統一管理的配置文件其他服務如何調用

(1)服務於注冊中心(Eureka)

(2)ribbon

(3)Feign

(4)斷路器(Hystrix)

(5)路由網關(zuul)

(6)分布式配置中心(Spring Cloud Config)

(7)消息匯流排(Spring Cloud bus)等等

⑥ spring cloud的zuul怎樣整合oauth2

Spring Cloud項目的既定目標在於為Spring開發人員提供一整套易於使用的工具集,從而保證其輕松構建起自己需要的分布式系統方案。為了實現這一目標,Spring Cloud以Netflix OSS堆棧為基礎將大量實現堆棧加以整合並打包。這些堆棧而後可以通過大家所熟知的各類基於注釋的配置工具、Java配置工具以及基於模板的編程工具實現交付。下面就讓我們一起了解Spring Cloud當中的幾類常見組件。 Spring Cloud Config Server Spring Cloud Config Server能夠提供一項具備橫向擴展能力的集中式配置服務。它所使用的數據被保存在一套可插拔庫層當中,後者目前能夠支持本地存儲、Git以及Subversion。通過利用一套版本控制系統作為配置存儲方案,開發人員能夠輕松實現版本與審計配置的內容調整。 如何利用Spring Cloud構建起自我修復型分布式系統 配置內容會以Java屬性或者YAML文件的形式體現。該Config Server會將這些文件合並為環境對象,其中包含易於理解的Spring屬性模型以及作為REST API存在的配置文件。任何應用程序都能夠直接調用該REST API當中所包含的配置數據,但我們也可以將智能客戶端綁定方案添加到Spring Boot應用程序當中,並由後者自動將接收自Config Server的配置信息分配至任意本地配置當中。 Spring Cloud Bus Spring Cloud Config Server是一套強大的配置分發機制,能夠在保障一致性的前提下將配置內容分發到多個應用程序實例當中。然而根據其設計思路的限定,我們目前只能在應用程序啟動時對其配置進行更新。在向Git中的某一屬性發送新值時,我們需要以手動方式重啟每個應用程序進程,從而保證該值被切實納入應用當中。很明顯,大家需要能夠在無需重啟的前提下完成對應用程序配置內容的更新工作。 如何利用Spring Cloud構建起自我修復型分布式系統 Spring Cloud Bus的任務正是為應用程序實例添加一套管理背板。它目前依靠將一套客戶端綁定至一組AMQP交換與隊列當中來實現,但這一後端在設計上也實現了可插拔特性。Spring Cloud Bus為我們的應用程序帶來了更多管理端點。在圖二中,我們可以看到一個面向greeting屬性的值被發送至Git當中,而後一條請求被發送至應用A中的/bus/refresh端點。該請求會觸發以下三個事件: 應用A從Config Server處請求獲取最新版本的配置內容。任意註明了@RefreshScope的Spring Bean都會被重新初始化並載入新的配置內容。 應用A向AMQP交換機制發送一條消息,表明其已經收到更新指示。 通過監聽AMQP隊列而被納入Cloud Bus的應用B與應用C會獲取到上述消息,並以與應用A同樣的方式實現配置更新。 現在我們已經有能力在無需重啟的情況下對應用程序配置進行更新了。

⑦ spring cloud 中的zuul怎麼保證自身高可用

zuul多個節點啟動,自身也可以作為服務,注冊到eureka上。
或者也可以一組節點配置為upstream,通過nginx的負載均衡分布。
後面一種方式需要自己開發監控插件,在節點出錯的時候,自動修改nginx的配置並reload,通過這個方式把節點去掉。在節點恢復之後,通過同樣的方式重新掛載上去。