问题标签 [microservices]

I m actually studying Microservice architecture pattern and it seems that the API Gateway pattern uses the Discovery pattern, but with REST API endpoints.

Can anybody explain me how it works for example if my API Gateway is NodeJS based and my REST APIs are Java written ?

I dont really know how can I implement this pattern and I dont find any code or schema to help me understand a bit more.

Thanks for advance

我实际上正在研究微服务，但我遇到了一个问题。

语境

我正在开发两个微服务：

• 用户管理，基于 Spring，带有 MySQL 数据库
• 规划管理，基于 ASP.NET 的 SQL Server 数据库。此服务的唯一访问点是列出一些 RESTFUL 端点的 API，例如/planning/{day}/{userId} or /planning/{startDate}/{endDate}/{idUser}
• 计费管理，基于 MongoDB 的 Node.Js。

问题

1. 我该怎么做才能只允许通过用户服务访问计划信息而不耦合这两个服务？知道以后可以从其他地方访问计划服务，但不是现在。

2. 如何从 MySQL 数据库中的用户对应的计费服务中访问计费信息？我知道微服务没有耦合，这一点让我很生气，因为它必须以某种方式耦合，不是吗？就像idUser在计费中引用？否则，我怎么知道我应该从我的 API 中公开哪些账单？更准确地说，微服务如何在它们之间进行通信，而不是耦合？

3. 如何在不将身份验证请求从其他服务复制到身份验证服务的情况下创建身份验证？

我有点困惑。我在一家年轻的银行公司工作，我们决定实施 DDD 架构来打破复杂性。

所以，这是我的问题（它遵循团队中某人提出的设计建议）。假设我们有 3 个不同的域。D1、D2、D3，公开域（Web）服务。每个域都操作依赖于相同表的强类型业务实体。在这些领域之前，我们希望微服务以集中的方式保证表中持久化的数据是一致的。D1、D2 和 D3 要求微服务将符合特定规则的数据持久化。我们希望微服务充当表的 CRUD 代理。微服务为 D1、D2 和 D3 域提供特定的 DTO，将表混淆为 D1、D2、D3。

这种方法听起来不错吗？您会考虑在 DDD 架构中使用微服务来管理 1+ 个域的 CRUD 和数据一致性吗？使用微服务“CRUDing”和验证数据是否会破坏有界上下文？如果有的话，在 DDD 架构中处理微服务的最佳实践是什么？

非常感谢您的贡献，

[编辑]

以下文章帮助我完善了我的想法：http ://martinfowler.com/bliki/MicroservicePremium.html

微服务在单体系统无法维护的复杂情况下很有用。它们不是前期设计实施的良好候选者。另一方面，DDD 试图在项目一开始就解决复杂性。成功的 DDD 不应该满足微服务实现。

我很难为微服务架构选择一个体面/安全的身份验证策略。我在该主题上找到的唯一 SO 帖子是：微服务架构中的单点登录

我的想法是在每项服务（例如身份验证、消息传递、通知、配置文件等）中对每个用户都有一个唯一的引用（在逻辑上然后是他的user_id），并且如果登录则可以获得当前用户的可能性id。

根据我的研究，我发现有两种可能的策略：

1. 共享架构

在此策略中，身份验证应用程序是其他服务中的一项。但是每个服务都必须能够进行转换session_id=>user_id所以它必须非常简单。这就是我想到 Redis 的原因，它可以存储 key:value session_id:user_id。

2.防火墙架构

在此策略中，会话存储并不重要，因为它仅由身份验证应用程序处理。然后user_id可以转发到其他服务。我想到了 Rails + Devise（+ Redis 或 mem-cached，或 cookie 存储等），但有很多可能性。唯一重要的是服务 X 永远不需要对用户进行身份验证。

这两种解决方案在以下方面如何比较：

• 安全
• 稳健性
• 可扩展性
• 使用方便

或者你可能会建议我在这里没有提到的另一个解决方案？

我更喜欢解决方案＃1，但没有找到太多默认实现来保护我，因为我正朝着正确的方向前进。

我实际上正在阅读有关微服务架构的文章，但是，似乎他们正在以最简单的方式处理事情，而没有深入解释。

为了向您解释我的问题，我将向您展示我的实际小架构：

所以，这就是我想要使用的。在技​​术上做任何事情之前，我需要更多的理论信息。

我的域名说明

我有一些基于移动和浏览器的客户，他们能够在应用程序上连接自己，获取他们的用户信息，并能够咨询他们所购买商品的账单信息。

在单体应用程序中，我将使用以下架构： - 带有移动/Angular-Ember 的表示层 - 带有 REST API 的业务层，前面带有 NGINX - 带有标准 MySQL 数据库的 DAL - 可伸缩性仅适用于 X 轴

在这种情况下，我想使用微服务架构，因为它是“域可扩展的”并且非常灵活（当然要了解更多关于它的知识）。

在架构上，在每个服务中，相关 API 都公开了唯一的 HTTP URL。

问题

a/在（1）flux 中，“mobile”在http://myDomain.or/auth上发送一个 http 请求。

在我看来，APIGateway 能够询问标准服务注册中心（Eureka、ZooKeeper 或其他东西）是否能够找到 AuthSrv 是否可访问并可以检索他的网络地址。然后 ApiGateway 可以请求 AuthSrv 并响应服务器

