What is QBit?

For a quick overview check out these two slide decks QBit Early Slide Deck and QBit Java Microservices Lib. For support from the community see this qbit google group. There are also tons of documentation in the QBit WIKI. The wiki home page does a good job of covering QBit basics, and tries to touch on every area. If you are more looking for the high-level What is QBit trying to solve then look no further than Java Microservices architecture, High Speed Microservices, Reactive Microservices, and Microservice Monitoring.

Here is a high-level bullet list style description.

QBit looks like Spring MVC but is more like Akka with a lot of inspiration from Vert.x.

QBit core ideas were built when using Vert.x at large media company to be able to handle 100M users on fraction of servers (13 but could do it with 6 servers similar in scope to another app done by another vendor which used 2,000 servers. Similar Java EE app done by competing media company used 150 servers). For this project the service was capable of handling 2,000,000 CPU intensive requests per second on 10 servers. (Only able to test this service to 400K TPS across cluster due to F5 starting to implode, but was able to test single node at 150K TPS using cloud load tester that simulated clients from iOS, Android and Web. 150K was limitation of the license agreement of the cloud load tool.).

Ideas were expanded while using QBit to build OAuth based application id rate limiter.

Uses messaging, event busses, and queues. Similar in architecture to Vert.x/Akka. Not quite as complex as Akka, not quite as low level as Vert.x.

A service looks just like a Java class. It has methods. It has fields. The fields do not need to be synchronized because only one thread can access the service at a time. Services calls are sent in batches over a queue (internally). For CPU intensive services there are low level checks to see if the service is busy. If the service is busy, the batch sizes get larger, which means there is less overhead using low level thread-safe hand-off constructs, which means it runs faster. Batching also helps with remote services to maximize IO bandwidth.

If you are building high-speed in-memory services, QBit is an excellent option. If you are building async services, QBit is an excellent option. If you are building services that must work with streams of calls or message, then QBit is an excellent option. If you are building microservices and you want to implement back pressure detection, circuit breakers, coordinate calls to N number of other internal / external services, QBit is an excellent option.

Tier 1: Core Features

1. Fast queue lib (200M messages a second)
2. Fast service queue lib (internal queue to queue, typed actor like)
3. Proxy to service queue programming model is Java idiomatic (smaller learning curve).
4. Ability to handle queue states (queue empty, queue busy, queue limit, etc.)
5. Reactor (call coordination, callbacks, timing out detection, async call workflow). Easy to use. Focused on services and handling calls.
6. Workers Services can be round-robin workers (pooled, each member has its own state but stateless wrt to client session) or sharded workers (shard calls so that in-memory services can split the data into shards so that any single shard of in-memory data is only accessed by one thread).

Note: Tier 1 support is similar to Akka typed Actors. A service is a Java class that sits behind one or two queues (request/response queues).

Tier 2: Core Features

1. EventService: Pub/Sub events (works with service queue lib to deliver events) (20M TPS)
2. StatsService: collect stats (high-speed, can be clustered)
3. HealthService: collects health status of service queues (new)
4. ServiceDiscovery service (Consul or JSON file watcher)

Tier 2: IO: Http Web Server / Http Web Client:

1. Simplified HTTP dev, async
2. One liners for sending and receiving HTTP requests/responses
3. HttpClient, HttpServer
4. Easy to use WebSocket lib for servers and clients
5. Many utility function and builders for building complex REST calls (postGzipJson).
6. Thread safe access to handlers just like QBit services

Tier 3: REST/HTTP

1. Builds support for REST on top of Tier 1 and Tier 2
2. Focused on JSON only responses and bodies (uses high-speed JSON parser)
3. Supports subset of Spring MVC annotations @RequestMapping
4. Easier smaller set. Main focus is on REST services with JSON.
5. Faster than mainstream (4x faster than Spring/Tomcat) 96K TPS to 200K TPS
6. Thread safe access to handlers just like QBit services

Tier 3: Remote call proxy

1. Easy to use. Use Builders to build a proxy
2. Remoting with WebSocket
3. Programming model same as ServiceQueue
4. Wire protocol is JSON and ASCII
5. We use the fasted Java JVM parser
6. Proxy similar to local proxy
7. 4x to 5x faster than QBit REST/HTTP (should be 10x faster) 400K TPS (800K messages a second)
8. Program to interfaces. Simple.
9. A service can have a remote and local proxy interfaces

Admin Features:

1. Metadata provider (creates large catalog of metadata about services used for REST mapping calls) (Replaced older hackier way)
2. REST end point to see status of internal services (rudimentary http page as well)
3. Auto-register health checks with services
4. Auto register rudimentary stats with services (counts, sampling for timing, creation, queue size, etc. Periodic low over-head)

EventService

1. Pub/Sub events (works with service queue lib to deliver events) (20M TPS)
2. Easy to use api, register(), subscribe(), consume()
3. Internal app messaging. Used by ServiceDiscovery for example.
4. You could use to create workflows, or just to monitor an event
5. Async.
6. A Channel interface is used to implement the listener and to send messages. A Channel is just a plain java interface. It is easy to see who listens to the event from the IDE because all you have to do is do a find usage.
7. You do not have to use the proxy channel. A channel name can be any String.
8. EventService can be clustered! You can send events to all other nodes. You can use it to replicate calls or events to other nodes. The clustering using Consul.io to get a list of service members in a service group.
9. By default, it is not clustered. You can easily integrate with any 3rd party messaging system. The EventService has an event replication mechanism to replicate event messages to other pipes (Kafka, JMS, RabbitMQ), etc.

StatsService

1. Tracks counts, timings, and levels
2. Can be clustered (with QBit ServiceDiscovery service and Console)
3. Can be integrated with StatsD
4. Can be used to implement things like high-speed rate limiting based on header
5. Can be used to implement things like track system and implement back pressure cool off

ServiceDiscovery

1. Keeps track of services
2. Lets you find services
3. Lets you know when services have been added or removed
4. Removes services that are unhealthy
5. Uses Consul.io, but can also just poll a JSON file for easy integration with Consul or etcd, (Chef push), etc.

HealthService

1. Internal single node tracking (single node meaning process)
2. Tracks N number of internal health nodes
3. Services can auto-register with the health system.
4. Uses TTL. It is a watchdog type service.