А вам спасибо за ответы) Видимо, поддержка платформы мастхэв, а то нам приходится дежурить по очереди. Только судя по специфическим кейсам обращений такую поддержку вряд ли получится покрыть инструкциями, и ее сотрудник будет мало отличаться от разработчика) Но, честно говоря, мы и не пробовали, может постепенно и можно подготовить людей.
Спасибо за подробную статью! Но уже не в первый раз читаю про Pact, и пока никак не осознаю от какого класса ошибок он защищает. Допустим, изменил ты контракт сервиса, перегенерил клиентов в вызывающих его сервисах, откуда может возникнуть несоответствие?
А в итоге, кто разбирается с падениями джоб? У вас же тоже рядовые разраб-ки не умеют в gitlab-ci, докер, кубер и что-то там argo-like? Не атакуют разработчиков платформы?) И заметил, что разраб-ки сервисов имеют возможность контролировать ресурсы в кубере, они прям реально что-то там замеряют и тюнят под МР-, препрод-, прод-стенды? Или всем проставляется дефолт при создании сервиса и, максимум на проде как начинает торомозить, что-то себе увеличивают?
Так ведь эта особенность c процессами под подключение жесткий такой косяк postgres, разве нет? Настолько, что сам по себе сервер мало лишь кто юзает, всегда в связке с пулером?
До сих пор страдаем с лимитом подключений кластера, пытаясь распределить их между юзерами. В mssql с его потоками даже не задумывались о такой проблеме, про пул воркеров вообще узнал, когда полез разбираться, почему там в этом плане все тип-топ)
P. S. А, и бэкап только кластера целиком та еще фича)
В яндексовом pg этот лимит резервируется за юзером и невозможно завести новых юзеров, превысив max_connections. Что очень мешает, когда на кластере у нас 100 БД, каждая со своим юзером, нагрузки никакой, т. к. тестовый кластер, а соединения никогда не используются по максимуму одновременно. Скорее наоборот, полчаса в день работы под каждым юзером)
Какой же тогда смысл в этой настройке в чистом pg? Как я понял, суть в том, чтобы один юзер не мог все соединения сервера захватить. Т. е. в managed postgres от Яндекса, она хотя бы работает)
Выше ответил, не знаю или вы следите за всей темой: у обычного pg тоже есть такие лимиты у юзеров, и больше max_connections вряд ли получится использовать. Может все выставляют -1 и не подозревают)
Расскажите, как быть с лимитом соединений на юзера? Его надо выставлять сразу при создании пользователя, который может потреблять пару часов в сутки свой максимум, а в остальное время впустую занимать лимит, при том, что новых пользователей уже нельзя будет завести, хотя ресурсы фактически свободны. Понимаю, что там в pg трэш с обработкой запросов процессами и этими приблудами-пулерами, но как с этим жить вообще после божественного ms sql?)
Все мимо: и не минусовал, и статью прочел целиком, правда со второго раза, когда понял по комментам, что происходит нечто загадочное)
Ваша цитата:
разработчики бэкэнда должны будут изменить описание интерфейса и опубликовать его новую версию
Это что по-вашему, как не генерация клиента для API, пускай без кода методов, но описания dto-шек-то как обновятся, да и набора методов? И что прикажете, для каждого вызывающего сервиса этим заниматься? Это вовсе не ответственность разработчиков API.
Ок, имеем один сервис, который выступает бэком для фронта, а может и не только фронта. А еще десятки сервисов, которые дергают друг друга, в особо сложных случаях еще и написанных на разных языках. Сваггер полностью закрывает вопрос описания их API и генерации клиентов. Вы же предлагаете бэкендерам поддерживать непонятно как генерируемый абсолютно чуждый для них .tsc-файл. План надежный, как сами знаете что)
Ну это все описание последствий, а невролог-то в итоге, что сказал? Причина какая, и почему не устранили? А то у меня дочка по ночам скрежещет, в глисты тоже не верю, но к кому с этим идти так и не определился. Стоматологи открещиваются)
А вам спасибо за ответы) Видимо, поддержка платформы мастхэв, а то нам приходится дежурить по очереди. Только судя по специфическим кейсам обращений такую поддержку вряд ли получится покрыть инструкциями, и ее сотрудник будет мало отличаться от разработчика) Но, честно говоря, мы и не пробовали, может постепенно и можно подготовить людей.
Спасибо за подробную статью! Но уже не в первый раз читаю про Pact, и пока никак не осознаю от какого класса ошибок он защищает. Допустим, изменил ты контракт сервиса, перегенерил клиентов в вызывающих его сервисах, откуда может возникнуть несоответствие?
А в итоге, кто разбирается с падениями джоб? У вас же тоже рядовые разраб-ки не умеют в gitlab-ci, докер, кубер и что-то там argo-like? Не атакуют разработчиков платформы?) И заметил, что разраб-ки сервисов имеют возможность контролировать ресурсы в кубере, они прям реально что-то там замеряют и тюнят под МР-, препрод-, прод-стенды? Или всем проставляется дефолт при создании сервиса и, максимум на проде как начинает торомозить, что-то себе увеличивают?
Напоминает платформы для микросервисов в Авито и Сбере: вдохновлялись или до всего сами дошли?
Согласен, хотелось бы подробностей, почему refresh не опасно отдавать злоумышленнику, если только его достаточно, чтобы получить новый access.
Так ведь эта особенность c процессами под подключение жесткий такой косяк postgres, разве нет? Настолько, что сам по себе сервер мало лишь кто юзает, всегда в связке с пулером?
До сих пор страдаем с лимитом подключений кластера, пытаясь распределить их между юзерами. В mssql с его потоками даже не задумывались о такой проблеме, про пул воркеров вообще узнал, когда полез разбираться, почему там в этом плане все тип-топ)
P. S. А, и бэкап только кластера целиком та еще фича)
Добрый день!
А можно тут поподробнее? Заполнять план задним числом? Или просто отставать/опережать на квартал по документам?
Это же рецепт идеального agile - спокойно делать задачи по приоритетам, а на планировании заполнять следующий спринт итогом предыдущего)
Как-то не очень похоже, что все в порядке)
Пока видно, что СДЭК занимается чем угодно, только не доставкой уже оформленных посылок.
В яндексовом pg этот лимит резервируется за юзером и невозможно завести новых юзеров, превысив max_connections. Что очень мешает, когда на кластере у нас 100 БД, каждая со своим юзером, нагрузки никакой, т. к. тестовый кластер, а соединения никогда не используются по максимуму одновременно. Скорее наоборот, полчаса в день работы под каждым юзером)
Какой же тогда смысл в этой настройке в чистом pg? Как я понял, суть в том, чтобы один юзер не мог все соединения сервера захватить. Т. е. в managed postgres от Яндекса, она хотя бы работает)
Выше ответил, не знаю или вы следите за всей темой: у обычного pg тоже есть такие лимиты у юзеров, и больше max_connections вряд ли получится использовать. Может все выставляют -1 и не подозревают)
Что-то сомневаюсь, что pg при max_connections = 100, например, даст завести 10 юзеров с connection limit = 20.
В ms sql - нет, а в pg - есть. И непонятно, как в этом треде 1С очутился)
Расскажите, как быть с лимитом соединений на юзера? Его надо выставлять сразу при создании пользователя, который может потреблять пару часов в сутки свой максимум, а в остальное время впустую занимать лимит, при том, что новых пользователей уже нельзя будет завести, хотя ресурсы фактически свободны. Понимаю, что там в pg трэш с обработкой запросов процессами и этими приблудами-пулерами, но как с этим жить вообще после божественного ms sql?)
Все мимо: и не минусовал, и статью прочел целиком, правда со второго раза, когда понял по комментам, что происходит нечто загадочное)
Ваша цитата:
Это что по-вашему, как не генерация клиента для API, пускай без кода методов, но описания dto-шек-то как обновятся, да и набора методов? И что прикажете, для каждого вызывающего сервиса этим заниматься? Это вовсе не ответственность разработчиков API.
Не совсем понял. Сваггер генерит OpenAPI-контракт без привязки к языку. По нему уже, кому необходимо, генерит клиент, в том числе для ts.
Ок, имеем один сервис, который выступает бэком для фронта, а может и не только фронта. А еще десятки сервисов, которые дергают друг друга, в особо сложных случаях еще и написанных на разных языках. Сваггер полностью закрывает вопрос описания их API и генерации клиентов. Вы же предлагаете бэкендерам поддерживать непонятно как генерируемый абсолютно чуждый для них .tsc-файл. План надежный, как сами знаете что)
Почти в точку: если правильно понял, о ком речь из местных знаменитостей, то он пожарник)
Думал, там будет что-то типа: снизьте стресс, попейте магний) Хорошо, спасибо!
Ну это все описание последствий, а невролог-то в итоге, что сказал? Причина какая, и почему не устранили? А то у меня дочка по ночам скрежещет, в глисты тоже не верю, но к кому с этим идти так и не определился. Стоматологи открещиваются)