Что имел ввиду автор, описывая красную дверь в своем произведении? Ваще неибу :) и не вижу смысла задумываться о публичных высказываниях разных пиздоболов.
Тут все уже сказали, поэтому я скажу про другое: вы путаете теплое с мягким и складываете все яйца в одну корзину, но это и не удивительно ввиду отсутствия инсайдерской инфы. А вот как было на самом деле (я в Сбербанке тоже не работаю, просто более осведомлен об определенных вещах).
Визуальной разработкой действительно занимались, но с BPMS она совершенно была не связана, никто Грефу ее не продавал и более того — он об этой теме никогда и не знал. Home-grown инструмент визуального проектирования ПО по мотивам популярных лет 20 назад DDD на основе UML и кодогенерации был разработан двумя энтузиастами в недрах одного из ЦК СБТ на основе некого программного продукта, используемого в некоей RAD-платформе, проданной руководству этого ЦК некоей известной в РФ консалтерской конторой на заре 2015г, когда не было никаких искусственных интеллектов, аджайлов и всего того из чего сейчас состоит Сбербанк. Этот инструмент должен был лечь в основу современной автоматизации процессов производства ПО [в отдельно взятом ЦК и зажечь огонь революции во всем мире], в начале 2017г этой темой занималась целая команда, но ее дальнейшая судьба в силу agile-трансформации перестала кого-либо волновать. Технологические причины, по которым этот инструмент был обречен на фееричный успех, вы в статье озвучили, nuff said. Однако главная причина была совсем не технического плана, но это уже совсем другая история.
Тема с заменой Pega тоже была, но никто бесплатный Activiti Грефу опять же не продавал, потому что он не занимается такими вопросами. Для этого у него был известный в узких кругах господин Хлызов, вот ему-то, в рамках формального процесса управления архитектурой и технологиями, в начале того же 2015г некая группа товарищей и показала презу на 100500 страниц где сравнивалось много разных BPMS и по результатам пилотирования выигрывал Activiti. Решением архитектурного совета Activiti принят как целевая BPMS, end of story. Никто не собирался использовать BPMN для кодогенерации [тем более Java-кода], а решение принималось компетентными в этом людьми после тщательного исследования вопроса.
Мораль сей басни только в одном: не всегда хорошая идея получает хорошую реализацию, но в любом случае, ваша статья — не более чем домыслы, основанные на слухах (перепутать BPMN и UML надо очень сильно постараться). В компаниях enterprise-уровня существуют методологии принятия технологических решений (неважно, плохие или хорошие). Никто показом красивых картинок топ-менеджерам ничего давно уже не продает, потому что все вменяемые люди знают про пилотирование и техническую экспертизу; любой из топ-10 банков ежегодно проводит десятки пилотов, из которых может быть один перерастает в опытное внедрение, из десятка которых может быть одно действительно завершается успешно.
«Ситуация, когда каждый программист при любом коммите в open source проект, должен задумываться о юридической безопасности своих действий, представляется нам стоп-фактором...»
Заменим слово «программист» словом «сотрудник», слово «коммит» словом «высказывание», а слово «open-source проект» — на «публичная площадка» и получим то, за что 146% подписавшихся под петицией и поставивших "+1" руководителей увольняют своих сотрудников (и что явным образом запрещено в регламентах любой крупной компании, впрочем, как и несогласованные коммиты в опен-сорс).
Не говоря уж о том, что смысл претензии не в опен-сорсе, а в пол-лярде долларов и правообладании, никакому развитию никакого рынка ПО она не мешает.
Ситуацию я осуждаю, но с высказыванием «программных комитетов» согласиться тоже не могу, как и поставить +1, т.к. не уполномочен на это пресс-службой своего работодателя.
А уж сколько в физике нерешаемых задач, ужас, одни Навье-Стокс или уравнения Эйнштейна чего стоят. И ничего, решают, численные методы используют, частные случаи, приближения, как и алгоритмические решения любых алгоритмически-неразрешимых задач дискретной математики.
Как можно заявлять о безусловной победе Стандартной модели как средства описания вообще всей физики в целом над Ньютоновской или Гамильтоновской механикой? Вот так и можно: пришли Нильс Бор, Макс Планк и еще человек 20 всяких там Эйнштейнов и Гейзенбергов и всем все популярно объяснили (при том что половина всей квантовой физики до сих пор остается очень сильно теоретической, а ее основы — «аксиоматичны и темны», особенно если брать теорию струн). В XIX веке это было немыслимо, а в XX веке это уже свершившийся факт, и, собственно, статья написана именно про это. Вы, видимо, совсем не поняли ее смысл, советую прочитать оригинал, т.к. перевод действительно посредственный.
Почитайте вашу же ссылку на английском языке, это ответит на все ваши вопросы: en.wikipedia.org/wiki/Entscheidungsproblem. Принятие решений — уже давно чисто алгоритмическая задача и никто в ней (как и в прочих задачах) не использует подходы, основанные на знаниях.
Не знаю как прочие читатели, а у меня высшее образование непосредственно в ИИ, и нам еще лет 15 назад в институте говорили те же слова как свершившийся факт: системы основанные на знаниях (всякие базы знаний, экспертные системы и прочая подобная фигня) умерли, это тупиковая ветвь науки, а будущее — за алгоритмическими методами (нечеткая математика, нейросети, кластерный анализ и пр). Полностью согласен с автором статьи.
Если погрузиться в архитектуру, то можно увидеть что паттерн CommandProcessor описан еще в GoF, а собственно любая реализация CQRS на практике сводится к обычной обработке событий, известной уже лет 20 (пресловутые EventDispatcherThread в свинге или флеше, или любом браузерном движке). Можно еще про WAL вспомнить.
Самая главная (и единственная) проблема ES/EDA в архитектуре веб-клиентов — отсутствие server push в HTTP — всегда раньше решалась использованием протоколов более низкого уровня, а сейчас — использованием websockets. Современные веб-приложения ориентируются на Reactive Streams (на HL++ в 2017 году даже был доклад про их использование в .net), лучше стараться думать в эту сторону, а не про паттерны имени Фаулера и прочих теоретиков.
Не привязываясь к тому, где и сколько кто-то работает или не работает, в статье ваши «требования» не озвучены, что свидетельствует об их отсутствии.
Если вы проводили испытания, то весь смысл написания этой статьи должен заключаться в статистике и метриках (как пример: habr.com/ru/post/351012). Но ниже Сергей в своем комментарии как бэ намекает на то, что у вас ничего нет. Получается что лично вы еще хуже знакомы с ситуацией.
Сергей, вы находитесь в четвертой итерации подсистемы управления параметрами в составе платформы ЕФС. Вы понятия не имеете, как на самом деле «этот сервис эволюционировал», а всего лишь сделали то, что в ней было еще в 2015 году, причем намного хуже (вертекс, акка, реактив, хранение в гите, вы серьезно?).
Были нагрузочные тесты, статистические исследования производительности, а у вас? Где метрики, где статистики? Что именно и как вы «разгоняли»? Взяли сравнили три совершенно не относящиеся к теме фреймворка и изобрели велосипед? Это позор и вам, и тем людям, кто пропустил эту статью.
А слона-то мы и не заметили. Planning poker и управление burndown — основные инструменты scrum, коий является единственной применимой в IT реализацией agile (ибо lsd, toc и прочий xp нигде и никем не используются ввиду своей излишней инновационности и/или ортодоксальности). Если ваши команды не используют ни то, ни другое, то я не очень понимаю, о каком реальном применении методологии вы рассказываете. Вы хоть scrum-колоду видели вживую?
Человек цитирующий сам себя тоже не светоч virtue. Что впрочем не отменяет того факта, что много лет назад подход к мотивации через KPI действительно был признан провалом в управлении. Что в свою очередь не отменяет того факта, что burndown — это самый настоящий KPI.
в Kafka все унифицировано, и разницы между Point-to-point и Publish-subscribe нет, в том числе и в API для программиста
Вот именно, поэтому режима ptp там нет в принципе (и более того, его очень сложно реализовать если вам нужны именно классические очереди с гарантированной доставкой и прочими ништяками, смотреть тут softwaremill.com/using-kafka-as-a-message-queue), а управление тем, кто и как получает сообщение, как раз и осуществляется посредством API программиста, а конкретно — через consumer groups, как вы ВНЕЗАПНО и узнаете ниже в статье :).
Так в топике можно сделать много партиций и посадить много читателей.
Число партишенов при этом должно быть не меньше числа консюмеров, иначе у вас будет consumer starvation.
В этот момент мы поняли: Kafka — это не совсем очередь.
А точнее, совсем не очередь ;).
Происходит ребаланс, и в течение некоторого времени брокер не отдает читателям никаких сообщений, пока ребаланс не произойдет.
Дело даже не в дублировании. Ребаланс — очень дорогая операция и примерно половина всех оптимизаций консюминга заключается в том чтобы его избежать, что выливается в шаманство с членством в группах и конфигурацией топиков. Самый простой способ, который вам надо было изначально применять — программное уравнивание. Создаете топик с N партишенов и при инициации консюминга создаете группу с N консюмерами. При этом, самый фан начинается когда вы топики и консюмеров в рантайме создаете, динамически. В сложных топологиях такого рода (напр. для построения микросервисных мешей) ребаланс в любом месте моментально убьет всю систему и окажется что группы из более чем 1 консюмера вообще надо применять очень аккуратно и в очень специфичных случаях.
События распределяются по ним в соответствии с ключами, которые мы событиям присваиваем… События внутри одной партиции упорядочены по времени… Второй подход — партиционирование потока при чтении.
Это ж называется CBR, или я чего-то не понял? Коллективный разум считает CBR антипаттерном Кафки и намекает, что если вам потребовалось его реализовать, то вы что-то не так делаете, т.к. кафка себя всегда позиционировала как быстрый транспорт, без этих ваших JMSов. Ну и да, термин «корреляция» в статье замечен не был, хотя обязан был быть.
Но есть такой класс задач — алгоритмы аналитики — где результатом обработки потока являются агрегаты событий… Как это реализовать?
Подключением к топику дополнительной группы консюмеров, выполняющих аналитику (имеется ввиду же онлайн-аналитика?). Потоковые вычисления, в т.ч. и аккумуляционные, испокон веков применялись в DSP и если честно я совсем не понял, зачем вам потребовалась наркомания с плавающими окнами на едином потоке.
Подумаем, как организовать доступ к данным потоковой архитектуры — данным в базах данных обработчиков событий.
Для RDBMS — на самом деле никак, пока не появятся реактивные драйвера для БД (Напр., ADBA для Oracle). JDBC является синхронным и блокирует все что нужно блокировать, поэтому в реактивных архитектурах их и не используют, либо реализуют волшебный CQRS и неблокирующие костыли.
***
От себя добавлю что термин «потоковая архитектура» правильно называется сейчас в источниках «reactive architecture» и строится на основе спецификации reactive streams.
В целом, есть у меня подозрение что если вы проведете бенчмарки одной и той же сложной бизнес-задачи на том решении что вы реализовали на базе Кафки и например на ActiveMQ (который еще с 2007 года поддерживает pub/sub, корреляцию и CBR чуть более чем полностью из коробки, в отличие от сатанинского MQ и чуть более кошерного Rabbit), то результаты у вас получатся примерно схожие, без учета кластеризации конечно, Кафка здесь вне конкуренции.
Почему? Потому что вы в статье использовали Кафку как аналог JMS-провайдера, накрутив поверх кучу поделок, компенсирующих напрочь отсутствующие в Кафке фичи спецификации. Кафку нельзя использовать как замену JMS, весь ее великий смысл — максимально быстро и эффективно передать много-много данных от продюсера к консюмеру. Что это за данные, какая у них семантика и тем более корреляция, как их лучше или хуже консюмить — это все вопросы приклада.
Кроме того, при безграничном масштабировании ВНЕЗАПНО окажется что больше 1-2к топиков на кластер Кафки делать совсем-совсем не рекомендуется и надо будет переосмысливать топологию (см. мои комментарии выше). Это выльется в фееричную боль, потому что переделывать надо будет вообще все.
Предпосылка о переносимости изначально неверна, просто потому что драйвера непереносимы по определению. Соответственно, можно перестать заниматься придумыванием способа исполнения нативного кода через жепу из js и
1) под windows написать сервис на любом языке (напр. javase с оберткой), который локально под управлением svchost будет выполнять те же самые функции, но без извращений. Как бонус получаем централизованное обновление сервиса через ad (про что вы конечно же забыли). Под linux это на ура переносится на systemd, после того, естественно, когда все драйвера перепишутся. Про jws уже выше предлагали, это в принципе то же самое, только без управления.
или
2) запиливаются плагины под браузер (целевой в банке — ie11, а слова про линукс и хром — это, пардон, розовые мечты апологетов js) и все работает. Обновление плагинов осуществляется опять же централизованно через ad. У CryptoPro плагины, например, уже есть. Фраза «Это тоже нам не подходит, не является целевым, привязывает к браузеру и ограничивает универсальность.» является сомнительной демагогией.
Из всего вышесказанного (да и не только, напр. тут тоже Эксельсиор) неясно, какой от AOTа великий бенефит по сравнению с JITом. Тема про WLS тоже совсем не понятна, каким образом АОТ-код можно запускать под управлением СП?
В современном мире микросервисов JVM даже с достаточно сложным кодом (напр. СП wildfly) стартует меньше чем за полсекунды. Если мы берем небольшие демонообразные приложения (т.е. на самом деле Ъ микросервисы), написанные прямыми руками, то они столько стартовали еще 10 лет назад на 1.4.
Вообще фраза «Java programs can become so large that it takes a long time for the JIT to warm up completely», которую цитируют во всех статьях про АОТ, немного противоречит текущему тренду (да и здравому смыслу) и если убрать постулат про приложения из тысячи классов, то получается что АОТ не привносит ничего кроме деградации?
Я, например, когда работаю с кодом — лучше концентрируюсь под ритмичную невариативную музыку с ярко-выраженной ритм-секцией. Лучше всего для этого подходит быстрый дет-метал типа флоридской четверки (на любителя жанра естественно) или smdm стокгольмской школы.
Визуальной разработкой действительно занимались, но с BPMS она совершенно была не связана, никто Грефу ее не продавал и более того — он об этой теме никогда и не знал. Home-grown инструмент визуального проектирования ПО по мотивам популярных лет 20 назад DDD на основе UML и кодогенерации был разработан двумя энтузиастами в недрах одного из ЦК СБТ на основе некого программного продукта, используемого в некоей RAD-платформе, проданной руководству этого ЦК некоей известной в РФ консалтерской конторой на заре 2015г, когда не было никаких искусственных интеллектов, аджайлов и всего того из чего сейчас состоит Сбербанк. Этот инструмент должен был лечь в основу современной автоматизации процессов производства ПО [в отдельно взятом ЦК и зажечь огонь революции во всем мире], в начале 2017г этой темой занималась целая команда, но ее дальнейшая судьба в силу agile-трансформации перестала кого-либо волновать. Технологические причины, по которым этот инструмент был обречен на фееричный успех, вы в статье озвучили, nuff said. Однако главная причина была совсем не технического плана, но это уже совсем другая история.
Тема с заменой Pega тоже была, но никто бесплатный Activiti Грефу опять же не продавал, потому что он не занимается такими вопросами. Для этого у него был известный в узких кругах господин Хлызов, вот ему-то, в рамках формального процесса управления архитектурой и технологиями, в начале того же 2015г некая группа товарищей и показала презу на 100500 страниц где сравнивалось много разных BPMS и по результатам пилотирования выигрывал Activiti. Решением архитектурного совета Activiti принят как целевая BPMS, end of story. Никто не собирался использовать BPMN для кодогенерации [тем более Java-кода], а решение принималось компетентными в этом людьми после тщательного исследования вопроса.
Мораль сей басни только в одном: не всегда хорошая идея получает хорошую реализацию, но в любом случае, ваша статья — не более чем домыслы, основанные на слухах (перепутать BPMN и UML надо очень сильно постараться). В компаниях enterprise-уровня существуют методологии принятия технологических решений (неважно, плохие или хорошие). Никто показом красивых картинок топ-менеджерам ничего давно уже не продает, потому что все вменяемые люди знают про пилотирование и техническую экспертизу; любой из топ-10 банков ежегодно проводит десятки пилотов, из которых может быть один перерастает в опытное внедрение, из десятка которых может быть одно действительно завершается успешно.
Заменим слово «программист» словом «сотрудник», слово «коммит» словом «высказывание», а слово «open-source проект» — на «публичная площадка» и получим то, за что 146% подписавшихся под петицией и поставивших "+1" руководителей увольняют своих сотрудников (и что явным образом запрещено в регламентах любой крупной компании, впрочем, как и несогласованные коммиты в опен-сорс).
Не говоря уж о том, что смысл претензии не в опен-сорсе, а в пол-лярде долларов и правообладании, никакому развитию никакого рынка ПО она не мешает.
Ситуацию я осуждаю, но с высказыванием «программных комитетов» согласиться тоже не могу, как и поставить +1, т.к. не уполномочен на это пресс-службой своего работодателя.
Самая главная (и единственная) проблема ES/EDA в архитектуре веб-клиентов — отсутствие server push в HTTP — всегда раньше решалась использованием протоколов более низкого уровня, а сейчас — использованием websockets. Современные веб-приложения ориентируются на Reactive Streams (на HL++ в 2017 году даже был доклад про их использование в .net), лучше стараться думать в эту сторону, а не про паттерны имени Фаулера и прочих теоретиков.
Если вы проводили испытания, то весь смысл написания этой статьи должен заключаться в статистике и метриках (как пример: habr.com/ru/post/351012). Но ниже Сергей в своем комментарии как бэ намекает на то, что у вас ничего нет. Получается что лично вы еще хуже знакомы с ситуацией.
Были нагрузочные тесты, статистические исследования производительности, а у вас? Где метрики, где статистики? Что именно и как вы «разгоняли»? Взяли сравнили три совершенно не относящиеся к теме фреймворка и изобрели велосипед? Это позор и вам, и тем людям, кто пропустил эту статью.
Вот именно, поэтому режима ptp там нет в принципе (и более того, его очень сложно реализовать если вам нужны именно классические очереди с гарантированной доставкой и прочими ништяками, смотреть тут softwaremill.com/using-kafka-as-a-message-queue), а управление тем, кто и как получает сообщение, как раз и осуществляется посредством API программиста, а конкретно — через consumer groups, как вы ВНЕЗАПНО и узнаете ниже в статье :).
Число партишенов при этом должно быть не меньше числа консюмеров, иначе у вас будет consumer starvation.
А точнее, совсем не очередь ;).
Дело даже не в дублировании. Ребаланс — очень дорогая операция и примерно половина всех оптимизаций консюминга заключается в том чтобы его избежать, что выливается в шаманство с членством в группах и конфигурацией топиков. Самый простой способ, который вам надо было изначально применять — программное уравнивание. Создаете топик с N партишенов и при инициации консюминга создаете группу с N консюмерами. При этом, самый фан начинается когда вы топики и консюмеров в рантайме создаете, динамически. В сложных топологиях такого рода (напр. для построения микросервисных мешей) ребаланс в любом месте моментально убьет всю систему и окажется что группы из более чем 1 консюмера вообще надо применять очень аккуратно и в очень специфичных случаях.
Это ж называется CBR, или я чего-то не понял? Коллективный разум считает CBR антипаттерном Кафки и намекает, что если вам потребовалось его реализовать, то вы что-то не так делаете, т.к. кафка себя всегда позиционировала как быстрый транспорт, без этих ваших JMSов. Ну и да, термин «корреляция» в статье замечен не был, хотя обязан был быть.
Подключением к топику дополнительной группы консюмеров, выполняющих аналитику (имеется ввиду же онлайн-аналитика?). Потоковые вычисления, в т.ч. и аккумуляционные, испокон веков применялись в DSP и если честно я совсем не понял, зачем вам потребовалась наркомания с плавающими окнами на едином потоке.
Для RDBMS — на самом деле никак, пока не появятся реактивные драйвера для БД (Напр., ADBA для Oracle). JDBC является синхронным и блокирует все что нужно блокировать, поэтому в реактивных архитектурах их и не используют, либо реализуют волшебный CQRS и неблокирующие костыли.
***
От себя добавлю что термин «потоковая архитектура» правильно называется сейчас в источниках «reactive architecture» и строится на основе спецификации reactive streams.
В целом, есть у меня подозрение что если вы проведете бенчмарки одной и той же сложной бизнес-задачи на том решении что вы реализовали на базе Кафки и например на ActiveMQ (который еще с 2007 года поддерживает pub/sub, корреляцию и CBR чуть более чем полностью из коробки, в отличие от сатанинского MQ и чуть более кошерного Rabbit), то результаты у вас получатся примерно схожие, без учета кластеризации конечно, Кафка здесь вне конкуренции.
Почему? Потому что вы в статье использовали Кафку как аналог JMS-провайдера, накрутив поверх кучу поделок, компенсирующих напрочь отсутствующие в Кафке фичи спецификации. Кафку нельзя использовать как замену JMS, весь ее великий смысл — максимально быстро и эффективно передать много-много данных от продюсера к консюмеру. Что это за данные, какая у них семантика и тем более корреляция, как их лучше или хуже консюмить — это все вопросы приклада.
Кроме того, при безграничном масштабировании ВНЕЗАПНО окажется что больше 1-2к топиков на кластер Кафки делать совсем-совсем не рекомендуется и надо будет переосмысливать топологию (см. мои комментарии выше). Это выльется в фееричную боль, потому что переделывать надо будет вообще все.
через жепуиз js и1) под windows написать сервис на любом языке (напр. javase с оберткой), который локально под управлением svchost будет выполнять те же самые функции, но без извращений. Как бонус получаем централизованное обновление сервиса через ad (про что вы конечно же забыли). Под linux это на ура переносится на systemd, после того, естественно, когда все драйвера перепишутся. Про jws уже выше предлагали, это в принципе то же самое, только без управления.
или
2) запиливаются плагины под браузер (целевой в банке — ie11, а слова про линукс и хром — это, пардон, розовые мечты апологетов js) и все работает. Обновление плагинов осуществляется опять же централизованно через ad. У CryptoPro плагины, например, уже есть. Фраза «Это тоже нам не подходит, не является целевым, привязывает к браузеру и ограничивает универсальность.» является сомнительной демагогией.
В современном мире микросервисов JVM даже с достаточно сложным кодом (напр. СП wildfly) стартует меньше чем за полсекунды. Если мы берем небольшие демонообразные приложения (т.е. на самом деле Ъ микросервисы), написанные прямыми руками, то они столько стартовали еще 10 лет назад на 1.4.
Вообще фраза «Java programs can become so large that it takes a long time for the JIT to warm up completely», которую цитируют во всех статьях про АОТ, немного противоречит текущему тренду (да и здравому смыслу) и если убрать постулат про приложения из тысячи классов, то получается что АОТ не привносит ничего кроме деградации?