如何在PCF中为微服务配置API网关、服务发现？
当我们部署到pcf时，Netflix eureka、zuul、ribbon、feign spring cloud配置不有用？（如果是，在pcf中有哪些可选方案以及如何配置它们？）
由于构建微服务遵循CI/CD方法，开发人员在推送代码之前如何验证其微服务的工作，因为我们在生产PCF中没有使用eureka、zuul、ribbon、feign。（如何在developer Machine中模拟pcf环境？）。
共有1个答案
@Bean
public Cloud cloud() {
return new CloudFactory().getCloud();
}
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD
-
我有一个使用ZuulNetflix作为API网关的应用程序，架构如下： 该架构运行良好，使用浏览器和邮递员我可以从微服务（服务1、2和3）访问不同的RESTendpoint。但是当我试图在我的前端Web应用程序（AngularJS WebApp）中使用它时，它在chrome控制台中给我带来了以下错误。 如果我设置注释，则通过自己的地址和端口使用服务将有效。但是当通过网关访问它时，restendpo
-
在微服务架构中，建议： > 客户端应用程序到API网关的通信应该是同步的（就像http上的REST一样）。 API网关到微服务的通信也应该是同步的 但是服务到服务的通信应该是异步的。 您应该尽可能遵循的另一个规则是，只使用内部服务之间的异步消息传递，只使用从客户端应用程序到前端服务（API网关加上第一级微服务）的同步通信（如HTTP）。 现在，如果我理解正确的话，当用户向API gateway请求
-
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处，比如：负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是，我应该在网关层还是在每个微服务endpoint单独实现授权？例如，在网关上验证用户，并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的，并且节省了处理时间。然而，授权逻辑实际上是单个服务