Architecture
Navitia is made up of 6 main modules:
- Kraken is the c++ core
- Jörmungandr is the python frontend
- Tÿr is the back-office boss
- Brokk, the postapp, is able to take and deliver all messages between all components
- Ed is the postgres database
- Chaos can feed Navitia with disruptions on generic objects
- Kirin can feed Navitia with real-time informations
The reserve team, shown on the previous diagram, is made up of:
- osm2ed which can fill Ed with some nodes and ways form OpenStreetMap database (take extracts from openstreetmap extract form geofabrik for example)
- NTFS2Ed (fusio2ed in codebase) which is able to put public transport data (NTFS format) into Ed.
- GTFS2Ed which is able to put public transport data (GTFS format) into Ed.
⚠️ gtfs2ed will soon be replaced by our gtfs2ntfs converter, please check navitia_model - Perturbation connectors whose job is to translate different kinds of perturbations into navitia's model
- Ed2Nav which has the right to feed Kraken with a specific file called "data.nav.lz4"
- nav2RT which is describe below...
Jörmungandr is the web service frontend. Spelling out request, it chooses the right worker (the right Kraken instance, but maybe another kind of worker in the future), requests it, waits for the answer and formats the right response. Jörmungandr is multitenancy: its lonely instance handles every Kraken instance and the reddis data cache. It could soon thereby process journeys between distinct Kraken workers. Jörmungandr also makes messages to store statistical data.
Kraken is the intelligent service :-). It plans journeys, finds times, processes isochron... One Kraken instance handles a specific region. Jormungandr can manage many Kraken, each one stands for a region. So: Jormungandr can be load-balanced, Kraken can be load-balanced, and Jormungandr can manage many distinct regional Kraken. Huh ?
Brägi is the service that abstract Elasticsearch to Jormungandr. It searches addresses, POIs, and cities in the database in order to make autocomplete stuff.
We like to call the navitia instance of rabbitMQ "Brokk". It assumes most of the exchanges between navitia components. The only exception is the communication between Jormungandr and Kraken, which uses zmq for performance purposes.
There is only one shared exchange for every Kraken instance. The topic defines every targeted instance.
The default Exchange is called "navitia". Every application has to create the exchange before using it, using the following configuration:
type : topic
durable: True
Every message sent must be associated with a specific topic (routing_key):
- For real-time, the format is as follow: "realtime.contributor"
- For intra-instance communication, the format is as follows "instance_name.type.etc". For example, Tÿr sends a reload message to Kraken with the following key: "instance_name.task.reload"
https://github.com/CanalTP/chaos
Chaos is the web service which implements disruptions aspect of Navitia.
https://github.com/CanalTP/kirin
Kirin receives real-time events via Brokk in order to record them from the exchange to Ed database. It thereby manages real-time fail-over. It only SQL-persists real-time event (from the exchange to Ed): every Kraken instance is feeding straight by Brokk.
Related connectors (like Chaos) have to transform specific formats into the Navitia diagram model and to publish results on Brokk.
Every real-time provider is associated with a topic, formatted as "realtime.provider". Specific real-time connectors (as the upcoming ws Chaos) publish their event on the global RabbitMQ exchange ("navitia" by default) using their topic. All subscribers can then receive these events.
ED is the main database, which stores
- theorical, adaptative and real-time public transport data
- geographical and geocoding data
To fill Ed, there are many connectors (gtfs2Ed for example). Some could need small databases to work: in that case, those small databases do not stand in Ed. Ed is pure ;-)
The database engine is postgresql with postgis extension. The database model will come very soon (we're currently working on it...)
gtfs2ed feed Ed with gtfs file. Ed can store more specific object properties than gtfs: accessibility data, comments, specific on-demand-transport data, traffic policy... All of them are shown in the Ed database model. If you need one piece of that kind of data which is not managed by gtfs, you will need to produce another connector, and to append it in Tyr (like fusio2ed which manages NTFS transport data format, for example).
(whom real name should be nav2RT2nav, but...) nav2RT reads real-time data in Ed, then reads planned data from the "data.nav.lz4" files and then write a new "data.nav.lz4" with some structuring perturbations (like a re-structured tramway route after a broken catenary). Every Kraken subscribing the concerned region will be fed by this new "data.nav.lz4"
https://github.com/CanalTP/navitia-stat-persistor
Very simple component which can persist every request/response (transiting via Brokk/RabbitMQ) in a PostgreSQL database.