cloud - 可能有多个网关以及如何仅在 JHipster 中使用前端创建网关？

Question

我正在开发 3 个微服务：

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

我可以轻松生成 (1) 和 (3) 但如何生成 (2) ？

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

jhipster --skip-server --blueprints vuejs

但是 jhipster 文档说 skip-server 选项对微服务没有意义，而且 jhipster 也不会在上面配置为网关。

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

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

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

附带问题：

当创建 (2) 或 (3) 的多个实例以每秒处理数百万个请求时，Redis 和 Cassandra 的分布式集群将由 (3) 的所有实例共享？据我所知，每个微服务实例都有自己的数据库实例，例如 MySQL。我是微服务的新手，对这方面感到困惑。

标签： cloudmicroservicesjhipster

Answer 1

我可以轻松生成 (1) 和 (3) 但如何生成 (2) ？

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

对于本地开发，可以是运行VueJS APP的节点服务器，消费部署在K8s上的微服务

对于 prod 或 test env，您可以利用云产品，仅作为示例 -

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

K8s 自动缩放器可以根据负载、生成和减少 pod 来处理每个微服务的缩放。

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

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

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

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

附带问题：据我所知，每个微服务实例都有自己的数据库实例，例如 MySQL。我是微服务的新手，对这方面感到困惑。

每个微服务可能有多个实例，例如每个服务的多个 kubernetes pod，它们应该指向同一个 DB 端点。

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

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

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

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

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

2.如果有人访问 UI 应用程序（public.com），则静态网站（基于 VueJS 的 Web 应用程序）从 CDN 获得服务。实际代码可以在托管服务器或 AWS S3 上，后者价格便宜、高度可扩展且广泛用于当今的网站服务。

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

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

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

6.API网关应该有逻辑来解析JWT，检查其有效性和真实性并提取所需的SCOPES，可以作为自定义标头传递给微服务。API 网关可以咨询用户管理服务以帮助处理来自用户数据存储的用户数据。如果需要，这些自定义标头可用于带有微服务的 RBAC。在这里，想法是将身份验证卸载到 API 网关，因此微服务可以轻松发展，而无需过多担心横切问题。只有经过身份验证的呼叫才能进入您的专用网络。

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

8.然后微服务可以对数据库进行读写。假设负载在高峰时间增加，自动缩放器可以扩展微服务 pod。

9. 同样，如果管理员想要访问管理应用程序，他会看到管理 UI，该 UI 连接到用户管理服务和相应的用户数据存储

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

• 典型示例如下 -

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

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

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