可能有多个网关，如何在JHipster中创建只有前端的网关？

Question

我正在开发3个微服务：

1. 面向管理员的web应用网关，用于使用mysql进行用户管理（admin.com）
2. 面向公众的web应用网关，仅包含vuejs前端（public.com）
3. REST API微服务，包含使用Redis和Cassandra的核心应用程序

我可以轻松生成（1）和（3），但如何生成（2）？

我尝试使用以下命令生成（2）

jhipster--跳过服务器--蓝图vuejs

但jhipster docs表示，跳过服务器选项对微服务没有意义，而且jhipster不会将上述配置为网关。

https://www.jhipster.tech/separating-front-end-and-api/

如何解决上述问题，在同一个基于微服务的应用程序中是否可以有多个网关？

该应用程序将使用库伯内特斯部署。

附带问题：

当创建（2）或（3）的多个实例以每秒处理数百万个请求时，Redis和Cassandra的分布式集群将被（3）的所有实例共享？据我所知，Microservice的每个实例都有自己的db实例，例如MySQL。我对微服务不熟悉，对这方面感到困惑。

Answer 1

如果使用k8s部署api网关，另一种解决方案可能是将api网关置于k8s入口之后，让k8s入口路由来自公共的请求。com到网关服务，以及用于管理。com，它是针对api网关本身的。此解决方案应能够解决（2）。

Answer 2

我可以轻松生成（1）和（3），但如何生成（2）？

在这里，我建议如果可能的话，将UIINFRA完全与基础服务分离，这使得独立于后端UI基础设施和设置变得容易。因此，我们可以在VueJS应用程序之外创建一个webpack或可部署的。这个可部署的可以以多种不同的方式部署或托管。

对于本地开发，它可以是运行VueJS应用程序的节点服务器，使用部署在K8s上的微服务

对于prod或test env，您可以利用云产品，仅举个例子-

AWS Route 53-

K8s autoscaler可以根据负载、繁殖和减少POD来扩展每个微服务。

如何解决上述问题，在同一个基于微服务的应用程序中是否可以有多个网关？

如果您试图构建可扩展的架构，我建议使用第三方网关解决方案。

假设Kong/Mule Gateway并在其上配置了多条路由，然后可以重定向到各自的endpoint。这样，同一网关解决方案可以满足多种需求。

AWS API Gateway和AZURE API管理服务等基于云的解决方案也很有帮助。

附带问题：据我所知，Microservice的每个实例都有自己的db实例，比如MySQL。我不熟悉微服务，对这方面感到困惑。

每个微服务可能有多个实例，比如每个服务都有多个kubernetes吊舱，它们应该指向同一个DBendpoint。

然后，DBendpoint可以使用集群拓扑解析为单个或多个实例。同样，集群取决于高可用性要求。它可以像ACTIVE-REPLICA一样简单，其中ACTIVE-REPLICA是主要的，它可以故障转移到REPLICA。

对于第（1）点，只是一个建议，请检查OIDC实现，例如Okta/KeyCloak，它可以部署为集群并带有UI。

或者看看OIDC的开源参考实现MITREiD，它为管理任务提供了可定制的UI，可用于跨UI/后端服务实现RBAC。

我从您的描述中看到架构实现的方式可以是-

1.DNS路由器，根据主机名路由到endpoint/URL。

2、如果有人访问UI app（public.com），静态网站（基于VueJS的web app）将从CDN获得服务。实际的代码可以在托管服务器或AWS S3上，这是一种廉价、高度可扩展的服务器，目前广泛用于服务网站。

如果应用程序需要身份验证，它可以检查会话令牌，比如JWT。如果它不存在，请从用户管理服务获取，如图所示，它也可以是OIDC实现。用户需要提供thr凭证。

4.如果用户执行需要后端数据或表单提交的操作，VueJS应用程序会向所需的微服务发送XHR请求以及会话令牌。

对微服务的调用通过DNS服务路由到您的API网关，也可以直接调用API网关endpoint。

API网关应该有逻辑来解析JWT，检查其有效性和真实性，并提取所需的作用域，这些作用域可以作为自定义头传递给微服务。API网关可以咨询用户管理服务，以帮助从用户数据存储中获取用户数据。如果需要，这些自定义头可以用于带有microservice的RBAC。这里的想法是将身份验证卸载到API网关，这样微服务就可以很容易地发展，而不必担心交叉问题。只有经过身份验证的呼叫才能进入您的专用网络。

7. API网关映射到不同的负载均衡器，这些负载均衡器又可以指向K8s Inete服务。这将传递给所需的服务，这些服务最终会到达作为微服务实例运行的一个pod中的代码。

然后，微服务可以读写数据库。比如说，如果负载在峰值时间增加，自动缩放器可以放大，微服务吊舱也可以放大。

网关和负载平衡器可以以不同的方式进行编排

• 典型示例如下-

假设部署在云上的服务可以遵循以下模式，其中自定义域映射到用户请求进入的API网关，然后路由到后端的各个集成，后端通常是服务集群/目标组的负载平衡器。

另一种云不可知的模式是，将api网关解决方案（如Kong）部署为一个单独的容器（如公共容器），然后微服务可以驻留在其他私有容器中。

这里的想法是将任何业务关键型逻辑放在专用网络中，并使其只能由允许的服务访问。这些服务反过来可以公开访问。因此，我们可以减少安全漏洞的表面积，从而减少攻击向量。