JHipster如何生成Istio架构的应用

18-11-27 banq
                   

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的名称

最后,我们获得了一个等价的架构:

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生成更合适的架构。架构看起来像这样:

外部调用直接路由到正确的微服务(同时受益于断路和重试),并且服务间调用需要执行简单的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,尤其是在受到良好控制的环境中,对大多数问题的响应仍然很好。