问题标签 [microservices]

我正在设计一个所有微服务都集群的架构。例如：5 个 Web 服务器、1 个集群数据库、1 个集群队列系统、8 个集群工作人员（如发送电子邮件、发送短信等），从队列中消费（任务由 Web 服务器推送）

我想知道最佳实践是为了检测每个“微服务集群”是否健康，以及在这种情况下如何让整个服务“快速失败”，其中一个微服务不可用。

所有服务都位于一个用于 ha 代理的 nginx 后面 - 是否应该是 nginx 监控所有内容并失败？如何检查所有微服务的健康状况？

我正在考虑为我们的内部服务之间的通信引入一种强类型（读取 - 使用预定义模式）数据交换格式。例如，我猜想 Thrift 或 Cap'n Proto 之类的东西。

使用它而不是像 JSON 这样的东西至少有两个明显的优势（对我来说）是

1. 您将知道服务可以预期的数据的确切格式（因此在通信时留出更少的歧义和错误空间）和
2. 该实现通常为您反序列化原始消息，并提供访问对象的方法。

与 JSON 之类的方法相比，这条路线的实际缺点是什么？

对于上下文——我们的系统由用 python 和 java 编写的服务组成——未来可能还有其他语言，并通过服务和消息代理（如 rabbitmq）之间的 HTTP 端点进行通信。

在我们公司，我们正在从一个巨大的单体应用程序过渡到一个微服务架构。这个决定的主要技术驱动因素是需要能够独立扩展服务和开发的可扩展性——我们有十个 Scrum 团队在不同的项目（或“微服务”）中工作。

过渡过程很顺利，我们已经开始受益于这种新技术和组织结构的优势。现在，另一方面，我们正在努力解决一个主要的痛点：如何管理这些微服务之间的依赖关系的“状态”。

让我们举个例子：其中一个微服务处理用户和注册。该服务（我们称之为 X）负责维护身份信息，因此是用户“id”的主要提供者。其余的微服务对这个有很强的依赖。例如，有一些服务负责用户配置文件信息 (A)、用户权限 (B)、用户组 (C) 等，它们依赖于这些用户 ID，因此需要在这些服务之间维护一些数据同步（即服务 A 不应该有未在服务 X 中注册的用户 ID 的信息）。我们目前通过使用 RabbitMQ 通知状态更改（例如新注册）来保持这种同步。

可以想象，有许多X：许多“主要”服务以及它们之间的许多更复杂的依赖关系。

管理不同的开发/测试环境时出现的主要问题。每个团队（因此，每个服务）都需要经过几个环境才能使一些代码生效：持续集成、团队集成、验收测试和实时环境。

显然，我们需要在所有这些环境中工作的所有服务来检查系统是否作为一个整体工作。现在，这意味着为了测试依赖服务（A，B，C，...），我们不仅要依赖服务 X，还要依赖它的状态。因此，我们需要以某种方式维护系统完整性并存储全局和连贯的状态。

我们目前的方法是从实时环境中获取所有数据库的快照，进行一些转换以缩小和保护数据隐私，并在特定环境中进行测试之前将其传播到所有环境。这显然是组织和计算资源方面的巨大开销：我们有十个持续集成环境、十个集成环境和一个验收测试环境，所有这些环境都需要使用来自实时和最新版本代码的共享数据“刷新”频繁地。

我们正在努力寻找更好的方法来缓解这种痛苦。目前我们正在评估两种选择：

1. 为所有这些服务使用类似 docker 的容器
2. 每个服务有两个版本（一个用于开发该服务，另一个作为沙箱供其他团队在开发和集成测试中使用）

这些解决方案都不能减轻服务之间共享数据的痛苦。我们想知道其他一些公司/开发人员是如何解决这个问题的，因为我们认为这在微服务架构中一定很常见。

你们怎么样？你也有这个问题吗？有什么推荐吗？

很抱歉解释太长，非常感谢！

我在一个使用多个（很多）服务器开发解决方案的环境中工作。他们的微服务风格是榜样。

为了能够升级系统，它们必须在运行时可切换/可替换（包括用户界面）。已决定的主要解决方案是

1. 门户/代理是最终用户唯一可见的系统
2. 代理“知道”支持服务器
3. 代理有一些基本的用户界面，例如菜单。可能与子系统协作（菜单中的几个条目等）
4. 用户请求包含一些动态内容的页面
5. 门户将页面“内容”部分的查询中继/代理到子系统。
6. 客户端所需的任何 REST 调用也通过主服务器代理。

REST 调用当然非常简单，但我在 Angular 中太笨了，无法真正理解如何进行“混合”。第 5 点当然是困难的部分。如果子服务器可见，则 iframe（eeek！）可能有已使用，但在本例中未使用。

我需要在一个页面内进行某种“委托”，以前做过什么吗？微服务旗舰如何处理用户界面？

