问题标签 [microservices]

我对 Web 应用程序分化为微服务的点感到困惑——是在 url 级别还是在模型级别？例如，假设我有一个提供 3 个页面的单体应用程序。假设每个页面都有一个单独的用例，我想用他们自己的微服务来支持它们。现在，哪些是实现基于微服务的架构的正确方法：

• 我创建了三个不同的应用程序（微服务），每个应用程序都包含一个页面的（路由、控制器、模型、模板）。然后根据请求的页面，我将请求路由到该特定应用程序。这意味着从数据库到 HTML 的整个页面由单独的应用程序提供。基本上，同一网站中的不同页面完全由后端的不同应用程序提供服务。
• 这 3 个微服务不处理 UI 内容，只处理其用例的数据（模型、控制器、无模板）并通过 REST api 公开它。我有一个面向公众的应用程序。该应用程序仅查询三个不同的应用程序（微服务）以获取数据，然后构建要返回给浏览器的 html 页面。在这种情况下，Web 应用程序中的所有页面都由一个应用程序提供服务，该应用程序在内部使用三个不同的微服务。

在构建遵循微服务架构 ( http://martinfowler.com/articles/microservices.html ) 的整体服务时，有什么理由反对（或支持）使用企业服务总线的特性？为什么我们应该使用哑管道和智能端点而不是使用更智能的管道并能够开发更简单的服务？

我刚刚阅读了一篇关于微服务和 PaaS 架构的文章。在那篇文章中，大约下降了三分之一，作者指出（在Denormalize like Crazy下）：

重构数据库模式，并对所有内容进行反规范化，以实现数据的完全分离和分区。也就是说，不要使用服务于多个微服务的底层表。不应该共享跨多个微服务的基础表，也不应该共享数据。相反，如果多个服务需要访问相同的数据，则应通过服务 API（例如已发布的 REST 或消息服务接口）共享这些数据。

虽然这在理论上听起来很棒，但在实践中它有一些严重的障碍需要克服。其中最大的原因是，数据库通常是紧密耦合的，每个表都与至少一个其他表有某种外键关系。因此，不可能将数据库划分为由n 个微服务控制的n个子数据库。

所以我问：给定一个完全由相关表组成的数据库，如何将其反规范化为更小的片段（表组），以便这些片段可以由单独的微服务控制？

例如，给定以下（相当小但示例性的）数据库：

不要花太多时间批评我的设计，我是即时完成的。关键是，对我来说，将这个数据库分成 3 个微服务是合乎逻辑的：

1. UserService- 用于系统中的 CRUDding 用户；应该最终管理[users]表；和
2. ProductService- 用于系统中的 CRUDding 产品；应该最终管理[products]表；和
3. OrderService- 用于系统中的 CRUDding 订单；应该最终管理[orders]和[products_x_orders]表

然而，所有这些表都具有彼此之间的外键关系。如果我们对它们进行非规范化并将它们视为单体，它们就会失去所有的语义意义：

现在没有办法知道谁订购了什么、数量多少或何时订购。

那么这篇文章是典型的学术喧嚣，还是这种非规范化方法在现实世界中具有实用性，如果是这样，它是什么样的（在答案中使用我的示例的奖励积分）？

我以为我知道 REST/“RESTFul”、restfulservices、webservices、SOA 和微服务是什么，但我遇到了太多不同的定义，以至于我得出的结论是这些术语被过度使用、误用或简单地定义不当。

我希望对上述术语的含义，它们的具体定义，它们的共性和差异，优缺点，以及最重要的底线 - 为了正确使用这些术语而要记住的最重要的事情有一个清晰的理解。

我是 Cloud Foundry 的新手，正在研究我们的旧 Java EE 应用程序与在 Cloud Foundry 上运行的应用程序进行异步通信的可能方法。

我们已经在做很多异步工作，并且正在将事件发布到 Active MQ。

我知道云代工厂有可能与 Rabbit MQ 绑定，我的问题是云代工厂运行应用程序连接（监听）到现有的 CF 平台外的 Rabbit MQ 的可能性？

关于实现这一目标的其他替代方案的任何想法？

分布式系统中的不同组件如何知道将消息发送到何处以访问某些服务？

例如，假设我有一个处理身份验证的服务和一个处理搜索的服务。处理搜索的组件如何知道将身份验证请求发送到哪里？子域更常用吗？如果是这样，复制在这种情况下如何工作？是否有一些处理所有这些路由的本地 IP 地址注册表？

我有一个专门用于批处理的 Web 应用程序（这里是批处理服务，API 驱动），我有一个专门用于其他所有事情的主 Web 应用程序。我一直在努力决定最好的方法是避免批处理服务中业务逻辑的重复。两个应用程序都是集群的。批处理的分离对于简单的工作来说是可以的，但我有更复杂的工作，如果业务逻辑被复制，它只会导致混乱。这是我出于这个问题的目的的用例。

1. 客户为用户更新安排一个 cron 作业。
2. 批处理服务提供一个包含 20,000 条用户记录的 CSV 文件。
3. 批处理服务通过文件对记录执行验证，基本上是试运行。
4. 批处理服务将检查允许的更改和错误阈值（百分比为计数）
5. 如果验证阈值通过，批处理服务将开始创建/更新用户。
6. 创建或更新用户时，有许多模块/功能需要了解这些事件。
7. 跟踪工作进度，客户可以查看进度、日志和工作状态。

以下是我一直在考虑的一些解决方案：

• 合并业务逻辑并在两个应用程序之间共享。这不一定很容易，因为主应用程序是一个 Grails 应用程序，而且它到处都是 GORM。
• 让批处理服务命中主应用程序上的 API，以进行创建和更新以及可能更复杂的验证场景。担心这会对 tomcat 造成影响，但调用将通过负载均衡器进行分配。
• 让批处理服务在主应用程序上命中 API 以进行验证，然后将创建/更新请求排队并让主应用程序检索它们。同上，队列有助于减少 http 调用。还需要一个队列来将状态报告回批处理服务。
• 通过让批处理服务进行自己的验证和插入/更新来复制一些逻辑，然后触发用户创建的事件或用户更新的事件，以便主应用程序中的模块/功能可以处理这些更改。
• 将批处理服务嵌入到主应用程序中

其他详情：

• 批处理服务和 Web 应用程序都是集群的
• 两者都在 AWS 上运行，因此我可以轻松访问 SQS 和 SNS 等工具
• Java 1.7 应用程序
• Tomcat 容器
• 主要应用是 Grails
• 批处理服务以 Spring Batch 和 Quartz 为核心

所以我的问题是，根据上述细节，避免业务逻辑重复的可接受方法是什么？可以/应该改变架构以更好地适应这一点吗？

另一个需要考虑的想法是这会是什么样子以及“微服务”架构。这个词在办公室里被反复讨论过很多次，我们一直在考虑将主要的 Web 应用程序分解为服务的想法。例如，我们最终可能会提供用户管理服务。

我目前有两个应用程序正在运行...

一个是我的 REST API 层，它为前端提供了许多服务。另一个是“翻译应用程序”，它可以被提供一个 JSON 对象（通过 http POST 调用），对该对象执行一些数据翻译和映射并将其返回到 REST 层

我的情况是我想为大量对象执行此操作。我想要的流程是：

用户以特定格式请求 100,000 个对象 -> REST 层从数据库中检索这些对象 -> 将每个 JSON 数据对象传递给翻译服务以执行格式化 -> 将每个对象传递回 REST 层 -> REST 层将新对象返回给用户.

我不想做的是在 100,000 个不同的调用上调用 tranlate.example.com/translate，或者通过 1 个巨大的 POST 请求传递数兆字节的数据。

因此，显而易见的答案是将数据流式传输到翻译应用程序，然后将数据流式传输回来。

跨应用程序传输数据似乎有很多解决方案：打开 websocket (socket.io)，打开两者之间的原始 TCP 连接，或者由于 Node 的 HTTP 请求和响应数据实际上是一个流，我可以利用它然后在成功翻译后发出一个 JSON 对象

我的问题是这里有在两个应用程序之间流式传输数据的最佳实践吗？看来我应该使用 http(req, res) 流并保持长期连接打开以保留“REST”模型。任何可以提供的样品都会很棒。

我正在使用 Spring Boot 和 RabbitMQ 测试微服务架构。

我现在有两个小服务： UserRegistrationService（在数据库中注册用户） GetUserInfo（从同一个数据库返回用户）

我选择让所有用户特定的服务使用相同的数据库。

这两项服务都使用实体“用户”（JPA）。（这可能不是最聪明的方法）

有处理这种依赖的聪明方法吗？（两个服务依赖于同一个实体）我应该让实体（用户）成为一个单独的项目并使用工件存储库吗？

在单体架构中，您将拥有一个核心/平台代码，在其之上将构建一堆服务或业务领域。一些例子是，数据库抽象，外部服务抽象等。

在微服务的情况下，平台代码是否会被编写为一个模块，该模块将作为每个微服务中的依赖模块导入，或者这是否违反了架构的构造，因为模块和通用之间的紧密耦合（核心/平台）代码，从而回到与多个部署、代码错误、供应商锁定等相关的问题？