转载

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：
- 特别允许将HTTP请求路由到基于contextpath网址生成的所有微服务：它基于插入Eureka的Zuul（和Ribbon）来动态发现可用服务的位置
- 它还托管Web应用程序（Angular或React）和一些服务，例如用户存储库（取决于生成选项）
最终，每个微服务都可以从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的名称

最后，我们获得了一个等价的架构：

JHipster如何生成Istio架构的应用

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（ @saturnism ）是JHipster的Istio工作的发起者，同时试图确保为Istio生成更合适的架构。架构看起来像这样：

JHipster如何生成Istio架构的应用

外部调用直接路由到正确的微服务（同时受益于断路和重试），并且服务间调用需要执行简单的http客户端Istio代理的服务。如图中绿色部分。感兴趣的读者阅读Envoy和Hystrix的比较

但是，这种架构有两个主要影响：

JHipster网关不再作为应用程序网关（尽管它的名字）
删除Discovery服务已经完全放弃了JHipster Registry，以及Spring Cloud Config。

作为应用程序网关的JHipster网关在微服务架构中可以发挥多种作用：调用微服务的路由只是这些角色中的一种。根据需要，应用程序网关必须能够：

过滤一些标题
管理CORS标头
管理限制（参见JHipster提供的 RateLimitingFilter 的实现......）
管理身份验证上下文要注意：JHipster生成的身份验证模式“JWT”在此处运行良好，但其他模式（其中UAA保持无状态）将需要网关。更强大的JWT身份验证（特别是刷新）的集成通常还需要一个网关。
应用跨安全规则

可以采用不同的策略以不同的方式处理所有这些方面，但应用程序网关仍然是集中处理它们的最简单方法。

理想的架构

免责声明：目前，JHipster还不能直接生成这个架构。从下面可以看出，这可能涉及对网关生成的代码的特定更改，这只会对此特定情况有意义。

JHipster如何生成Istio架构的应用

这里的目标是将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，尤其是在受到良好控制的环境中，对大多数问题的响应仍然很好。

原文 https://www.jdon.com/50849

正文到此结束