The architecture chapter describes the overall architecture of Eclipse Ditto and in detail which sub-components fulfill which responsibilities.
Top level component view
This overview shows the Ditto services (components), the externally provided and consumed API endpoints, the external dependencies (MongoDB and nginx) and the relations of the services to each other.
The components have the following tasks:
- Policies: persistence of Policies
- Things: persistence of Things and Features
- Things-Search: tracking changes to
Things,Features,Policiesand updating an optimized search index + executes queries on this search index - Concierge: orchestrates and authorizes the backing persistence services
- Gateway: provides HTTP and WebSocket API
- Connectivity:
sends Ditto Protocol messages to external message brokers and receives messages from them.
Supported transport protocols are AMQP 1.0 (e.g. Eclipse Hono), AMQP 0.9.1 (e.g. RabbitMQ), MQTT 3.1.1 (e.g. Eclipse Mosquitto), plain HTTP or Apache Kafka 2.x.
Components
Ditto consists of multiple “microservices” as shown in the above component view.
A “microservice” in Ditto is defined as:
- has its own data store which only this microservice may access and write to
- has an API in form of signals (commands, command responses, events)
- can be accessed by other services only via the defined signals
Communication
All microservices can communicate asynchronously in a Ditto cluster. Communication is done via Akka remoting which means that each service acts as server, providing a TCP endpoint, as well as client sending data to other services.
Therefore, it is required that all Ditto microservices can reach each others port 2551.
Another consequence is that all messages which are sent between Ditto microservices are in a way serializable and deserializable. All Ditto signals can be serialized from Java objects to JSON representation and deserialized back from JSON to Java objects.