-
Notifications
You must be signed in to change notification settings - Fork 19
Architecture
(An updated diagram is coming shortly.)
In order to make a useful service, we need to define the design priorities for the Xmidt service.
- High Availability
- Massive Scale
- Able to Scale Orthogonally
- Performance
Given these design priorities, we are able to easily make consistent and aligned decisions throughout the process of developing all the parts that make up XMiDT.
At a high level, each of the components (server or otherwise) perform generally one task so they can independently be scaled with minimal impact to other components. Additionally, this design pattern affords the project the ability to more easily add or re-configure itself with less impact to individual components.
Parodus is the client device broker. It is tasked with connecting up to the specified fabric.xmidt.example.com
URL so that it can be managed as well as provide near real time upstream data. Parodus also has hooks to provide for acquiring JWT credentials to present to Talaria upon connection. After connection, it's role is to maintain connection to the XMiDT cluster at all times as well as shuttle messages between a client and the cluster.
At the other end of the Parodus connections is a collection of Talaria machines. Their job is to keep the connections open to the devices and pass messages to and from the device. A small amount of JWT authorization checking is done in Talaria to ensure the device is allowed, as well as keeping the Consul cluster up to date with it's existence.
Petasos machines are a redirector service based on a consistent hash. The Petasos machines for a data center/region/zone communicate with Consul to determine the number of Talaria machines. Once it knows the Talaria count, it can perform a hash based on the device-id
of the incoming device to determine where in the cluster the device should go. An HTTP redirection response is sent to the device which then connects directly to the target Talaria.
For outward bound events (flow only one direction), Caduceus provides the needed protection of the XMiDT cluster from the demands of the servers in other services that ultimate wish to consume the events. Delivery is attempted for all events & Caduceus handles both slowly consuming clients as well as scaling to very large clients.
The XMiDT API is served by Scytale. The basic job of this machine is to authenticate the cloud caller, accept the request and fan out the request to all possible Talaria machines that are targeted by the request. If an XMiDT cluster is deployed in 3 separate data centers for high availability, Scytale will be configured (either directly or through Consul) to forward a request to a particular device to the 3 possible Talaria machines where the device could reside.