Vert.x 3 和微服务

Question

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

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

当扩展到多个微服务来支持一个完整的应用程序时，您最终会有许多选择。对于哪种风格能够最终支持连续交付，并最大限度地减少升级停机时间，有什么想法吗？

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

在部署方面，快速部署新服务是可取的，而不会使整个应用程序停机。

< li >选项3。可以为此提供一种方法，但也会导致开销，尤其是当每个vertice中都有一个DB verticle在运行时。 < li >选项1。可能更容易，但如何重新加载新的和更新的垂直。

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

有什么想法吗？

Answer 1

我认为对服务进行划分必须有可靠的可伸缩性理由，并且没有任何一刀切的方法来处理生命周期和解决让这些服务相互交互时会遇到的问题。无论是“verticle”还是其他什么东西在监听套接字，我都认为限制endpoint/地址的数量会在这个方向上带来最少的麻烦。在任何情况下，负责将给定的verticle关联到它的socket的代码实体都需要以某种方式将生命周期控制暴露给某个编排框架...就像它不是一个垂直的聆听者一样。

Answer 2

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

这些是官方微服务模块：

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

而且还有更多官方模块派上用场:

• 使用拖放向导的指标 - 从核心组件获取指标并发送到删除向导。
• 使用千分尺的指标 - 从核心组件获取指标并发送到千分尺。
• Vert.x 运行状况检查 - 提供一种公开运行状况检查的简单方法。
• Vert.x 集群 - 支持黑泽尔卡斯特，动物园管理员，阿帕奇点燃和无机智能
• Vert.x 服务 - 封装可重用功能以供其他地方使用的简单而有效的方法。

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

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

< li>Vert.x -从零到(微)-hero，作者Clement Escoffier (Vert.x核心开发人员) < Li > Piotr mik owski的Vert.x异步微服务 < Li > Piotr mik owski在DZone上运行Kubernetes/OpenShift上的Vert.x微服务 < li >事件驱动的微服务与Vert.x和Kubernetes(第1部分，共3部分)作者Andy Moncsek

最后，如果你想看到比HelloWorld走得更远的代码，那么看看：

• Vert.x 微服务蓝图 作者：赵磊 在 Github 上

而且还有更多的代码（比如API网关，尽管是中文自述文件）。

Answer 3

先说术语。

• 顶点是一个 Java 类，它通常扩展抽象验证并实现一个 start（..） 方法。顶点可以公开一个或多个 HTTP 终结点，并公开一个或多个事件总线终结点。
• 顶点在 Vert.x 应用程序（以前称为“模块”）内运行。应用程序可以包含一个或多个顶点。我通常保持1：1，以保持事情的小而简单。
• 应用程序在 Vert.x 实例中运行。您可以运行应用程序的多个实例以增加并行化。
• 一个 Vert.x 实例在 Vert.x 容器内运行。容器是具有一个或多个应用程序实例的正在运行的进程。
• Vert.x 容器在 JVM 内部运行。

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

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

用Vert.x构建的web应用程序通常由一个或多个Vert.x应用程序组成，这些应用程序公开通过eventbus与一个或多个公开(内部)eventbusendpoint的Vert.x应用程序通信的RESTendpoint。

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