区分Maven Multi Module和Spring微服务？
我正在为下一个项目阅读Spring微服务。Tut说“架构风格主要应用程序分为一组称为微服务的子应用程序。一个大型应用程序分为多个协作过程。”。所以我们已经有了一个框架maven多模块在那里，我在我的经验中分离了项目。即使是。为什么我们需要微服务来分离一个项目？。请区分它。提前感谢…
共有1个答案
微服务架构中的每个服务都应该是隔离的，这意味着负责该服务的团队能够将持续部署付诸实践，而无需部署其他服务。在实践中，恕我直言，我认为我们可以使用我们最喜欢的构建工具（例如 maven 或 gradle）使用两种方法：
>
MonoProject：域、存储库、服务和控制器都在同一个项目中。
多项目：域、存储库、服务和控制器可以按不同的模块分组。即域和存储库在存储库模块中，服务在另一个同名模块中，控制器在前面模块中。
但是，无论您使用哪种方法，项目（单声道或多声道）都应该代表一个服务。
-
我有一个关于分解为微服务的问题。假设我们有 2 个微服务：用户和产品。假设我们现在需要向系统添加类别。更具体地说，产品具有一个或多个类别（例如，产品红色微型法拉利属于玩具和汽车类别），并且用户可以具有她喜欢的类别（例如玩具和鞋子）。现在，当我们检索产品的完整列表时，我们希望对它们进行排序，以便属于首选用户类别的产品位于顶部。 基本上有一个在微服务之间共享的概念（在本例中为类别）。如何在微架构环境中
-
此外，如果我删除尤里卡和Zuul，我如何使它在本地和非kubernetes环境中工作？
-
注解 注解 功能 @EnableEurekaServer 标注在 Application 类头，表示该服务为一个 服务注册发现服务器。 @EnableDiscoryClient 标注在 Application 类头，注册服务。 @@EnableFeignClients 标注在 Application 类头，发现服务。 @EnableZuulProxy 架构 服务注册与发现 1. 服务注册与发现 1
-
我想知道每种方法的利弊是什么。例如，在graphQL中包含所有内容似乎有点多余，因为我们将在每个服务中复制模式的部分。另一方面，我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗？我们都没有使用GraphQL的经验，所以这里是否有一些明显的利弊我们可能会遗漏？ 提前道谢！
-
更准确地说，在我看来，BDD测试应该验证业务逻辑，而且只验证业务逻辑。在许多框架中，BDD测试场景是由滑板持有者用DSL创建的。BDD测试倾向于收敛于排他性的“不了解基础设施”的实践。另一方面，集成测试应该验证解决方案是否与目标基础结构匹配（它们由DevOps完成？），并且只与基础结构匹配。当业务功能通过微服务“分布”时，您应该模拟BDD测试环境（应该是本地环境）中的几乎所有内容（infra和bu
-
对于一个项目，我想使用Spring Boot设置一个小型微服务场景，其中有一个向客户端公开REST和GraphQL的API网关、一个Eureka服务注册表和三个服务。由于性能原因，我希望API网关后面的所有服务都可以谈论gRPC，但同时仍然会公开一个额外的REST API。有没有一种干净的方法可以在相同的业务逻辑上实现这两种类型的接口？网关如何将客户端的HTTP请求代理到gRPC请求？