Давным-давно, в далекой га…… начиналось всё с одного сервера, написанного на java. Данный сервер реализовывал полный спектр задач:

1. Коммуникация с “железками” — получение замеров, статусной информации, телеметрия, конфигурирование инфраструктуры и т.п.;
2. Realtime обработка поступивших данных;
3. Агрегирование полученных данных;
4. Высокоуровневый интерфейс с клиентским софтом на базу RMI (клиент в те стародавние времена тоже был на java/netbeans rcp).

И было счастье, ибо всё работало и всех всё устраивало, пока в один прекрасный момент не пришёл заказчик, который не хотел клиентов на java и вообще не хотел desktop-клиентов, и вообще не хотел клиентов, а хотел интеграции со своей системой. И пришло осознание того, что дальше так жить нельзя, наш собственный клиент был переписан под web (HTML5/JS/OL), а на сервере был с почестями отрезан и похоронен RMI API и заменён на REST+WebSocket API (на базе Netty) и JSON как формат представления данных (на базе Jackson). Получившийся протокол получил внутреннее название RTLSCP (real track location system communication protocol).

И вновь наступило счастье – те, кто хотели получить только интеграцию сервера со своими системами, использовали RTLSCP API без каких-либо cross-платформенных заморочек, а те, кому был необходим готовый клиент, получали наш кастомизированный web-клиент.
Функционал системы рос (причём, в основном, за счет client-side хотелок), кодовая база сервера, соответственно, тоже росла, и однажды пришло осознание того, что пихать client-specific функционал в основной сервер не есть гуд, исходя из соображений стоимости поддержки получившегося комбайна. В связи с этим было принято решение вынести всю client-specific логику в промежуточный сервер, который будет общаться с основным по RTLSCP, проксировать его для внешних клиентов и, помимо этого, реализовывать дополнительную бизнес-логику и расширять протокол (это расширение получило название RTLSCP.Ext). Данный промежуточный сервер был написан на node.js с целью получения открытой легко расширяемой/модифицируемой на стороне заказчика системы.

Технология RealTrac тоже не стояла на месте, и с недавних пор начался лавинообразный рост запросов на добавление уже внутреннего функционала, связанного с освоением новых бизнес ниш. И на горизонте забрезжила тень проблемы, связанной с расширением функционала основного сервера с последующими трудозатратами на сопровождение полноценных высокоуровневых API в двух модулях системы — основном сервере и сервере приложений. С одной стороны, это позволяет поставлять основной сервер без сервера приложений, с другой стороны, имеет место дублирование функционала. И было решено отказаться от высокоуровневого API на стороне основного сервера, связав его с сервером приложений по простому внутреннему API, а высокоуровневый API оставить только на сервере приложений. В итоге функционал разделился так:

1. Основной сервер

1. коммуникация с “железками”;
2. весь цикл обработки “сырых” данных;
3. реализация всей низкоуровневой бизнес-логики;
4. хранение всех “сырых” и обработанных данных;
5. поддержка простого API для интеграции с сервером приложений;

2. Сервер приложений

1. поддержка простого API для интеграции с основным сервером
2. реализация всей высокоуровневой бизнес-логики;
3. поддержка высокоуровневого клиентского API.

Основные требования к новой архитектуре:

1. Модульная структура обоих компонент;
2. Минимизация трудозатрат по добавлению поддержки нового железа;
3. Минимизация трудозатрат по расширению структур данных;
4. Минимизация трудозатрат по добавлению новых функциональных модулей;
5. Возможность будущей кластеризации системы при сохранении легковесности;
6. Необходимость оставить решение cross-платформенным.

После множества измышлений и проведённых анализов мы пришли к выводу, что нужно строить систему на базе Vert.x как достаточно функциональном, но при этом легковесном решении, полностью отвечающим всем нашим запросам. Изюминкой стала возможность бесшовной интеграции основного сервера (java) и сервера приложений (nodejs) на базе общей шины событий, предоставляемой платформой Vert.x. По сути, два сервера будут работать в едином информационно-событийном поле, что как решает проблемы взаимодействия между ними, так и минимизирует проблемы по расширению функционала и/или масштабированию/кластеризации системы.
Переход на описанную архитектуру у нас только начался, и, что из этого в итоге выйдет — покажет время…