JHipster如何生成Istio架構的應用
JHipster目前提供了一個選項,用於生成服務網格Istio架構的應用。
快速介紹Istio
Istio是與Kubernetes完全整合的服務網格,它的作用是管理微服務架構中服務之間的所有通訊。
- 不同服務例項之間的智慧負載均衡(包括斷路和重試)
- 藍色/綠色部署
- 兩個版本的服務之間的金絲雀測試或A / B測試
- 流量和服務的監測/可觀測性
- 應用程式間呼叫安全性
這篇文章的重點是要了解它如何能夠取代大部分Netflix堆疊工具,例如:Ribbon,Hystrix,Zuul的一部分,並免除了Eureka的服務。直接受益於Kubernetes平臺的發現服務。
JHipster如何生成經典微服務架構
JHipster嚴重依賴Spring Cloud,尤其是Spring Cloud Netflix:
- JHipster Registry伺服器:
- Eureka伺服器(服務登錄檔)
- Spring Cloud Config伺服器(集中應用程式配置)
- 每個微服務例項
- 從Spring Cloud集中配置檢索
- 使用Eureka註冊(通過其預設IP)。
- 閘道器JHipster:
- 最終,每個微服務都可以從Eureka和Ribbon中受益,以發現其他微服務
- Hystrix確保這些呼叫的穩健性(GW-> MS和MS-> MS):特別確保斷路功能
Spring Cloud與Istio共存架構
Istio的操作原理基於在每個Pod內注入代理(在這種情況下,此代理是Envoy)。(然後每個Pod將託管指定微服務及其相同位置的Envoy代理例項)。每個Pod上的傳入和傳出網路連線集將路由到該代理(通過iptable規則),然後該存根可以獨立於託管應用程式應用呼叫和路由策略。
這部分是與JHipster的經典架構競爭,因為負載平衡 服務發現等是由Spring Cloud生態系統管理。但是,當要求在Istio上部署時,JHipster生成器必須足夠智慧實現兩種機制共存:
主要變動是修改Eureka中微服務的註冊模式:
- 生成的Kubernetes描述符設定環境變數以禁用Eureka中的IP註冊,並將其替換為名稱記錄。
- 此名稱通常用於Eureka託管服務的主機名。這裡將填充與微服務相關的Istio VirtualService的名稱
最後,我們獲得了一個等價的架構:
Envoy代理在呼叫時顯示為綠色,微服務的每個例項向Eureka註冊具有相同主機名,Envoy代理將決定將http://productservice/路由到微服務的哪個副本。
對於服務間呼叫(架構中的Cart到Product),它是相同的:
如果開發人員使用JHipster提供的標準機制:Eureka和Ribbon將付諸實施,但是代理Istio將在負載平衡上有最終決定權,因此,使用單個Http客戶端將具有相同的整體效果。
然而,應該注意,Ribbon和Hystrix的存在可能會產生邊緣效應:
- Ribbon的重試機制和Istio的重試機制將會疊加起來:最好只啟用兩種機制中的一種,才能進行更多控制(預設情況下,JHipster不會啟用重試功能區,但重試生成的描述符中啟用了Istio)
- Hystrix和Istio會競爭,將Hystrix超時放在Istio超時之前觸發。
另一種架構“Istio-native”
谷歌的Ray Tsang( ofollow,noindex" target="_blank">@saturnism )是JHipster的Istio工作的發起者,同時試圖確保為Istio生成更合適的架構。架構看起來像這樣:
外部呼叫直接路由到正確的微服務(同時受益於斷路和重試),並且服務間呼叫需要執行簡單的http客戶端Istio代理的服務。如圖中綠色部分。感興趣的讀者閱讀Envoy和Hystrix的 比較
但是,這種架構有兩個主要影響:
- JHipster閘道器不再作為應用程式閘道器(儘管它的名字)
- 刪除Discovery服務已經完全放棄了JHipster Registry,以及Spring Cloud Config。
作為應用程式閘道器的JHipster閘道器在微服務架構中可以發揮多種作用:呼叫微服務的路由只是這些角色中的一種。根據需要,應用程式閘道器必須能夠:
- 過濾一些標題
- 管理CORS標頭
- 管理限制(參見JHipster提供的 RateLimitingFilter 的實現......)
- 管理身份驗證上下文要注意:JHipster生成的身份驗證模式“JWT”在此處執行良好,但其他模式(其中UAA保持無狀態)將需要閘道器。更強大的JWT身份驗證(特別是重新整理)的整合通常還需要一個閘道器。
- 應用跨安全規則
可以採用不同的策略以不同的方式處理所有這些方面,但應用程式閘道器仍然是集中處理它們的最簡單方法。
理想的架構
免責宣告:目前,JHipster還不能直接生成這個架構。從下面可以看出,這可能涉及對閘道器生成的程式碼的特定更改,這隻會對此特定情況有意義。
這裡的目標是將JHipster閘道器放在微服務之前,並可能將Spring Cloud Config保留在註冊器中,閘道器保留JHipster Zuul,能提供自定義過濾器功能如 RateLimitingFilter 。但是在Zuul伺服器的配置中不會整合Hystrix(或Ribbon),因為這兩者與Istio競爭。如果不需要過濾器,可以簡單地刪除Zuul。
結論
JHipster的微服務架構基於Spring Cloud,特別是Netflix堆疊(雖然也可以使用Consul和Traefik等替代品),這是有道理的。因此,在Istio上應用的這種架構顯示出一些侷限性是完全正常的。
很難取悅所有人,JHipster已經提供了非常豐富的一種組合,因此維護起來很複雜。
最後但並非最不重要的是,Istio的1.0版本於2018年7月底釋出。這是一項非常有前景的技術,但仍然很年輕,鮮為人知。Spring Cloud,尤其是在受到良好控制的環境中,對大多數問題的響應仍然很好。