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，尤其是在受到良好控制的環境中，對大多數問題的響應仍然很好。