fli-iam / shanoir-ng

Shanoir (SHAring iN vivO Imaging Resources)
GNU General Public License v3.0
19 stars 21 forks source link

Microservices Architecture Optimisations #321

Open michaelkain opened 4 years ago

michaelkain commented 4 years ago

This misconceptions are not urgent, but shall be addressed in the next time to increase the stability of sh-ng for the future. Microservices architectures work as each microservices has its own domain model and understanding of this domain. Each microservice should be able to do its main work independently from the others, and what will happen, if another microservices falls, it should not directly impact the others to stop functioning too. Today in sh-ng, when we do an import of data, we ask ms studies to get the list of studies available for the import and where to put the data. As a result, when ms studies is down we can not do imports and ms import becomes useless too. To solve this issue, we should do the following: Both mss, studies and import, know the model of "study". ms studies has a complexe understanding of this model (all details + user-study-rights etc.) and ms import knows study name (unique) and nothing more. In the db both manage a study list, ms studies complexe and ms import very basic. When an import is done, the list of ms import is used and no communication happens between ms studies and ms import. The frontend talks with ms import. When a new study is created, changed or deleted with ms studies, a rabbitmq communication happens in the background to update the list of ms import. This has only advantages: when ms import is down, ms studies can operate and create studies, the main information is savely stored, rabbit mq messages are stored in rabbit mq (assumption, that rabbit mq is a stable tool, we we assume). When ms import comes back it is updated with the message. If ms studies is down, ms import can do imports.

jcomedouteau commented 4 years ago

Maybe we could use kind of a study cache (they are cool implementation of caches with Spring) => First time, we make a (rabbitMQ) call to msStudies to fill the StudyName cache => When a study is created / updated / deleted => The cache is evicted then renewed

Using this, we have only one interaction MSStudy => MSImport which is evicting the cache. I would find it cool to implement this using annotations and not lines of code inside ApiController / Service methods but I don't know if it's possible.

arthursw commented 4 years ago

All right it seems a good idea!