Skip to main content

myddd-vertx与架构

myddd-vertx并不关心架构,它专注的是领域驱动与整洁架构的编码模式。无论你的项目或产品使用的是什么架构,单体服务也好,微服务也好,都可以使用myddd-vertx。

这意味着你不需要担忧myddd-vertx是否能满足你的架构需求。事实上,基于响应式的实现的myddd-vertx,无论你想使用哪种架构模式,myddd-vertx在性能上都有着天然的优势。

myddd-vertx架构推荐

在《演进式架构》一书中,作者就一个团队或一个公司应该使用的架构做了说明,认为一个团队或公司不能只有一种推定架构,而是有着从简单到复杂的多套架构,根据实际的需求来选择架构。这些不同的架构甚至可以考虑不同的语言,比如最简单的可以考虑NodeJS等。

为此,myddd-vertx也就此推荐了几种架构搭配,这意味着myddd-vertx能够适应不同的项目需求,你应该根据你的实际情况去选择。

  1. 单体架构

如果你的一些需求很明显不存在极大的并发量或高可用,那myddd-vertx的单体架构是非常适合的。

这种架构模式下,最终会以Jar的形式部署。

基于vert.x极高的性能表现,就算是在这种架构模式下,依然有着优秀的性能表现。从我实际的性能测试表现上来看,至少是传统Spring Boot的6-8倍的优势。

  1. 单体 + 集群部署架构

这种是对单体架构的扩展,如果你的架构在并发上,或是特别在高可用上有需求,那在单体架构的基础上,添加nginx或lvs为负载均衡的集群是最合适的选择。

相比单体架构,它有着以下几个优势

  • 性能水平可以水平扩展

  • 支持高可用,单个服务当机不会影响服务的可用性

事实上,我们推荐你主要考虑使用这个模式,除了TO C互联网以外的大部分情况下,我们认为这种架构足以胜任。

  1. 微服务架构

微服务是近年来非常流行的一种架构。

关于微服务,我认为国内有过度使用的趋势,国内架构师有一种不管需不需要,适合不适合,全往微服务上套的趋势。这是一个很不好的趋势。

事实上,微服务在解决了一些问题的时候,同时带来了大量的问题,而大部分项目或产品的场景,如果不是TO C互联网,有着极大的用户群体或活跃使用用户,根本不需要使用微服务。

如果确实你的产品或项目面临这种需求,不用担心,myddd-vertx对微服务的支撑是天然的。当然,这是由vert.x带来的,vert.x在微服务上的支撑是天然的,甚至是比其它语言框架更好的。

vert.x本身带有Event Bus,也有服务注册与查找,也支持消息队列等,所有这些都是vert.x天然支持。

因此,在确有需要的情况下,你完全可以考虑使用微服务架构