这是让它工作的好方法吗？处理 X 机器访问数据时是否存在延迟问题？

b/通量（2）咨询服务注册表。服务注册表如何理解 /auth 上的每个请求，甚至是 /auth/other 等子 url 上的每个请求（如果它被暴露）都与此地址 ip:port 上的此服务相关？

c/通量 (3) 显示服务注册表具有可用的 AuthSrv。(3 bis) 显示另一个：没有可用的 AuthSrv。在一个小的应用程序中，我们可以承认我们失去了一些责任，但在一个大系统中，数百个服务链接，我们如何处理服务不足？

d/在另一篇文章中，我在询问如何存储计费信息，因为它与用户、来自另一个服务和另一个数据库有关。

在标准架构中，我将拥有：

在微服务架构中，有人建议使用：

这是处理“服务数据共享”而不是耦合服务的最佳方式吗？

e/在这种特定情况下，我什么时候应该更喜欢使用 AMQP 协议而不是 HTTP 协议？

感谢提前

我想开始将我的应用程序拆分为微服务。我的第一个任务是删除我们每个应用程序中重复的功能。诸如电子邮件发送、导出、搜索索引等之类的事情——在每个应用程序中重复相同或相似代码的事情。

我只是觉得有点不知所措，很难开始。我知道微服务的目的是您可以为工作选择正确的语言，但就我们目前的目的而言，我假设 .NET 将是我将在其中构建所有内容的主要框架。

基本上，首先，我想创建一个微服务，它只发送电子邮件，我们所有的应用程序都可以与之交谈并告诉他们发送他们需要的电子邮件。我的想法是电子邮件发件人具有发送电子邮件的逻辑，但每个应用程序都需要告诉它收件人、正文等。

我正在努力解决以下问题：

• 应用程序应该使用什么协议来与该服务通信？基于 HTTP 的 REST？如果是这种情况，电子邮件发送微服务是否有效地只是一个 Web API 2 应用程序（如果我要构建一个 REST api，这就是我个人会使用的）。

• 如果我要使用 REST，从后端进行安静调用的最佳方式是什么？我们系统中的大多数电子邮件现在都是通过后端代码发送的。我已经看到了 RestSharp 这个名字，这通常被认为是最好的方法吗？

• 未来的规划，我认为拥有某种了解所有服务的网关将是有益的，这样每个应用程序只需要知道这个网关，然后网关就可以与它需要的任何服务进行对话。这只是应用程序和微服务之间的另一个 REST API 吗？

抱歉所有的问题，只是在所有这些东西（和一般的建筑）上开始，以便在我的工作场所加紧工作，目前有点让我头晕目眩。

我已经阅读了许多有关使用 Spring Boot 和 RESTful 服务的指南，其中许多包含有关运行单元测试的信息，最值得注意的是“使用 Spring Boot 构建应用程序”。但是，我还没有看到任何示例说明如何对使用/依赖于其他 Spring Boot 应用程序的 Spring Boot 应用程序进行单元测试，这在云微服务架构中很常见。因此，例如，我们有以下 Spring Boot 服务：

服务中介、适配器 1、适配器 2

ServiceMediator 调用 Adapter1 或 Adapter2，具体取决于输入。

有没有办法在 Spring JUnit 测试中启动和测试 ServiceMediator 之前启动 Spring Boot 服务 Adapter1 和 Adapter2？

我基于微服务架构构建了一个应用程序，我现在有两个服务，它们都有一些通用代码。

这样做的传统方法是什么？（不同的项目、模块等）我还想要一个关于如何在 git 存储库中处理它们的参考资料（对于所有人？对于每个人？）

对于将单体应用程序拆分为微服务的人，您如何处理拆分数据库的难题。出于性能和简单性的原因，我从事过的典型应用程序进行了大量的数据库集成。

如果您有两个逻辑上不同的表（如果您愿意的话，是有界上下文），但您经常对大量数据进行聚合处理，那么在单体应用中，您很可能会避开面向对象，而是使用数据库的标准JOIN 功能可在将聚合视图返回到您的应用层之前处理数据库上的数据。

您如何证明将此类数据拆分为微服务的合理性，据推测您将需要通过 API 而不是在数据库中“加入”数据。

我读过 Sam Newman 的微服务书，在关于拆分 Monolith 的章节中，他举了一个“打破外键关系”的例子，他承认跨 API 进行连接会更慢 - 但他接着说，如果无论如何，您的应用程序足够快，它比以前慢有关系吗？

这似乎有点油嘴滑舌？人们的经验是什么？您使用了哪些技术来使 API 连接的性能可以接受？

目前，我们设计并计划将我们的系统转换为微服务架构模式。

为了松散耦合，我们考虑使用 JMS 主题进行事件驱动设计。这看起来很棒。但我现在不知道如何解决多个微服务实例的问题。对于故障转移和负载平衡，我们有每个服务的n 个实例。如果将事件发布到主题，每个实例都将接收并处理该事件。

可以使用数据存储中的锁和已处理状态来处理此问题。但是这个解决方案看起来非常昂贵，并且每个实例都有相同的工作。这对我来说不是负载平衡。

这种模式是否有一些好的解决方案或最佳实践？