Vert.x 3和微服务

23

微服务作为一种软件架构风格,正在得到越来越多的关注,它有助于更好地支持持续交付、提供快速部署和关注点分离模型。

Vert.x 3和Vert.x-Apex提供了一种有趣的微服务构建模型。如示例所示,一个简单的垂直应用可以公开一个HTTP服务,从而提供REST服务。该垂直应用绑定了自己的TCP端口。

在扩展到多个微服务以支持完整应用程序时,你会面临许多选择。对于哪种风格最终可以支持持续交付并最小化升级停机时间,你有什么想法吗?

选项

  1. 运行多个垂直应用可能是一种解决方案,每个应用程序都包含其自己的路由,因此http处理包含在垂直应用中。请求/响应可以完全由垂直应用处理。这意味着每个垂直应用都在自己的TCP端口上运行。
  2. 使用路由器,你可以在单个端口上公开所有路径,并相应地进行处理。数据将由包含路由器的垂直应用程序处理,可能会将其传递给其他垂直应用程序。这开始看起来像是一种更单片机的方法。
  3. 运行包含服务的单独的vert.x实例(可以将它们集群)。这可能使使用持续交付更容易,因为整个事物是自包含的。
  4. 其他可能的选项?

部署

在部署方面,希望能够快速部署新服务,而不会使整个应用程序宕机。

  • 第3个选项可能提供了一种方式,但也可能会导致开销,特别是当每个垂直应用中都有一个DB垂直应用运行时。
  • 第1个选项可能更容易,但是如何重新加载新的和更新的垂直应用程序。

分离的微服务提供了一种有趣的开发方式,但会在编排和部署方面面临一些挑战。

有什么想法?

3个回答

14

让我们从术语开始。

  • 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构建微服务风格的应用程序时,通常需要小型独立的逻辑工作单元,称之为服务。这样的服务理想情况下应该在其自己的过程中运行,是自包含和独立可升级的。将其映射到上述术语:将服务构建为包含服务逻辑的单个Verticle的Vert.x应用程序。

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

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

回答你的问题:在Vert.x架构中,选项3是最常见的,且与微服务架构最接近。在这里,您可以选择2个选项:要么运行1个应用程序,该应用程序具有处理所有HTTP调用并将请求处理委派到其他应用程序的REST端点,要么为每个服务(或至少为每个为最终用户提供功能的服务)提供自己的REST端点。后者设置略微复杂,因为前端需要连接到多个HTTP端点,但是它更具可扩展性,并且单个故障点较少。


你能否详细说明一下“一个应用程序可以包含一个或多个垂直”?我不明白vx应用程序和vx垂直之间的区别,特别是在扩展AbstractVerticle并使用“$ vertx run com.my.verticles.Main”启动的“main”类的情况下。这里的“应用程序”是什么? - Draculater
一个Vert.x应用程序需要一个Verticle作为入口点。因此,您至少需要1个Verticle。但是,您还可以从“main”Verticle编程方式部署其他Verticles。请参见https://github.com/bertjan/vertx3-examples/blob/master/basic-eventbus/src/main/java/nl/revolution/vertx3/eventbus/basic/VertxStarter.java以获取示例。 - Bert Jan Schrijver
1
我指的是示例中的 vertx.deployVerticle(..); 语句。不要被 VertxStarter 类具有(Java)main 方法并使用 Vertx.vertx() 获取 Vertx 实例的事实所困扰;-)(在这种情况下也没有必要扩展 AbstractVerticle)。 - Bert Jan Schrijver

3

目前,Vert.x拥有一些官方模块用于创建微服务架构,我认为这些在您提问时可能还不存在。

这些是官方的微服务模块

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

还有更多官方模块非常方便:

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

您可以在微服务设计中添加许多其他官方模块。

此外,还有一些很棒的文章介绍如何将它们应用于实践中:

最后,如果您想查看比HelloWorld更深入的代码,请参考:

此外,还有许多可用的代码(例如API网关,但仅有中文的Readme文档)。


0

我认为你必须有坚实的可扩展性理由来分区你的服务,而且在处理生命周期和解决服务之间相互交互时,并没有一种适合所有情况的方法。无论是一个“垂直”的东西还是其他东西在侦听套接字,我认为限制端点/地址的数量会在这个方向上引起最少的麻烦。无论如何,负责将给定的“垂直”与其套接字相关联的代码实体都需要以某种方式向编排框架公开生命周期控件...就像如果它不是在那里侦听的“垂直”,也会这样做。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接