Архитектура для регионально распределенной очереди событий?
Волнует вопрос к подходу построения шины сообщений для офиса+филиалы. Суть проблемы:
1. Есть некий холдинг, в который входят разные юр лица
2. Бизнес у юр лиц - разный. Это может быть как производство, так и транспортные услуги.
3 Хочется иметь актуальную аналитику по всему холдингу здесь и сейчас
4. Как выход - сливать все данные в какую-то базу\шину\что-то только чтения и по этому хранилищу строить аналитику.
5. Есть требования - актуальность (здесь и сейчас), доступность, надежность
Как решение - просто все данные о проводках, допустим, сливать куда то в шину, откуда все это попадет в что-то колоночное для агрегации и откуда это будет читаться чем-то, что визуализирует в графики, дашборды и все такое.
Допустим, это kafka+vertica+tableau.
Но возникает вопрос - где расположить условную kafka? Допустим, если есть 1 офис и 2 филиала, при расположении kafka только в офисе, филиал может по причине отсутствия связи просто не достучаться. Потому хочется сделать условно 2 kafka - в офисе и филиале, но в связи с тем, что филиал может быть в 2 прихлопа 3 притопа, т.е. маленький - это будет уже оверхедом. Тем не менее, НЕ работать он не может, если вдруг связь упала. Значит событиям (сообщениям) где-то надо копиться, чтобы потом при восстановлении связи - все стало хорошо. У кого какой опыт и рекомендации на эту тему?(вопрос про архитектуру, нежели чем про выбор инструментов)
Две хранилки в ранесенных локациях с высокой доступностью, в филиалах резервный независимый канал (если данные обезличенные, можно через инет)
Типовой преднастроенный комплект (сервер+софт) типа Кеша в филиал, главное, чтоб был в режиме достал из коробки и заработал.
Тут ещё зависит от того, что есть сейчас. Проводки же уже как-то учитываются? Если в каждом филиале стоит свой уникальный софт (Пусть тот же 1с с уникальной конфигурацией), отличающийся от других, там все равно надо ставить какой-то адаптер данных.
И вам же нужно это только для статистики? Тогда реального времени не надо.
Валентин, да, во многих филиалах свой софт: где-то 1с, где-то самописное решение, аналогичное 1с.
По началу - для статистики, просто требования есть к получению этой статистики - до 4х часов задержки=мах.
Да, резервный канал - как один из выходов, наверное. Немного напрягает, что пользователю придется как-то сам на сам бороться в маленьком филиале в стиле: "Соединения нет - попробуйте позже". А в момент переключения события копить где-нить в том же надежном кэше(собственно, в бд приложения, почему нет?).
А если пользователь сможет в момент переключения не работать, то и вовсе копить не надо.
Валентин, в итоге, правильным решением было б разместить где-то высокодоступную шину(допустим, в яндекс облаке, амазоне и т.д) и начать с централизованной архитектуры+резервирование каналов. Потом по по ходу возникновения проблема их решать? Такой, риторический вопрос, конечно. Спасибо ;)
Простой
Средний
Средний
Простой
