23

微服务作为一种软件架构风格正在获得关注，它将更好地支持持续交付，提供快速部署和关注点分离的模型。

Vert.x 3 和 Vert.x-Apex 为构建微服务提供了一个有趣的模型。如其中一个示例所示，一个简单的 Verticle 可以公开 HTTP 服务，因此可以使用 REST 服务。verticle 绑定了自己的 tcp 端口。

当扩展到多个微服务以支持完整的应用程序时，您最终会有很多选择。关于哪种风格最终可以支持持续交付并最大程度地减少升级停机时间的任何想法？

选项

  1. 运行多个 verticles 可能是一个解决方案，它们都包含自己的路由，因此 http 处理包含在 verticle 中。请求/响应可以完全由 Verticle 处理。这可能意味着每个 Verticle 在它自己的 tcp 端口上运行。
  2. 使用路由器，您可以在单个端口上公开所有路径，并相应地处理它们。数据将由包含路由器的 Verticle 处理，可能会将其传递给其他 Verticle。然后这开始看起来像一个更单一的方法。
  3. 运行包含服务的单独的 vert.x 实例（可能对它们进行集群）。这可以更容易地使用持续交付，因为整个事情是独立的。
  4. 其他可能的选择？

部署

在部署方面，需要快速部署新服务，而不会使整个应用程序瘫痪。

  • 选项 3. 可以为此提供一种方法，但也可能导致开销，尤其是当每个 Verticle 中都有一个 DB Verticle 运行时。
  • 选项 1. 可能更容易，但是重新加载新的和更新的 Verticle 怎么样。

单独的微服务提供了一种有趣的开发方式，但在编排和部署方面存在一些挑战。

有什么想法吗？

4

3 回答 3

14

让我们从术语开始。

  • Averticle是一个 Java 类，通常扩展AbstractVerticle并实现 start(..) 方法。一个 Verticle 可以暴露一个或多个 HTTP 端点并暴露一个或多个eventbus端点。
  • 一个 Verticle 在 Vert.x application（以前称为“模块”）中运行。一个应用程序可以包含一个或多个 Verticle。我通常保持 1:1 的比例，以使事情变得小而简单。
  • Vert.x 应用程序在 Vert.x 中运行instance。您可以运行应用程序的多个实例以提高并行度。
  • Vert.x 实例在 Vert.x 中运行container。容器是具有一个或多个应用程序实例的正在运行的进程。
  • Vert.x 容器在 JVM 中运行。

使用 Vert.x 构建微服务风格的应用程序时，您通常需要小的独立逻辑工作单元，将它们称为服务。理想情况下，此类服务应在其自己的进程中运行，自包含且可独立升级。将其映射到上面的术语：将服务构建为 Vert.x 应用程序，其中包含具有服务逻辑的单个 Verticle。

Vert.x 应用程序使用由 Hazelcast 构建的分布式事件总线相互通信。这意味着运行在同一台服务器甚至多台服务器上的多个 JVM 可以通过 Vert.x 事件总线相互通信。

使用 Vert.x 构建的 Web 应用程序通常由一个或多个 Vert.x 应用程序组成，这些应用程序公开通过事件总线进行通信的 REST 端点，而一个或多个 Vert.x 应用程序公开（内部）事件总线端点。

回答您的问题：选项 3 在 Vert.x 设置中最常见，并且最接近微服务架构。您可以在其中选择 2 个选项：您可以使用 REST 端点运行 1 个应用程序，该端点处理所有 HTTP 调用并将事件总线上的请求处理委托给其他应用程序，或者您提供每个服务（或至少每个服务为最终用户提供功能) 它自己的 REST 端点。后者的设置有点复杂，因为有多个 HTTP 端点要从前端连接，但它更具可扩展性并且单点故障更少。

于 2016-02-28T12:51:14.023 回答
3

Vert.x 目前有许多用于创建微服务架构的官方模块——我相信——在你提出问题的时候并不存在。

这些是官方的微服务模块：

  • Vert.x 服务发现- 发布、查找和绑定到任何类型的服务。
  • Vert.x 断路器- 为 Vert.x 提供断路器模式的实现
  • Vert.x Config - 提供一种可扩展的方式来配置 Vert.x 应用程序。

还有更多官方模块派上用场：

  • Metrics using Dropwizard - 从核心组件获取指标并发送到 Dropwizard。
  • Metrics using Micrometer - 从核心组件获取指标并发送到 Micrometer。
  • Vert.x 健康检查- 提供了一种公开健康检查的简单方法。
  • Vert.x 集群- 支持 Hazelcast、Zookeeper、Apache Ignite 和 Infinicast
  • Vert.x 服务- 封装可重用功能以在其他地方使用的简单有效的方法。

您可以在微服务设计中加入更多官方模块。

还有一些关于如何在实践中应用它们的精彩文章：

最后，如果您想查看比 更进一步的代码，请HelloWorld查看：

还有更多的代码（比如API Gateway，虽然是中文自述文件）。

于 2018-07-01T19:57:53.310 回答
0

我认为你必须有充分的可扩展性理由来划分你的服务，并且没有任何一种万能的方法来处理生命周期和解决你在让这些服务相互交互时遇到的问题. 无论是“垂直”还是其他东西正在侦听套接字，我都认为限制端点/地址的数量会在这个方向上引起最少的麻烦。在任何情况下，负责将给定 Verticle 关联到其套接字的代码实体需要以某种方式将生命周期控件公开给某个编排框架……就像它不是在那里侦听的 Verticle 一样。

于 2015-11-04T14:30:22.580 回答