微服务作为一种软件架构风格,正在得到越来越多的关注,它有助于更好地支持持续交付、提供快速部署和关注点分离模型。
Vert.x 3和Vert.x-Apex提供了一种有趣的微服务构建模型。如示例所示,一个简单的垂直应用可以公开一个HTTP服务,从而提供REST服务。该垂直应用绑定了自己的TCP端口。
在扩展到多个微服务以支持完整应用程序时,你会面临许多选择。对于哪种风格最终可以支持持续交付并最小化升级停机时间,你有什么想法吗?
选项
- 运行多个垂直应用可能是一种解决方案,每个应用程序都包含其自己的路由,因此http处理包含在垂直应用中。请求/响应可以完全由垂直应用处理。这意味着每个垂直应用都在自己的TCP端口上运行。
- 使用路由器,你可以在单个端口上公开所有路径,并相应地进行处理。数据将由包含路由器的垂直应用程序处理,可能会将其传递给其他垂直应用程序。这开始看起来像是一种更单片机的方法。
- 运行包含服务的单独的vert.x实例(可以将它们集群)。这可能使使用持续交付更容易,因为整个事物是自包含的。
- 其他可能的选项?
部署
在部署方面,希望能够快速部署新服务,而不会使整个应用程序宕机。
- 第3个选项可能提供了一种方式,但也可能会导致开销,特别是当每个垂直应用中都有一个DB垂直应用运行时。
- 第1个选项可能更容易,但是如何重新加载新的和更新的垂直应用程序。
分离的微服务提供了一种有趣的开发方式,但会在编排和部署方面面临一些挑战。
有什么想法?
vertx.deployVerticle(..);
语句。不要被 VertxStarter 类具有(Java)main 方法并使用 Vertx.vertx() 获取 Vertx 实例的事实所困扰;-)(在这种情况下也没有必要扩展 AbstractVerticle)。 - Bert Jan Schrijver