可能有多个网关以及如何仅在 JHipster 中创建带有前端的网关？
Multiple gateways possible and how to create gateway with frontend only in JHipster?
我正在开发 3 个微服务：
- 面向管理员的 Web 应用程序网关用于用户管理 (admin.com) 使用 mysql
- public 面向仅包含 vuejs 前端的 Web 应用程序网关 (public.com)
- 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。我是微服务的新手，对这方面很困惑。
I can easily generate (1) and (3) but how to generate (2) ?
在这里，我建议如果可能的话，将 UI INFRA 与服务基础设施完全隔离，这样可以轻松地发展 UI 基础设施并独立于后端进行设置。
因此，我们可以创建一个 webpack 或可部署的 VueJS 应用程序。可以通过多种不同方式部署或托管此可部署项。
本地开发，可以是节点服务器运行VueJS APP，消费micro-services部署在K8s
对于生产环境或测试环境，您可以利用云产品，举个例子 -
AWS Route 53 -> AWS CloudFront(CDN) -> AWS S3（部署 Webpack/JS 代码，它可以扩展到数十亿个请求，因为 (2) 只是静态 JS 代码，实际数据将由它使用对微服务后端的 XHR 调用来获取）
K8s 自动缩放器可以根据负载缩放每个微服务，产生并减少 pods。
How to solve above problem and are multiple gateways possible in the
same Microservices based app?
如果您正在尝试构建可扩展的架构，我建议使用第三方网关解决方案。
说 Kong/Mule 网关并在其上配置多个路由，然后可以重定向到各个端点。这样同一个网关解决方案可以满足多种需求。
AWS API 网关和 AZURE API 管理服务等基于云的解决方案也很有帮助。
Side question: As far as I know each instance of Microservice has its
own instance of db such as MySQL. I am new to Microservices and
confused about this aspect.
每个微服务可能有多个实例，比如每个服务有多个 kubernetes pods，它们应该指向相同的数据库端点。
然后数据库端点可以使用集群拓扑解析为单个或多个实例。
同样，集群依赖于高可用性要求。它可以像 ACTIVE-REPLICA 一样简单，其中 ACTIVE 是主要的，它可以故障转移到 REPLICA。
对于第(1)点，只是一个建议，请查看OIDC实现，例如Okta / KeyCloak，可以集群部署，UI。
或查看 OIDC 的开源参考实现 MITREiD，它为您提供可自定义的 UI 管理任务，可用于跨 UI/backend 服务实施 RBAC。
我从你的描述中看到架构实现的方式可以是 -
1.DNS 路由器，根据主机名路由到 endpoint/URL。
2.If有人访问UI应用程序（public.com），静态网站（基于VueJS的网络应用程序）得到
从 CDN 提供。实际代码可以在托管服务器或 AWS S3 上，这是
如今，价格低廉、可扩展性强且广泛用于网站服务。
3.If 应用程序需要身份验证，它可以检查 session 令牌，比如 JWT。如果不是
present从User management service获取，如图，也可以是
OIDC 实施。用户需要在场外提供凭据。
4.If 用户执行需要后端数据或表单提交的操作，VueJS 应用程序
向所需的微服务发送 XHR 请求以及 session 令牌。
5.The 对微服务的调用通过 DNS 服务路由到您的 API 网关，或者我们可以
直接调用 API 网关端点。
6.API 网关应该有解析 JWT 的逻辑，检查其有效性和真实性
并提取所需的 SCOPES，可以将其作为自定义 headers 传递给 micro-
服务。 API 网关可以咨询用户管理服务来帮助处理用户数据
来自用户数据存储。这些自定义 headers 可以用于微服务的 RBAC，如果
必需的。在这里，想法是将 auth 卸载到 API 网关，这样微服务就可以进化
很容易，而不必担心横切问题。并且只有经过身份验证的调用
进入你的私人网络。
7.API 网关映射到不同的负载均衡器，这些负载均衡器又可以指向 K8s
入口服务。这将传递给所需的服务，最终到达您的
作为您的 micro-service.
的实例之一的代码 运行
8.The 微服务可以读写数据库。假设如果负载在高峰时间增加，则
autoscaler 可以向上扩展，微服务 pods.
- 同样，如果管理员想要访问管理应用程序，他会看到管理员 UI，这
连接到用户管理服务和相应的用户数据存储
网关和负载均衡器可以用不同的方式编排
- 典型的例子如下-
假设部署在云上的服务可以遵循以下模式，其中自定义域映射到 API 用户请求进入的网关，然后路由到后端的相应集成，这通常是 cluster/target 组您的服务。
另一种与云无关的模式可以是，部署 api 网关解决方案，例如 Kong，作为一个单独的容器，比如 public，然后微服务可以驻留在其他私有容器中。
在这里，想法是pt 专用网络中的任何业务关键逻辑，并使其仅允许允许的服务访问。这些服务反过来可以 public 访问。因此，我们可以减少安全漏洞的表面积，从而减少攻击向量。
如果您使用 k8s 部署 api 网关，另一种解决方案可能是将 API 网关放在 k8s ingress 后面，让 k8s Ingress 将请求从 public.com 路由到网关服务，对于 admin.com，它用于 api 网关本身。这个解决方案应该可以解决(2).
我正在开发 3 个微服务：
- 面向管理员的 Web 应用程序网关用于用户管理 (admin.com) 使用 mysql
- public 面向仅包含 vuejs 前端的 Web 应用程序网关 (public.com)
- 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。我是微服务的新手，对这方面很困惑。
I can easily generate (1) and (3) but how to generate (2) ?
在这里，我建议如果可能的话，将 UI INFRA 与服务基础设施完全隔离，这样可以轻松地发展 UI 基础设施并独立于后端进行设置。 因此，我们可以创建一个 webpack 或可部署的 VueJS 应用程序。可以通过多种不同方式部署或托管此可部署项。
本地开发，可以是节点服务器运行VueJS APP，消费micro-services部署在K8s
对于生产环境或测试环境，您可以利用云产品，举个例子 -
AWS Route 53 -> AWS CloudFront(CDN) -> AWS S3（部署 Webpack/JS 代码，它可以扩展到数十亿个请求，因为 (2) 只是静态 JS 代码，实际数据将由它使用对微服务后端的 XHR 调用来获取）
K8s 自动缩放器可以根据负载缩放每个微服务，产生并减少 pods。
How to solve above problem and are multiple gateways possible in the same Microservices based app?
如果您正在尝试构建可扩展的架构，我建议使用第三方网关解决方案。
说 Kong/Mule 网关并在其上配置多个路由，然后可以重定向到各个端点。这样同一个网关解决方案可以满足多种需求。
AWS API 网关和 AZURE API 管理服务等基于云的解决方案也很有帮助。
Side question: As far as I know each instance of Microservice has its own instance of db such as MySQL. I am new to Microservices and confused about this aspect.
每个微服务可能有多个实例，比如每个服务有多个 kubernetes pods，它们应该指向相同的数据库端点。
然后数据库端点可以使用集群拓扑解析为单个或多个实例。 同样，集群依赖于高可用性要求。它可以像 ACTIVE-REPLICA 一样简单，其中 ACTIVE 是主要的，它可以故障转移到 REPLICA。
对于第(1)点，只是一个建议，请查看OIDC实现，例如Okta / KeyCloak，可以集群部署，UI。
或查看 OIDC 的开源参考实现 MITREiD，它为您提供可自定义的 UI 管理任务，可用于跨 UI/backend 服务实施 RBAC。
我从你的描述中看到架构实现的方式可以是 -
1.DNS 路由器，根据主机名路由到 endpoint/URL。
2.If有人访问UI应用程序（public.com），静态网站（基于VueJS的网络应用程序）得到 从 CDN 提供。实际代码可以在托管服务器或 AWS S3 上，这是 如今，价格低廉、可扩展性强且广泛用于网站服务。
3.If 应用程序需要身份验证，它可以检查 session 令牌，比如 JWT。如果不是 present从User management service获取，如图，也可以是 OIDC 实施。用户需要在场外提供凭据。
4.If 用户执行需要后端数据或表单提交的操作，VueJS 应用程序 向所需的微服务发送 XHR 请求以及 session 令牌。
5.The 对微服务的调用通过 DNS 服务路由到您的 API 网关，或者我们可以 直接调用 API 网关端点。
6.API 网关应该有解析 JWT 的逻辑，检查其有效性和真实性 并提取所需的 SCOPES，可以将其作为自定义 headers 传递给 micro- 服务。 API 网关可以咨询用户管理服务来帮助处理用户数据 来自用户数据存储。这些自定义 headers 可以用于微服务的 RBAC，如果 必需的。在这里，想法是将 auth 卸载到 API 网关，这样微服务就可以进化 很容易，而不必担心横切问题。并且只有经过身份验证的调用 进入你的私人网络。
7.API 网关映射到不同的负载均衡器，这些负载均衡器又可以指向 K8s 入口服务。这将传递给所需的服务，最终到达您的 作为您的 micro-service.
的实例之一的代码 运行8.The 微服务可以读写数据库。假设如果负载在高峰时间增加，则 autoscaler 可以向上扩展，微服务 pods.
- 同样，如果管理员想要访问管理应用程序，他会看到管理员 UI，这 连接到用户管理服务和相应的用户数据存储
网关和负载均衡器可以用不同的方式编排
- 典型的例子如下-
假设部署在云上的服务可以遵循以下模式，其中自定义域映射到 API 用户请求进入的网关，然后路由到后端的相应集成，这通常是 cluster/target 组您的服务。
另一种与云无关的模式可以是，部署 api 网关解决方案，例如 Kong，作为一个单独的容器，比如 public，然后微服务可以驻留在其他私有容器中。
在这里，想法是pt 专用网络中的任何业务关键逻辑，并使其仅允许允许的服务访问。这些服务反过来可以 public 访问。因此，我们可以减少安全漏洞的表面积，从而减少攻击向量。
如果您使用 k8s 部署 api 网关，另一种解决方案可能是将 API 网关放在 k8s ingress 后面，让 k8s Ingress 将请求从 public.com 路由到网关服务，对于 admin.com，它用于 api 网关本身。这个解决方案应该可以解决(2).