多个网关是可能的，如何创建仅在JHipster中使用前端的网关？

Question

我正在开发3项微型服务：

1. 使用mysql面向web应用程序的用户管理网关(admin.com)
2. 面向公共的web应用程序网关，只包含vuejs前端(public.com)
3. REST微服务，包含使用Redis和Cassandra的核心应用程序

我可以很容易地生成(1)和(3)，但是如何生成(2)？

我尝试使用下面的命令生成(2)

跳过服务器蓝图vuejs

但是jhipster docs说，跳过服务器选项对于Microservice来说没有意义，而且jhipster也不会将上面的内容配置为网关。

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

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

该应用程序将使用Kubernetes部署。

附带问题：

当创建多个实例(2)或(3)以每秒处理数百万次请求时，分布式的Redis和Cassandra集群将被(3)的所有实例共享？据我所知，每个Microservice实例都有它自己的db实例，如MySQL。我对Microservices并不熟悉，对此我感到困惑。

Answer 1

我可以很容易地生成(1)和(3)，但是如何生成(2)？

在这里，我将建议，如果可能的话，将UI infra与下面的服务完全分离开来，这样就可以很容易地独立于后端来发展UI INFRA和设置。因此，我们可以创建webpack或可部署的VueJS应用程序。可以通过多种不同的方式部署或托管此可部署性。

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

对于prod或test env，您可以利用云产品，例如-

AWS路由53 -> AWS CloudFront-> AWS S3 (Webpack/ JS代码被部署到其中，它可以扩展到数十亿个请求，因为(2)只是静态JS代码，它将使用XHR调用微服务后端获取实际数据)。

K8s自动分词器可以根据负载、产卵和减少豆荚的数量来处理每个微服务的缩放。

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

如果您想构建一个可伸缩的体系结构，我建议您使用第三方网关解决方案。

假设Kong/Mule网关并在其上配置了多个路由，然后这些路由可以重定向到相应的端点。这样，相同的网关解决方案可以满足多种需求。

基于云的解决方案，如和AZURE管理服务也可以提供帮助。

附带问题:据我所知，每个Microservice实例都有它自己的db实例，如MySQL。我对Microservices并不熟悉，对此我感到困惑。

每个微服务可能有多个实例，比如每个服务的多个kubernetes荚，并且它们应该指向相同的DB端点。

然后，DB端点可以使用群集拓扑解析为单个或多个实例。同样，集群依赖于高可用性需求。它可以和活动副本一样简单，其中ACTIVE是主要的，它可以故障转移到副本。

关于(1)点，只是一个建议，请检查OIDC实现，例如Okta / KeyCloak，它可以作为集群部署并附带UI。

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

我从你的想法中看到架构的实现，可以是-

​

​

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

2.如果有人访问UI应用程序(public.com)，则静态网站(基于VueJS的web应用程序)将从CDN获得服务。实际的代码可以是在托管服务器或AWS S3上，这是一个廉价，高度可扩展和广泛用于服务网站的S3。

3.如果应用程序需要身份验证，它可以检查会话令牌，比如JWT。如果它不是从用户管理服务(如图中所示)获得的，它也可以是一个OIDC实现。用户需要临时提供这些凭据。

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

5.对微服务的调用通过DNS服务路由到您的API网关，或者直接调用API网关端点。

6.API网关应该具有解决JWT的逻辑，检查其有效性和真实性，并提取所需的范围，这些范围可以作为自定义标头传递给微服务。API网关可以参考用户管理服务来帮助用户数据存储。如果需要，这些自定义报头可以用于RBAC使用的微服务。在这里，想法是将auth卸载到API网关，这样微服务就可以很容易地发展，而不必担心横切关注点。只有经过认证的电话才能进入你的专用网络。

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

8.微服务可以读写数据库。如果负荷在高峰时间增加，自动分配器可以放大，微服务舱。

1. 就像wise一样，如果管理员想访问管理应用程序，他就会看到admin，它连接到用户管理服务和相应的用户数据存储。

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

• 典型的例子如下-

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

​

​

另一种与云无关的模式可以是部署api网关解决方案，如Kong，作为单独的容器(例如公共容器)，然后微服务可以驻留在其他私有容器中。

​

​

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

Answer 2

如果使用k8s部署api网关，另一种解决方案可能是将API网关置于k8s入口之后，让k8s将请求从public.com路由到网关服务，而对于admin.com，则是针对api网关本身。这个解决方案应该能够解决(2)。