Тем более, на джаве я всё-таки чуть-чуть кодил, просто после шарпа возвращаться на неё это как пересесть на старую Ладу с новенькой иномарки: вроде ездит, но уже давно привык к другому уровню комфорта.
Гладко было на бумаге, да вот только зачастую нет альтернативе шине или чему-то мидлварному вроде нее. В больших компаниях, ну например банках, оч много АБС которые в силу разных причин проще связать с другой такой неповоротливой АБС, шиной, нежели вкручивать в эти АБС коннекторы к кафке. Ну например, АБС поставляет вендор для которого компания оплачивает N доработок в месяц за K рублей, и на квартал вендору поставлены уже более приоритетные задачи, а расширять договор - не бюджет и вообще долго и сложно. А еще, стоимость этих доработок у вендора, как правило: оверпрайс. А еще, иногда нужно синтегрироваться с системой на которой работают 2-3 человека которые не в ресурсе затащить коннектор в проект, но сваять вызов апи на корп шине коробочными средствами - вполне. В общем, жизнь - она сильно сложнее, чем слабая, маркетинговая статья на хабре.
Нет, нормально это обработать правильно ошибку на вызывающей системе, а это однозначно вредный костыль. Все начинает осязаться когда пытаешься в логах понять какую ошибку отдал вызывающей системе, или pdf логать тоже просто нормально?) Или костыли в убер обвяз для логирования какието пилить, в общем ничего нормально не вижу.
Согл, но это в целом как-то неестественно, по этому немного коробит)
Да в целом это на прикладе реализуется довольно просто, прокся тут как будто лишнее усложнение которое нужно мониторить/саппортить/апдейтить/etc. Может в вашей сфере типовой, в моей за 7 лет один раз встретился, не типовой, экзотический и странный, почему не сделать по человечески, не понятно.
Ну мы и делаем да =)
Нет, не правильно, правильно стабилизировать/доработать вызывающую систему, а не размазывать ее логику по нескольким системам и потом дорабатывать/саппортить эту логику на нескольких.
Идея мягко говоря так себе, правильное решение здесь стабилизировать/доработать АБС, разделить нагрузку связанную с формированием отчетов и бух. проводок по разным нодам, добавить ресурсов в конце-концов. Еще тут есть своя специфика, ну например все проводки одного операционного дня нужно уложить в систему до закрытия этого дня, а если не уложил уже проблема и нужны доп манипуляции со стороны подразделений учета чтобы все правильно учесть. Соответственно нельзя не грузить проводки в систему по тому что кто-то где-то утилизирует ее формированием каких-либо отчетов, по этому решение не может выглядеть так, ну прям совсем, ибо создает проблем больше чем решает.
Ну вообще конечно так и есть, что касается кафки у нас например полностью кастомный свой клиентский обвяз с transactional outbox, гибкой настройкой ретраев, отложенными отправками и так далее по списку. И подпиливать этот обвяз может каждый из команды, естественно с оглядкой на грейд, обсуждением с командой, плотным ревью и тестированием.
Ну например вы выгружаете отчетность для бухгалтерии в большой организации, на том конце отчет забирают тети которым нужно взять файл-выгрузку из вашей системы и загрузить его в какую-нибудь свою "коробку", которая дальше его както обработает и коробка по историческим причинам принимает исключительно эксельник.
Ну и кстати не так уж и долго, можно например сохранять файлик в xlsb, открываются они сильно бодрее и весят ощутимо меньше.
Ну устойчивую архитектуру от всего наверно сложно построить, тут скорее вопрос целесообразности, ведь от увеличения кол-ва девяток после запятой в SLA стоимость решения растет и далеко не линейно)
Добрый день! Ситуация такая что нод всего три и фактор репликации стоит 3, соответственно на всех трех нодах данные одинаковые, отсюда и ~ одинаковое кол-во сегментов и из этого же следует что количество memory-mapped областей на всех нодах меняется очень сходно, практически одинаково в рамках процесса Kafka. Ну и соответственно за рамки дефолтного придела все ноды вышли в примерно одно и тоже время - почему и упали также +- в одно время с разницей в пару минут.
Гладко было на бумаге, да вот только зачастую нет альтернативе шине или чему-то мидлварному вроде нее. В больших компаниях, ну например банках, оч много АБС которые в силу разных причин проще связать с другой такой неповоротливой АБС, шиной, нежели вкручивать в эти АБС коннекторы к кафке. Ну например, АБС поставляет вендор для которого компания оплачивает N доработок в месяц за K рублей, и на квартал вендору поставлены уже более приоритетные задачи, а расширять договор - не бюджет и вообще долго и сложно. А еще, стоимость этих доработок у вендора, как правило: оверпрайс. А еще, иногда нужно синтегрироваться с системой на которой работают 2-3 человека которые не в ресурсе затащить коннектор в проект, но сваять вызов апи на корп шине коробочными средствами - вполне. В общем, жизнь - она сильно сложнее, чем слабая, маркетинговая статья на хабре.
:D
Нет, нормально это обработать правильно ошибку на вызывающей системе, а это однозначно вредный костыль. Все начинает осязаться когда пытаешься в логах понять какую ошибку отдал вызывающей системе, или pdf логать тоже просто нормально?) Или костыли в убер обвяз для логирования какието пилить, в общем ничего нормально не вижу.
Согл, но это в целом как-то неестественно, по этому немного коробит)
Да в целом это на прикладе реализуется довольно просто, прокся тут как будто лишнее усложнение которое нужно мониторить/саппортить/апдейтить/etc. Может в вашей сфере типовой, в моей за 7 лет один раз встретился, не типовой, экзотический и странный, почему не сделать по человечески, не понятно.
Ну мы и делаем да =)
Нет, не правильно, правильно стабилизировать/доработать вызывающую систему, а не размазывать ее логику по нескольким системам и потом дорабатывать/саппортить эту логику на нескольких.
Идея мягко говоря так себе, правильное решение здесь стабилизировать/доработать АБС, разделить нагрузку связанную с формированием отчетов и бух. проводок по разным нодам, добавить ресурсов в конце-концов. Еще тут есть своя специфика, ну например все проводки одного операционного дня нужно уложить в систему до закрытия этого дня, а если не уложил уже проблема и нужны доп манипуляции со стороны подразделений учета чтобы все правильно учесть. Соответственно нельзя не грузить проводки в систему по тому что кто-то где-то утилизирует ее формированием каких-либо отчетов, по этому решение не может выглядеть так, ну прям совсем, ибо создает проблем больше чем решает.
Ну вообще конечно так и есть, что касается кафки у нас например полностью кастомный свой клиентский обвяз с transactional outbox, гибкой настройкой ретраев, отложенными отправками и так далее по списку. И подпиливать этот обвяз может каждый из команды, естественно с оглядкой на грейд, обсуждением с командой, плотным ревью и тестированием.
Ну нет, <SOME SYSTEM> умеет только в тело JSON передавать, сделайте пожалуйста как просят!
Адски плюсую
Опасность в том что разработчик может засунуть
sheet.autoSizeColumn(columnIndex);после формирования каждой строчки и тогда получается беда
Тут точно также, сначала трекинг, потом в конце:
sheet.autoSizeColumn(columnIndex);Самое главное отличие в том, что не все используют актуатор. Соответственно, без актуатора эта настройка неактуальна.
Ну например вы выгружаете отчетность для бухгалтерии в большой организации, на том конце отчет забирают тети которым нужно взять файл-выгрузку из вашей системы и загрузить его в какую-нибудь свою "коробку", которая дальше его както обработает и коробка по историческим причинам принимает исключительно эксельник.
Ну и кстати не так уж и долго, можно например сохранять файлик в xlsb, открываются они сильно бодрее и весят ощутимо меньше.
Ну устойчивую архитектуру от всего наверно сложно построить, тут скорее вопрос целесообразности, ведь от увеличения кол-ва девяток после запятой в SLA стоимость решения растет и далеко не линейно)
Добрый день! Ситуация такая что нод всего три и фактор репликации стоит 3, соответственно на всех трех нодах данные одинаковые, отсюда и ~ одинаковое кол-во сегментов и из этого же следует что количество memory-mapped областей на всех нодах меняется очень сходно, практически одинаково в рамках процесса Kafka. Ну и соответственно за рамки дефолтного придела все ноды вышли в примерно одно и тоже время - почему и упали также +- в одно время с разницей в пару минут.
Можно в закрытом контуре хостить ну или поисследовать продукт поглубже :D
Достойно!
Ну конечно уровень - бог, захватывающе) Если не секрет, каков был реворд?
Другой алгоритм? Можно, вот так:
EsiaSigner esiaSigner = EsiaSigner.builder()....signingAlgorithmSupplier(() -> "SOME ALGO")....build();Думаю что проблем не должно возникнуть с android'ом.
Артефакт залил с лицензией "The Apache License, Version 2.0", в реп добавлю, спасибо!