Question posted in
The official documentation can be found here.

Redis – When would I want to create more than one verticles (assuming I am using non-blocking db clients in a stateless microservice)?

Assuming

  • I am building a stateless micro-service which exposes a few simple API endpoints (e.g., a read-through cache, save an entry to database),
  • I am using the non-blocking database clients e.g., mysql or redis and
  • I always want my microservices to speak to each other via HTTP (by placing EC2 instances behind a load balancer)

Questions

  1. When will I want to use more than 1 standard verticles (i.e., write the whole microservice as a single verticle and deploy n instances of it (n = num of event-loop threads))?. Won’t adding more verticles only add to serialization and context-switching costs?
  2. Lets say I split the microservice into multiple standard verticles (for whatever reason). Wouldn’t deploying n (n = num of event-loop threads) instances of each always give better performance than deploying a different ratio of instances. As each verticle is just a listener on an address and it will mean every event-loop thread can handle all kinds of messages and they are load balanced already.
  3. When will I want to run my application in cluster mode? Based on docs, I get the feeling that cluster mode makes sense only when you have multiple verticles and that too when you have an actual use-case for clustering e.g., different EC2 instances handle requests for different users to help with data locality (say using ignite)

P.S., please help if even if you can answer one of the above questions.

Tags:

2

Answers


  1. 0

    I always want my microservices to speak to each other via HTTP (by placing EC2 instances behind a load balancer)

    It doesn’t make much sence to use Vertx if you already went for this overcomplicated approach.
    Vertx is using Event Bus for in-cluster communication, eliminating the need for HTTP as well as LB in front.

    Answers:

    1. Why should it? If verticles are not talking to each other, where the serialization overhead should occur?

    2. If your verticles are using non-blocking calls (and thus are multithreded), you won’t see any difference between 1 or N instances on the same machine. Also if your verticle starts a (HTTP) server over a certain port, then the all instances will share that single server accross all thread (vertx is doing some magic reroutings here)

    3. Cluster mode is the thing which I mentioned in the beginning. This is the proper way to distribute and scale you microservices.

    Login or Signup to reply.
  2. 0

    1. A verticle is a way to structure your code. So, you’d want verticle of another type probably when your main verticle grows too big. How big? That depends on your preferences. I try to keep them rather small, about 200 LOC at the most, to do one thing.

    2. Not necessarily. Different verticles can perform very different tasks, at different paces. Having N instances of all of them is not necessarily bad, but rather redundant.

    3. Probably never. Clustered mode was a thing before microservices. Using it adds another level of complexity (cluster manager, for example Hazelcast), and it also means you cannot be as polyglot.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search