Стоит отметить, что в Garnet, в том числе, не работает lua, а если вы плотно используете redis (не только get/set), то скорее всего lua команды тоже уже используются.
Добавьте трассировки чтобы отслеживать прохождение вашего запроса через набор микросервисов. Трассировки позволят найти узкое место или удивиться что вместо одного запроса вы шлете N.
Кроме retry еще посмотрите на circuit breaker, иначе, возможно, вы создадите ненужную нагрузку при сбое.
Сделайте включаемым сбор лога тела запросов/ответов, так как иногда нужны не только метрики времени и статусов, но и разбор причин ошибок. А постоянный лог не всегда нужен/возможен/добавляет тормоза.
Я когда уходил из такой гос. структуры как раз поднимал вопрос о ЗП. Тогда она была ниже в 2-3 раза ниже отрасли. Долго обсуждали с руководством и пришли к выводу, что поднять ее в 2 раза все-таки сложно, но можно (правда она будет выше чем у самого руководителя). В итоге я все-таки ушел, но IT-шникам ЗП подняли.
В этой области действительно очень много зарегулированности и борьбы за цифры. Если цифры снижаются, то обычно кто-то должен уволиться или сесть, так как обязательно должен быть крайний.
ФАПы нельзя закрывать, так как должен расти показатель обеспеченности медицинской помощью. При этом нужно не только помещение (которое на деле может быть полностью разрушенным), но и персонал, который в этот ФАП не загонишь работать даже с учетом подъемных выплат.
Поднять ЗП или обновить технику тоже бывает не всегда можно. На всё должна быть бумажка, в том числе ограничивающая возможные позиции для закупки. Иначе придет прокуратура и спросит и за высокую ЗП айтишнику и за закупку мощной техники (ведь у них в прокураторе еще 286 работают и ничё).
И таких вилок в отрасли очень много.
А по поводу СЭМД ситуация наоборот радует. Ведь подделывать документы это не тоже самое что подделывать отчеты. За поддельные документы прокуратура может хорошо раскрутить. В итоге отчеты имеют тенденцию становиться более правдоподобными и проверяемыми.
А некоторые которые принимают заказ и начинают ее видеть просто стоят на месте, а у тебя заказ принят и ты как дурак стоишь и ждешь этого нехорошего человека.
Без чтения исходного кода, где собственно этот setByPath и используется было не понятно как произошло загрязнение. Можно было подумать на bodyParser, но оказывается там есть метод `app.put('/', (req, res) ...` где собственно всё и происходит.
Безусловно, в разных реализациях верны разные решения. Я всецело за гибкость в разработке. И у меня был опыт когда мне нужно было писать свой построитель запросов (во времена Delphi и отсутствия ORM). И сейчас есть проекты с БД, в которых никакой фиксированной схемы данных нет и нет ORM.
Я лишь утверждаю, что позиция, что "раз у меня негативный опыт с ORM, то и вам он не нужен" не верна. Для каждой задачи свой инструмент.
Вы исторически сидели на Oracle, но он взял и ушел из РФ
Вы продаете продукт, который может работать в локальных установках и используете для простоты установки SQLite/Firebird, а может работать для крупняка, где не сложно и заморочиться с настройкой и установкой серьезной СУБД
Да, для сложных запросов (подзапросы, функции) ORM не подходит, но такие случаи можно как-то особо обработать. Зато, если всё-таки ORM используется, то обычно перейти между разными СУБД довольно просто, как и поддерживать несколько СУБД в проекте.
Спасибо. Судя по тому как вы ответили, то можно просто заменить кафку на YDB и не переписывать клиентские приложения в части протоколов обмена. При этом мы получим новые эксплуатационные возможности и снизим требования к серверам в части объемов хранения. Если так, то это просто замечательная информация.
А тут точно речь не наоборот? Недобросовесные финансисты откроют продукты в виде незастрахованного вклада под большой процент, на которые поведётся население. Как население пылесосит деньги?
Да я собственно тоже считаю, что не будут они никуда звонить.
Альтернативой смс могла бы стать доставка через мессенджер, но тут тоже всё не просто. Единого мессенджера нет, а в ряде мессенджеров нет штатных механизмов доставки бизнес уведомлений.
В Китае, насколько я знаю, wechat решает все проблемы.
Взяли сильно большую тему и не до конца углубились в каждую задачу.
У меня в практике сложился следующий подход к выбору технологий:
Если это публичный сервис, то делаем REST-api + openapi (swagger) + валидация входных данных (а на тестовых средах и валидация выходных).
Если это внутреннее синхронное нагруженное взаимодействие, то gRPC
SOAP только если это legacy или просто такие требования (федералы любят)
Для отправки асинхронной задачи (и если ее не страшно потерять), если сервисы подключены к общему кешу Redis, то pub/sub через Redis
Для отправки асинхронных уведомлений (задач) множеству подписчиков - Kafka
В производительности, репликации, кластеризации, малом функционале относительно redis.
Стоит отметить, что в Garnet, в том числе, не работает lua, а если вы плотно используете redis (не только get/set), то скорее всего lua команды тоже уже используются.
Можно еще добавить:
Добавьте трассировки чтобы отслеживать прохождение вашего запроса через набор микросервисов. Трассировки позволят найти узкое место или удивиться что вместо одного запроса вы шлете N.
Кроме retry еще посмотрите на circuit breaker, иначе, возможно, вы создадите ненужную нагрузку при сбое.
Сделайте включаемым сбор лога тела запросов/ответов, так как иногда нужны не только метрики времени и статусов, но и разбор причин ошибок. А постоянный лог не всегда нужен/возможен/добавляет тормоза.
Насколько мне известно, в 2.5
Не совсем понял вопрос.
Я когда уходил из такой гос. структуры как раз поднимал вопрос о ЗП. Тогда она была ниже в 2-3 раза ниже отрасли. Долго обсуждали с руководством и пришли к выводу, что поднять ее в 2 раза все-таки сложно, но можно (правда она будет выше чем у самого руководителя). В итоге я все-таки ушел, но IT-шникам ЗП подняли.
В этой области действительно очень много зарегулированности и борьбы за цифры. Если цифры снижаются, то обычно кто-то должен уволиться или сесть, так как обязательно должен быть крайний.
ФАПы нельзя закрывать, так как должен расти показатель обеспеченности медицинской помощью. При этом нужно не только помещение (которое на деле может быть полностью разрушенным), но и персонал, который в этот ФАП не загонишь работать даже с учетом подъемных выплат.
Поднять ЗП или обновить технику тоже бывает не всегда можно. На всё должна быть бумажка, в том числе ограничивающая возможные позиции для закупки. Иначе придет прокуратура и спросит и за высокую ЗП айтишнику и за закупку мощной техники (ведь у них в прокураторе еще 286 работают и ничё).
И таких вилок в отрасли очень много.
А по поводу СЭМД ситуация наоборот радует. Ведь подделывать документы это не тоже самое что подделывать отчеты. За поддельные документы прокуратура может хорошо раскрутить. В итоге отчеты имеют тенденцию становиться более правдоподобными и проверяемыми.
А некоторые которые принимают заказ и начинают ее видеть просто стоят на месте, а у тебя заказ принят и ты как дурак стоишь и ждешь этого нехорошего человека.
Без чтения исходного кода, где собственно этот setByPath и используется было не понятно как произошло загрязнение. Можно было подумать на bodyParser, но оказывается там есть метод `app.put('/', (req, res) ...` где собственно всё и происходит.
Против природы не пойдёшь
Безусловно, в разных реализациях верны разные решения. Я всецело за гибкость в разработке. И у меня был опыт когда мне нужно было писать свой построитель запросов (во времена Delphi и отсутствия ORM). И сейчас есть проекты с БД, в которых никакой фиксированной схемы данных нет и нет ORM.
Я лишь утверждаю, что позиция, что "раз у меня негативный опыт с ORM, то и вам он не нужен" не верна. Для каждой задачи свой инструмент.
Вы исторически сидели на Oracle, но он взял и ушел из РФ
Вы продаете продукт, который может работать в локальных установках и используете для простоты установки SQLite/Firebird, а может работать для крупняка, где не сложно и заморочиться с настройкой и установкой серьезной СУБД
Для проблемы 2 можно сделать view, которая будет использовать что нужно, в том числе табличные функции, а в приложении сделать модель на view.
А на моей такое случается довольно часто. Особенно сейчас для разработки в РФ это актуально если были не на постгрес.
Да, для сложных запросов (подзапросы, функции) ORM не подходит, но такие случаи можно как-то особо обработать. Зато, если всё-таки ORM используется, то обычно перейти между разными СУБД довольно просто, как и поддерживать несколько СУБД в проекте.
Спасибо. Судя по тому как вы ответили, то можно просто заменить кафку на YDB и не переписывать клиентские приложения в части протоколов обмена. При этом мы получим новые эксплуатационные возможности и снизим требования к серверам в части объемов хранения. Если так, то это просто замечательная информация.
Судя по документации YDB топики практически тоже самое что кафка топики? Есть ли какие-то значимые различия?
А тут точно речь не наоборот? Недобросовесные финансисты откроют продукты в виде незастрахованного вклада под большой процент, на которые поведётся население. Как население пылесосит деньги?
Да я собственно тоже считаю, что не будут они никуда звонить.
Альтернативой смс могла бы стать доставка через мессенджер, но тут тоже всё не просто. Единого мессенджера нет, а в ряде мессенджеров нет штатных механизмов доставки бизнес уведомлений.
В Китае, насколько я знаю, wechat решает все проблемы.
Домохозяйкам TOTP сложно понять