单点登录身份验证/授权微服务架构的好的设计是什么？

我的想法：

我需要构建微服务以通过消息总线（RMQ 或 Kafka）使用异步接口处理身份验证和授权。

• 身份验证服务可以是管理用户身份（用户名、密码、电子邮件）的用户微服务

• 授权服务负责：

  1. 为具有允许访问角色的用户提供 Auth-Token。
  2. 充当 SSO 服务。
  3. 授权其他微服务，这样不是每个人都会向总线发布消息。

我做了一些研究，发现 2-legged OAuth 有时用于内部 Web/微服务。但由于 OAuth 主要依赖于 HTTP 301，因此在内部进行 HTTP 调用我认为这是内部系统的开销。

谢谢！

假设有一个工作服务从队列接收消息，从文档数据库中读取具有指定 Id 的产品，根据消息应用一些操作逻辑，最后将更新的产品写回数据库 (a)。

当处理不同的产品时，这项工作可以安全地并行完成，因此我们可以水平扩展（b）。但是，如果多个服务实例在同一个产品上工作，我们最终可能会遇到并发问题，或者数据库中的并发异常，在这种情况下，我们应该应用一些重试逻辑（但重试仍然可能再次失败等等） .

问题：我们如何避免这种情况？有没有办法可以确保两个实例不在同一个产品上工作？

示例/用例：一家在线商店在产品 A、产品 B 和产品 C 上进行了一次大促销，在一个小时内结束，数百名客户正在购买。对于每次购买，都会将一条消息排入队列（productId、numberOfItems、price）。 目标：我们如何运行我们的工作服务的三个实例，并确保 productA 的所有消息都将在 instanceA、productB 到 instanceB 和 productC 到 instanceC 中结束（不会导致并发问题）？

注意：我的服务是用 C# 编写的，作为工作角色托管在 Azure 上，我使用 Azure 队列进行消息传递，我正在考虑使用 Mongo 进行存储。此外，实体 ID 是GUID.

它更多的是关于技术/设计，所以如果你使用不同的工具来解决我仍然感兴趣的问题。

我正在重构几个 node.js 服务。它们都是forever从虚拟服务器开始的，如果进程崩溃了，它们就会重新启动。

现在，转向容器化和无状态应用程序结构，我认为进程应该退出并且容器应该在失败时重新启动。

那是对的吗？有好处还是坏处？

我们有一个后端，有十几个工人python与. 我们还有 API网关。工作人员之间的上下文由数据库处理。rabbitMQceleryDjangopostgresql

我们想：

1. 为了解耦数据库和工作人员，
2. 能够在 Go 中制作工人。

我们查看了microservice基础设施，这似乎很有趣。我们不明白的是我们应该使用什么样的请求/响应模式，以及如何在不使用公共数据库的情况下处理工作人员之间的请求上下文。

微服务文章处理notifications和subscription. 这适用于这种情况还是我们应该使用 HTTP 请求。是否使用了RPC图案？这个图案似乎很重。

自然地，随着所有这些微服务和不变性的炒作，现实生活中出现了这样的问题：

如何从一个不可变的容器化应用程序发送电子邮件，该应用程序应该支持从普通 SMTP 到 Sendgrid、MailJet、Mandrill、Mailgun 等事务性邮件提供商的多个提供商？

在基于过去架构原则构建的软件系统中，这个问题通常通过允许覆盖默认 SMTP 提供程序的插件机制来解决；WordPress 就是一个例子。然而，这被认为是糟糕的设计，因为它破坏了应用程序的不变性。

在观看并阅读了 Martin Fowler、Sam Newman、Adrian Cockcroft 和 Sudhir Tones 的大量文章之后，微服务似乎非常适合我的软件。但是，在深入考虑实施时，存在一些问题：

1. 我的软件有一个 UI，我们称它为基于 Web 的组件。该组件需要在内部协调/编排对 10-20 个不同微服务的调用（我们称之为“私有微服务”）并将数据返回给 AJAX 调用。在这个组件中耦合编排逻辑是一个好的设计吗？或者我应该创建另一个完成这项工作的微服务，并且基于 Web 的组件应该非常薄以将调用委托给这个微服务？
2. 我需要公开一些公共 API。我应该有一个单独的层来委派上述情况下的调用吗？

我认为这可能或多或少与公共/私有微服务的设计模式有关。

解决上述问题的好模式是什么？

2015 年 4 月 9 日更新：

API 网关模式实际上解决了我的担忧。我也同意有关 EAI 模式或安全考虑的其他答案。

为了进一步了解我的发现，我认为 Netflix 架构具有所谓的“边缘服务”，它是服务来自基于 Web 或设备的请求的前端，而中间层服务实际上是您的微服务。所以我认为将中间层服务推广为边缘服务，这必须是一个代表。它将保持中间层的清洁和一致。

看看https://github.com/cfregly/fluxcapacitor#project-overview有更多的想法。