да, поэтому я выше написал, что реплики и будет zero down time при обновлении переменных.
про наблюдаемость, сейчас пришли к понятию configmap в kubernetes, довольно удобная вещь, можно удобно просматривать переменные, работать с gitops итд, формировать их хоть руками, хоть через ansible и переопределять для контейнера, но не секьюрно конечно же, особенно если это настройки подключения к системам
В Спринге это проблема.
Есть ещё spring cloud режим с refresh аннотацией, но без cloud было бы проще.
Бин пересоздать та ещё проблема. Потому через базу разве что читать.
Вообще в системах уже как бы 12factor app и best way хранить в env properties и 3 replicas для rolling update изменений без этих велосипедов.
Единственная сложность это шифрование. Нужно будет заморочиться над интеграцией в vault или aes для secrets, который по дефолту не включён.
Но как консьюмить миллионы топиков?
Продюсеру то все равно. Открыл соединение и если указать в настройках Кафки, что автосоздавай топики, то по user id писать.
Скорее корректнее разбивать на partitions где key будет user id
Сложнее задача когда нужно разделить очередь на под очереди.
Чтобы сыпались ивенты в систему, а процессились у каждого пользователя свои под очереди в той последовательности в какой они сохранились.
Проще всего здесь использовать базу данных и пулить раз в х секунд с группировкой по пользователю.
А возможно ли реализовать подочереди для пользователей с одним инстансом?
Чтобы задачи выполнялись параллельно, но пользовательские задачи выполнялись одна за одной
А для usdt?
Биткоин принимать и отправлять просто.
С эфиром сложнее. Особенно токены.
Выдал клиенту eth адрес, туда насыпали usdt, а вот вывести оттуда без эфира нельзя. Нужно досылать эфир и выводить на общий адрес с которого можно сделать отправку.
Elk/opendistro, graylog, loki, fluentd.
с ui везде вопросы. Взять тот же Loki, инструмент визуализации метрик - grafana.
Часто нужна сложная аналитика паттернов, которыми хвалятся проприетарные и даже elk
>>Особенно, на фоне loki.
он ок для простых свистоперделок, не более.
Datadog - хорошая альтернатива, если не сильно много логов. Нет требований к размещению сервера внутри периметра.
Да. Не нужны высокодоступные распределенные локи
1
Ещё dynamodb не хватает в тесте.
Очень популярное решение
про наблюдаемость, сейчас пришли к понятию configmap в kubernetes, довольно удобная вещь, можно удобно просматривать переменные, работать с gitops итд, формировать их хоть руками, хоть через ansible и переопределять для контейнера, но не секьюрно конечно же, особенно если это настройки подключения к системам
В Спринге это проблема.
Есть ещё spring cloud режим с refresh аннотацией, но без cloud было бы проще.
Бин пересоздать та ещё проблема. Потому через базу разве что читать.
Вообще в системах уже как бы 12factor app и best way хранить в env properties и 3 replicas для rolling update изменений без этих велосипедов.
Единственная сложность это шифрование. Нужно будет заморочиться над интеграцией в vault или aes для secrets, который по дефолту не включён.
SRP так и работает.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
Data/Case классы как по мне наиболее ожидаемое.
С Null правда ещё сложно, хоть и есть optional.
Чуть синтаксиса со стримами и make Java great again.
Но как консьюмить миллионы топиков?
Продюсеру то все равно. Открыл соединение и если указать в настройках Кафки, что автосоздавай топики, то по user id писать.
Скорее корректнее разбивать на partitions где key будет user id
Все верно. А иначе разве что динамически создавать топики под пользователя.
Но если много топиков, то это шардинг топиков
Сложнее задача когда нужно разделить очередь на под очереди.
Чтобы сыпались ивенты в систему, а процессились у каждого пользователя свои под очереди в той последовательности в какой они сохранились.
Проще всего здесь использовать базу данных и пулить раз в х секунд с группировкой по пользователю.
Чтобы задачи выполнялись параллельно, но пользовательские задачи выполнялись одна за одной
В Нидерландах все ок. Не надо тут
Также можно использовать expressjs для nodejs
А для usdt?
Биткоин принимать и отправлять просто.
С эфиром сложнее. Особенно токены.
Выдал клиенту eth адрес, туда насыпали usdt, а вот вывести оттуда без эфира нельзя. Нужно досылать эфир и выводить на общий адрес с которого можно сделать отправку.
Какой то набор анти паттернов.
Спринг для демо
Get для приема сообщений
А внутри так вообще — тьма