Here is a high-level bullet list style description. (After a few more paragraphs.. right to the bulleted list).
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
Fast queue lib (200M messages a second)
Fast service queue lib (internal queue to queue, typed actor like)
Proxy to service queue programming model is Java idiomatic (smaller learning curve).
Ability to handle queue states (queue empty, queue busy, queue limit, etc.)
Reactor (call coordination, callbacks, timing out detection, async call workflow). Easy to use. Focused on services and handling calls.
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
EventService: Pub/Sub events (works with service queue lib to deliver events) (20M TPS)
StatsService: collect stats (high-speed, can be clustered)
HealthService: collects health status of service queues (new)
ServiceDiscovery service (Consul or JSON file watcher)
Tier 2: IO: Http Web Server / Http Web Client:
Simplified HTTP dev, async
One liners for sending and receiving HTTP requests/responses
Easy to use WebSocket lib for servers and clients
Many utility function and builders for building complex REST calls (postGzipJson).
Thread safe access to handlers just like QBit services
Tier 3: REST/HTTP
Builds support for REST on top of Tier 1 and Tier 2
Focused on JSON only responses and bodies (uses high-speed JSON parser)
Supports subset of Spring MVC annotations @RequestMapping
Easier smaller set. Main focus is on REST services with JSON.
Faster than mainstream (4x faster than Spring/Tomcat) 96K TPS to 200K TPS
Thread safe access to handlers just like QBit services
Tier 3: Remote call proxy
Easy to use. Use Builders to build a proxy
Remoting with WebSocket
Programming model same as ServiceQueue
Wire protocol is JSON and ASCII
We use the fasted Java JVM parser
Proxy similar to local proxy
4x to 5x faster than QBit REST/HTTP (should be 10x faster) 400K TPS (800K messages a second)
Program to interfaces. Simple.
A service can have a remote and local proxy interfaces
Metadata provider (creates large catalog of metadata about services used for REST mapping calls) (Replaced older hackier way)
REST end point to see status of internal services (rudimentary http page as well)
Auto-register health checks with services
Auto register rudimentary stats with services (counts, sampling for timing, creation, queue size, etc. Periodic low over-head)
Pub/Sub events (works with service queue lib to deliver events) (20M TPS)
Easy to use api, register(), subscribe(), consume()
Internal app messaging. Used by ServiceDiscovery for example.
You could use to create workflows, or just to monitor an event
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.
You do not have to use the proxy channel. A channel name can be any String.
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.
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.
Tracks counts, timings, and levels
Can be clustered (with QBit ServiceDiscovery service and Console)
Can be integrated with StatsD
Can be used to implement things like high-speed rate limiting based on header
Can be used to implement things like track system and implement back pressure cool off
Keeps track of services
Lets you find services
Lets you know when services have been added or removed
Removes services that are unhealthy
Uses Consul.io, but can also just poll a JSON file for easy integration with Consul or etcd, (Chef push), etc.
Internal single node tracking (single node meaning process)
Tracks N number of internal health nodes
Services can auto-register with the health system.