Ситуация следующая: есть написанный proof of concept системы, работает достаточно стабильно для того, чтобы за него можно было посадить специалистов предметников и собирать с них отзывы и предложения по работе системы. Соответственно у меня появилось время подумать над дальнейшей архитектурой и возможно что и переписать некоторые куски.
Дано: система для медиков (хирургов, анестезиологов, реаниматологов), занимается отслеживанием состояния пациента в ходе некоторого процесса (реанимации/операции). Процесс может быть длительным, от пары часов до чуть ли не года и имеет кучу всякого вычислимого состояния. В течении процесса происходит довольно много событий, некоторые из которых надо просто сохранить в базе и показать на клиенте, а некоторые из которых приводят к куче пересчетов текущих показателей процесса. Пример события 1 - пришли от прибора данные по текущему давлению. Их надо просто сохранить в базу и возможно что обновить график на клиенте. Пример события 2 - пациенту поставили капельницу. Надо не просто сохранить событие, а начать пересчитывать энное количество показателей (баланс жидкостей, солевой баланс, общие дозы введенных препаратов, отметить использование расходников итд).
Как сделано сейчас: Написано все на яве. Данные от приборов собираются одним процессом и пихаются в apache kafka. Основной процесс данные оттуда собирает, сохраняет в субд (mongodb) и если надо - распихивает по клиентам через вебсокеты. Так же основной процесс держит кучу rest сервисов, через которые работает веб-клиент и возможно что в дальнейшем - приложения под андроид/иос/винду. Все вычисленное состояние по процессам хранится в zookeeper-e, что в теории дает отказоустойчивость и возможность параллельного запуска нескольких сервисов на разных машинах.
Что напрягает и хочется переделать:
1 - Монга. С одной стороны довольно неплохо подходит для хранения «сырых» данных, с другой стороны приложение работает не только с ними, а еще и с кучей всяких справочников, данных процесса итд,которые довольно сильно перевязаны между собой, что в отсутствии внешних ключей дает кучу геммороя и лишнего кода на сервере.
2 - Кафка. Довольно капризное поделие с неплохой идеей, но вот реализация имхо хромает. Ловил ситуации конфликтов в zk на ровном и не очень месте, проблемы с переподключением consumer-a после разрыва связи и много чего еще. Плюс она требует наличия еще и отдельного zk, т.е. система получается довольно монструозной, минимум 4 отдельных процесса (получатель данных, кафка, zookeeper, основной сервер) + субд. А это сложности с развертыванием, поддержкой итд.
3 - В голове бродят мысли про то, что в такой событийно ориентированной системе вполне возможно что было бы неплохо использовать готовую реализацию акторов (akka?), а не писать свои велосипеды.
Собственно вопрос - как бы вы сами писали такую систему?
