Vert.x 3 和微服务

Question

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

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

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

选项

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

部署

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

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

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

有什么想法吗？

Answer 1

让我们从术语开始。

• verticle 是一个 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 应用程序通常由一个或多个公开 REST 端点的 Vert.x 应用程序组成，该应用程序通过事件总线与一个或多个公开（内部）事件总线端点的 Vert.x 应用程序进行通信。

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

Answer 2

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

这些是官方Microservices modules：

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

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

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

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

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

• Vert.x - From zero to (micro)-hero Clement Escoffier（Vert.x 核心开发人员）
• Asynchronous Microservices with Vert.x Piotr Mińkowski
• Running Vert.x Microservices on Kubernetes/OpenShift DZone 上的 Piotr Mińkowski
• Event-Driven Microservices With Vert.x and Kubernetes (Part 1 of 3) 由 Andy Moncsek 提供

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

• Vert.x Microservices Blueprint Github 上的 Eric Zhao

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

Answer 3

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