閱讀字數:1501 | 4分鐘閱讀
嘉賓演講視訊回顧及PPT地址:t.cn/RnP2eZZ
摘要
SpringCloud 中國社群創始人許進在本次演講中為大家分享自己在Spring Cloud Zuul與閘道器中介軟體的一些研發經驗。
閘道器介紹
API閘道器提供API全託管服務,豐富的API管理功能,輔助企業管理⼤規模的API,以降低管理成本和安全風險。——來自阿里雲的定義。
包括協議適配、協議轉發、安全策略(WAF)、防刷,流量量、監控日誌。
閘道器常用功能
統一接入:為各種無線應用提供統一接入服務;
高效能、高併發、高可靠性;
負載均衡,容災切換(異地多活)。
安全防護:和安全部合作,IP黑名單,URL黑名單;
風防控制,防惡意攻擊等。
協議適配:前端系統(http、http2)後端業務系統(RPC);
長、短連結支援;
根據前端請求路由至相應的SOA服務並執行,返回結果給前端。
流量管控:服務降級;熔斷;路由(異地多活中的應用)。
上圖是在異地多活中閘道器的位置。在異地多活中,閘道器可能需要開發一個filter,它主要是做使用者分片的路由。比如一個使用者在上海幫助北京的朋友下單,應該通過閘道器路由分片到北京的機房,在北京的機房中把所有服務呼叫或者資料落地等等全部做完。所以閘道器在異地多活中也是相當重要的。
Spring Cloud Zuul
SpringCloud Zuul通過與Spring Cloud Eureka進行整合,將自身註冊到Eureka Server中,與Eureka,Ribbon,Hystrix等整合,同時從Eureka中獲得了所有其它微服務的例項資訊。
首先一個http請求進來之後,一定會經過Zuul的Servlet,也可能會經過Zuul Filter Runner。Runner是統管所有Filter鏈的順序或者資料的互動,Filter Runner主要是管理整個Zuul的生命週期。
使用者請求進來後會有很多資訊,通過Request Context的上下文在Zuul的生命週期中進行傳遞。
FilterLoader是當Zuul啟動的時候會從本地或從動態Filter裡的指定目錄將Filter進行裝載。
如圖所示,Zuul除了自定義Filter之外,主要分為四種Filter型別。一種是“pre” Filters(易處理Filter),一種是“routing” Filters,就是服務路由的Filter。還有一種“post” Filters,以及“error” Filters。只要任何一個環節或者自定義的Filters出現異常之後,都會帶著Request Context上下文資訊直接跳到“error” Filters。如果全部流程跑完之後都沒有一個error的話,肯定會呼叫到內部服務。
請求轉發
當註解為@EnableZuulProxy時,測試轉發。通過訪問⽹閘道器的URL: http://localhost:8041/api-url/sc/order/1
可以正常地把請求的url轉發到http://localhost:8000/sc/order/2
預設路由規則
說明預設情況下,Zuul會代理理所有註冊到Eureka Server的微服務,並且Zuul的路由規則如下:
http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/**
會被轉發到serviceId對應的微服務。
http://localhost:8040/sc-zuul-first-provider/sc/order/2
閘道器的負載均衡
http://localhost:8040/sc-zuul-first-provider/sc/order/2
通過閘道器訪問服務提供者,負載均衡打出對應的日誌
為什麼要自研閘道器
1.閘道器配置實時生效,配置灰度,回滾等。
2.閘道器的效能,特別是防刷,限流,WAF等。
3.動態Filter,目前Zuul可以做到動態Filter,Filter配置下發,實時動態Filter。
4.對閘道器的監控,告警,流量調撥,閘道器叢集。
5.流程審計,增加Dsboard便捷的操作。
基於Netty的GW架構和Zuul的設計差不多,但是在細節方面比如Filter面的處理方式、基於Netty的高效能閘道器入口以及Request Context的上下文處理,都有不同的地方。
對外的GW最好的方式就是以輕量的client端引入到GW-server中。因為包括服務治理等一定是由服務治理內部的一些服務註冊與發現進行處理,client主要是做一個轉發或者一些簡單功能處理。
這樣做的好處就是,當閘道器和服務治理框架升級的時候,兩者之間的耦合就相當低了,閘道器隨著版本的迭代可以自行升級。至於內部的REST服務或RPC服務只是通過client端做一個薄薄的轉發,這樣就可以做到解耦。
Filter只需要做單一職責。如上圖所示,Filter有一個抽象的介面,當Filter啟動的時候會對資料進行一些處理。還有一個抽象的Filter主要是做一些每個Filter本身資料的CRUD。
Filter資料的CRUD
每個Fliter有自己的快取資料,快取資料的CRUD通過觀察者模式按key更新。
閘道器設計原則
1.每個Filter基於責任鏈,只做專一的一件事。
2.每個Filter有各自獨立的資料。
3.損耗效能的Filter順序往後放。
4.啟動讀取配置順序,先遠端,若遠端失敗,則讀取本地。
5.叢集閘道器,要注意資料的diff和灰度。
6. 儘量做到和服務治理框架解耦,易於接入,易於升級。
我今天的分享就到這裡,謝謝大家!