Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка
Кое-что знаю. Но да, о Твиттере - только из интернета. Оттуда же про 100 000 серверов, и про десяток тысяч работников, ну и про остальное. Остальное как раз сильно намекает на то, что видел сам лично.
там сотни команд инженеров, на каждой из которых лежит частичка общей ответственности за то, чтобы "сделать хорошо", а сами команды стремятся к тому, чтобы действовать максимально независимо друг от друга - именно это обеспечивает необходимый темп разработки.
Когда все независимы от других, получаем повышенную сложность движения к общей цели. Простейшая иллюстрация - представим, что на войне каждый солдат будет думать за генералов. Что тогда будет? Уж точно не "необходимый темп разработки".
они обеспечивают адекватное время замены одного маленького кусочка
Не совсем так. Скорее даже наоборот - сначала растолстели команды на монолитах, обросли наследственностью и притёрлись к организационным особенностям, что привело к сокращению их эффективности. Потом эту проблему идентифицировали и решили, что виноват инструмент - монолит. Ну и начались микросервисы, которые действительно в небольшом объёме позволяют быстро вносить изменения (нет традиционных для монолитов возражений, плюс ещё не так сильно растолстели).
Но проблема была не в монолите, а в особенностях организации разработки. И отчасти она решается эволюционно, вспомним тот же git вместо svn. Но качественно, революционным путём, эту проблему никто решать не собирается, потому что за такой постановкой стоит большой риск. Это означает, что и микросервисы никуда не денутся, им тоже придётся с этой проблемой столкнуться. И уже сталкиваются.
В целом опять как всегда - не инструмент виноват, а пользователь.
Нет такого человека, который разработал бы текущую архитектуру твиттера с нуля. Это эволюционно развившаяся система
Это опять возвращает нас к проблеме множества генералов на поле боя.
Если что-то в получившейся системе, состоящей в основном из связей, не устраивает, то переделывают конкретный кусок, минимизируя область поражения, а не всё целиком
Это применимо к любому варианту, проблема только в различии способов доставки изменений. Если доставку архитектурно сделать эффективной, то и монолит вполне позволит "минимизировать область поражения".
не надо вешать клеймо и натягивать шаблоны на обсуждаемую тему. Надо подобрать максимально эффективный способ для достижения требуемых результатов
Хорошо, но тогда вы должны объявить, что такое "требуемый результат". Из смысла статьи я его понял именно как потребность в выпускниках ПТУ.
Для работы в ИТ-бизнесе больше подходят стайеры, те, кто не хватая с неба звезд, способен в долгую. без срывов и выгорания решать задачи ИТ-бизнеса, включая конечно проф.рост.
Ну вот, вы сами снова описываете именно выпускника ПТУ/техникума. А выпускнику университета действительно скоро станет скучно от однообразия и он "выгорит".
То есть просто задайте нишу статьи - уровень курсов (если вам не нравится аналогия с ПТУ/техникумом).
Вы указали как раз на особенность самого обычного платного курса. Я же говорил о необходимости отделять мух от котлет. Правда получилось длинно, пытался давать набор проблем, для понимания смысла разделения. Попробую короче ниже.
Есть курсы, заточенные под узкую конкретику. В СССР это называлось ПТУ. Чуть шире - техникум.
Есть наука в широком смысле, включая развитие IT в корпорациях. Для этого направления нужны широко мыслящие. В СССР аналог такой подготовки - университет, несколько уже - институт.
Автор описывал именно улучшения с точки зрения потребности в готовых к работе слесарях, то есть выпускниках ПТУ. Да, можно согласиться, что после института мы имеем так себе слесарей, поскольку на нужных станках они не работали. Но проблема в том, что люди хотят "где лучше", а потому надеются на хорошие условия работы именно после получения высшего образования. Только востребованность на рынке реально есть на слесарей. Отсюда дисбаланс и крики - я потратил 5 лет непойми на что, и что я получил? Работу слесаря?
В нормальном обществе этот дисбаланс давно бы устранили путём подготовки к осмысленному выбору ещё в школе, но у нас, как мы видим, всё ещё вполне взрослые, и даже наверняка уже в приличном возрасте люди, продолжают непрерывно в целой серии статей (от разных авторов) дотачивать институтское образование до уровня ПТУ. А всё потому, что нет в обществе понимания проблемы. Не нужны современному обществу выпускники института. Точнее, нужны, но порядка на два меньше, а то и на три. Но эту проблему решают не расширением количества ПТУ (курсов) с соответствующей предварительной подготовкой в школе и других местах (это уже переподготовка), а попыткой свести уровень института к уровню ПТУ, но что бы это было высшее и престижное образование. Только так не бывает - или одно, или другое. А третий вариант - улучшение общества для исключения причин проблем с образованием - вообще никем не рассматривается.
Надеюсь на этот раз было понятнее, хотя опять получилось длинно. Подскажите, если что непонятно, наверное ещё есть куда улучшать подачу.
Чтоб решать какие-либо социальные проблемы, надо в первую очередь в них разбираться
В принципе правильно, но в частностях не работает.
Вы наверняка знаете о процессе, который называется "эволюция". Там всякая мелочь, вроде мёртвых запчастей от бактерий, которые называются вирусами, легко решают очень сложные с точки зрения молекулярной биологии задачи.
Хотя я одобряю критический взгляд на современное общество, но всё же не стоит вот так безапелляционно воевать с эволюцией. Она мёртвая, без эмоций, и вас просто раздавит.
Предлагаю включить древнюю особенность всех биологических организмов, присутствующую и у вас. Она называется - способность к адаптации. Ну и, заодно, возможно сможете улучшить собственное понимание общества.
Узкий взгляд. Автор готовит работника под себя, что укладывает задачу в жёсткие рамки. Желание прогнать студента через стандартную процедуру разработки приемлемо, но только если всё остальное даётся на хорошем уровне. Проблема в том, что всё остальное никак не показано автором, кроме нескольких очень кратких предложений.
Остальное - это база. Прогнать через готовую методику можно и обезьяну, но думать она от этого не научится. Но мало умения думать, важно к нему добавить отличное знание как основ, так и ключевых технологий. Курсы сегодня как раз гоняют по методикам, а основы закладывают поверхностно, на уровне "что-то прочитал по теме". При этом не формируется умение манипулировать смыслами инструментальной области на уровне "свободно думаю на этом языке". Поэтому вынужден констатировать, что очередное предложение по улучшению образования опять свелось к повтору идеи "курсы, но лучше, потому что придумал лично я".
Но, с другой стороны, умеющие думать на самом деле мало востребованы в реальном мире. Поэтому кажется, что их мало. Узкий круг хорошо оплачиваемых айтишников так же нельзя отнести к умеющим думать. То есть кто-то из них действительно может плавать в инструментальной области как рыба и вдобавок генерировать новые прикладные знания (и может даже теоретические основы, но это совсем малая часть). Основная же часть впадёт в ступор если придётся переходить на незнакомый набор технологий, потому что в голове нет связей между инструментами и концепциями, хотя сами инструменты использовать умеют хорошо. Ступор когда-то закончится, разумеется, но у большинства это будет именно тяжёлый процесс с ломкой. И в этом свете настоящее образование должно давать именно способных к лёгкому переходу на новые инструменты за счёт глубины понимания основ. Хотя повторюсь, востребованы именно умеющие пользоваться конкретным списком инструментов, а не умеющие быстро адаптироваться, или, тем более, самим разрабатывать инструменты. Я уж не говорю про теоретические основы для них.
Поэтому в мире, где нужны "натасканные", следует говорить о курсах для натасканных. И совсем отдельным будет разговор о тех, кто двигает науку и технологии вперёд. Не разделяя эти два направления будем и далее получать множество статей с предложениями по улучшению натаскивания, но без малейшего внимания к развитию.
Science изучает закономерности в природе, а не всю доступную природу
Конечно. Но изучение ведётся с какой-то целью. Цель типа "выявить неизвестное науке излучение" есть штука крайне важная. Но важна она для науки, а не для начальства. Из-за этой разницы мы и имеем массу упущенных (для науки, разумеется) возможностей. Ну а оправдание о непознаваемом полностью оставим именно им - ленивым и жадным вышестоящим.
Отсутствие критики объективного недостатка - не научный подход. Надеюсь, мой научный подход вы всё же одобрите :)
Не беспокойтесь, за свои слова я привык отвечать. Сертификаты же на самом деле ничего не доказывают, хоть и есть их у меня несколько штук, правда по технологиям IBM (MQ, Message Broker, etc).
Книги же - способ заработать. Никто не собирается давать вам систематизированные знания просто так, потому что систематизация затратна. Их дают исключительно ради прибыли, которая и окупает затраты. Ну а что бы была прибыль, нужна массовость. Поэтому про любой массовый продукт обязательно пишут книги. Да, про помаду и пенку для задницы малышей тоже пишут книги. Спросите у мамы, насколько сложно ей было разобраться с пенкой для задницы не читая соответствующие книги, поймёте смысл книжек про кафку.
Публикация содержит исключительно выводы автора. Там нет ничего полезного про эксперименты.
Что такое "полезное" в данном случае? Очень просто - сухое и лишённое любых соприкосновений с автором описание реальности. То есть сначала сухо, без выводов, предположений, намёков и вселяющих оптимизм многозначительных экивоков, описываем контекст - где, кто, как сидит, что расположено рядом, на каком расстоянии, какой толщины, из какого материала, ну и т.д, со всеми подробностями, включая схемы и фотографии. Потом описываются действия. Сначала экспериментатора, его предложение сделать что-то, указания, подсказки, кивки головой и прочие доступные для восприятия БО действия. Затем реакция БО. Подробно. С фотографиями. А лучше с видео и хорошим звуком, что бы морзянку пяткой экспериментатора заметить, ну или вибрирующий стол, реагирующий на нервное почёсывание снизу ногтями эжкспериментатора.
И это ещё пол дела. Вторая часть - от фокусников. Да, именно эти эксперты развлекательного жанра могут определить подвох, ибо сами его неоднократно создавали. Поэтому мало того, что они обязательно должны прокомментировать подобные "исследования", но ещё и сам автор обязан написать в своём исследовании пару глав о том, как он собрался ловить за руку именно намеренный обман. Какие меры принял? Как их реализовал? Со всеми подробностями, что бы вменяемый критик мог легко указать пальцем на некомпетентность экспериментатора.
Но экспериментаторы обычно стесняются подробно излагать все детали. Тут либо лень, что есть признак халтурщика и такие эксперименты безжалостно отправляются в топку, либо страх за разоблачение, ну или хотя бы за психологически неприятную критику, и тогда таким пугливым опять нет места в настоящей науке - либо ты доказываешь своё мнение, не стесняясь и не опасаясь уколов критики, либо ты пишешь для себя и своей бабушки, которой очень нравится читать сказки на ночь..
Результатом правильного проектирования и реализации DDD являются 4 свойства бизнес-логики:
легко понять;
Статья является просто кричащим противоречием заявленному в статье.
Хотя да, если не накидаешь англицизмов, то начальство может понять, что смысла в предлагаемой "архитектуре" нет никакого.
Бизнес-логика состоит из:
бизнес-логики мутации состояния DDD сущности;
бизнес-логики валидации состояния DDD entity;
бизнес-логики создания DDD сущности.
Зачем здесь 4 раза повторено выражение "бизнес-логика"? Её здесь нет. Ни одной. Потому что бизнес-логика - это правила ведения бизнеса. В бизнесе никто не мутирует состояния секретарши, не успевшей провалидировать состояние принтера с целью создания новой сущности "отчёт". Там просто дают втык. И это всем понятно, в отличии от.
Притянутый за уши формализм скрывает только одно - полное непонимание реальной задачи. Никакими ссылками на кандидатские западных теоретиков (столь же далёких от бизнеса) это безобразие не скрыть. Зато можно подменить задачи бизнеса на абсолютно произвольно трактуемые формулировки, что даёт бесконечный простор для пиления зарплат за счёт ничего-не-деланья.
Теория массового обслуживания занимается выявлением статистически описываемых закономерностей. Информационные системы занимаются обработкой информации. Статья - про последнее. Первое может помочь оптимизировать второе, но в целом имеет очень мало общего с предметом обработки информации в ИС.
Отличие от статистики в ИС простое - там детерминированные данные. Пропускная способность должна быть ХХХ на вход и УУУ на выход. И никаких вероятностей. Ну кроме флуктуаций в рамках максимально доступной пропускной способности. Эти флуктуации можно статистически оценивать и тем обосновывать выбор количественных показателей распределённых систем, но на практике почти никогда такие сложные вещи не приходят в голову большинству архитекторов ИС. Причина простая - оплачивается лишь возможность обработать некий поток, а минимизация стоимости обработки в список задач не входит из-за существенно большей стоимости разработки решения.
При этом имеет высокий порог вхождения, требователен к ресурсам.
Kafka как раз имеет очень низкий порог вхождения, благодаря хорошей документации и качественной архитектуре. Высоким же этот порог становится лишь для тех, кто привык лишь аннотации расставлять, не понимая происходящего внутри. Мир разработки заполнен плохо понимающими общие принципы быстроделами, но как раз эти общие принципы и дают возможность понять кафку гораздо легче, чем какой-нибудь, прости хосспади, спринг. Спринг требует понимания, что было в голове у автора той или иной части и как он это сумел по быстрому сляпать в своей обвязке вокруг заимствованных компонентов. А кафка, если человек хорошо знаком с базовыми принципами, просто предлагает ему чистую реализацию, без малейшей каши из головы очередного мамкиного "архитектора".
Немного аналогий:
Кафка - это кольцо, оно вставляется в этот цилиндр.
Спринг - это магический круг вечного огня, он разжигает небесное пламя, и после всего лишь нескольких (но очень важных!) заклинаний вы сумеете победить подземного дракона, а потом поймать океанского кита, на чём вы заработаете огромную кучу денег и станете самым уважаемым архитектором в мире вечно зелёных цилиндров, поглощающих пламя вечного кругового огня! Скорее, все на спринг!
Все эти танцы с перекладыванием ответственности с одного сервиса на другой всегда ведут к одному и тому же - к неэффективности. К счастью для начинающих "архитекторов" владельцы бизнесов ни в зуб ногой в этих ваших брокерах, а потому легко выделяют огромные бюджеты на то, что наблюдали в соседнем бизнесе, а там такой же "архитектор" сочинил такое же перекладывание ответственности. Ну и распространяется эта волна бессмысленного раскладывания по очередям на весь мир.
Либо у вашего бизнеса есть нормальный архитектор, и тогда у вас всё быстро, дёшево и надёжно, либо вы наняли модного "архитектора", делающего "как у всех", и тогда ваши затраты увеличиваются на порядок в сравнении со случаем, где есть нормальный архитектор.
Ну да не будем мешать бизнесу сливать деньги акционеров. Благо, чем больше они сольют, тем больше айтишников останутся довольными.
Oracle адаптирован под длинные транзакции, то есть всё там пишется на диск, хотя может и не сразу.
Если в пакете инсерт и потом на него же апдейт, то достаточно одной записи в лог, а при коммите одна на диск. Если же оптимизатор глупый - будут две в лог и при коммите их обе придётся прочитать, что бы два раза записать в одно и то же место на диске.
Точность схемы не гарантирую, но надеюсь разжёвано достаточно подробно, что бы был очевиден главный принцип.
Какие оптимизации могут потребоваться пакету, содержащему только ряд [WITH ...] INSERT/MERGE/UPDATE/DELETE ... FROM ... ?
Группировка для одномоментной записи на диск, например. Но вообще там много места для оптимизаций. Если время выполнения пакета можно улучшить - оптимизация нужна. Если вам кажется, что оптимизация сложная, это не повод от неё отказываться.
Создаём временную таблицу. Читаем из неё. Создаём две записи. Удаляем из временной. Пишем туда же новое значение. Читаем его. Снова создаём две записи.
Посчитайте, сколько обращений к БД вы сделали.
Какие оптимизации могут потребоваться
Такие же, как и при любых других вычислениях. Например, про объединение инсертов в одну запись мы тут уже который день говорим.
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Кое-что знаю. Но да, о Твиттере - только из интернета. Оттуда же про 100 000 серверов, и про десяток тысяч работников, ну и про остальное. Остальное как раз сильно намекает на то, что видел сам лично.
Когда все независимы от других, получаем повышенную сложность движения к общей цели. Простейшая иллюстрация - представим, что на войне каждый солдат будет думать за генералов. Что тогда будет? Уж точно не "необходимый темп разработки".
Не совсем так. Скорее даже наоборот - сначала растолстели команды на монолитах, обросли наследственностью и притёрлись к организационным особенностям, что привело к сокращению их эффективности. Потом эту проблему идентифицировали и решили, что виноват инструмент - монолит. Ну и начались микросервисы, которые действительно в небольшом объёме позволяют быстро вносить изменения (нет традиционных для монолитов возражений, плюс ещё не так сильно растолстели).
Но проблема была не в монолите, а в особенностях организации разработки. И отчасти она решается эволюционно, вспомним тот же git вместо svn. Но качественно, революционным путём, эту проблему никто решать не собирается, потому что за такой постановкой стоит большой риск. Это означает, что и микросервисы никуда не денутся, им тоже придётся с этой проблемой столкнуться. И уже сталкиваются.
В целом опять как всегда - не инструмент виноват, а пользователь.
Это опять возвращает нас к проблеме множества генералов на поле боя.
Это применимо к любому варианту, проблема только в различии способов доставки изменений. Если доставку архитектурно сделать эффективной, то и монолит вполне позволит "минимизировать область поражения".
Хорошо, но тогда вы должны объявить, что такое "требуемый результат". Из смысла статьи я его понял именно как потребность в выпускниках ПТУ.
Ну вот, вы сами снова описываете именно выпускника ПТУ/техникума. А выпускнику университета действительно скоро станет скучно от однообразия и он "выгорит".
То есть просто задайте нишу статьи - уровень курсов (если вам не нравится аналогия с ПТУ/техникумом).
Вы указали как раз на особенность самого обычного платного курса. Я же говорил о необходимости отделять мух от котлет. Правда получилось длинно, пытался давать набор проблем, для понимания смысла разделения. Попробую короче ниже.
Есть курсы, заточенные под узкую конкретику. В СССР это называлось ПТУ. Чуть шире - техникум.
Есть наука в широком смысле, включая развитие IT в корпорациях. Для этого направления нужны широко мыслящие. В СССР аналог такой подготовки - университет, несколько уже - институт.
Автор описывал именно улучшения с точки зрения потребности в готовых к работе слесарях, то есть выпускниках ПТУ. Да, можно согласиться, что после института мы имеем так себе слесарей, поскольку на нужных станках они не работали. Но проблема в том, что люди хотят "где лучше", а потому надеются на хорошие условия работы именно после получения высшего образования. Только востребованность на рынке реально есть на слесарей. Отсюда дисбаланс и крики - я потратил 5 лет непойми на что, и что я получил? Работу слесаря?
В нормальном обществе этот дисбаланс давно бы устранили путём подготовки к осмысленному выбору ещё в школе, но у нас, как мы видим, всё ещё вполне взрослые, и даже наверняка уже в приличном возрасте люди, продолжают непрерывно в целой серии статей (от разных авторов) дотачивать институтское образование до уровня ПТУ. А всё потому, что нет в обществе понимания проблемы. Не нужны современному обществу выпускники института. Точнее, нужны, но порядка на два меньше, а то и на три. Но эту проблему решают не расширением количества ПТУ (курсов) с соответствующей предварительной подготовкой в школе и других местах (это уже переподготовка), а попыткой свести уровень института к уровню ПТУ, но что бы это было высшее и престижное образование. Только так не бывает - или одно, или другое. А третий вариант - улучшение общества для исключения причин проблем с образованием - вообще никем не рассматривается.
Надеюсь на этот раз было понятнее, хотя опять получилось длинно. Подскажите, если что непонятно, наверное ещё есть куда улучшать подачу.
В принципе правильно, но в частностях не работает.
Вы наверняка знаете о процессе, который называется "эволюция". Там всякая мелочь, вроде мёртвых запчастей от бактерий, которые называются вирусами, легко решают очень сложные с точки зрения молекулярной биологии задачи.
Хотя я одобряю критический взгляд на современное общество, но всё же не стоит вот так безапелляционно воевать с эволюцией. Она мёртвая, без эмоций, и вас просто раздавит.
Предлагаю включить древнюю особенность всех биологических организмов, присутствующую и у вас. Она называется - способность к адаптации. Ну и, заодно, возможно сможете улучшить собственное понимание общества.
Узкий взгляд. Автор готовит работника под себя, что укладывает задачу в жёсткие рамки. Желание прогнать студента через стандартную процедуру разработки приемлемо, но только если всё остальное даётся на хорошем уровне. Проблема в том, что всё остальное никак не показано автором, кроме нескольких очень кратких предложений.
Остальное - это база. Прогнать через готовую методику можно и обезьяну, но думать она от этого не научится. Но мало умения думать, важно к нему добавить отличное знание как основ, так и ключевых технологий. Курсы сегодня как раз гоняют по методикам, а основы закладывают поверхностно, на уровне "что-то прочитал по теме". При этом не формируется умение манипулировать смыслами инструментальной области на уровне "свободно думаю на этом языке". Поэтому вынужден констатировать, что очередное предложение по улучшению образования опять свелось к повтору идеи "курсы, но лучше, потому что придумал лично я".
Но, с другой стороны, умеющие думать на самом деле мало востребованы в реальном мире. Поэтому кажется, что их мало. Узкий круг хорошо оплачиваемых айтишников так же нельзя отнести к умеющим думать. То есть кто-то из них действительно может плавать в инструментальной области как рыба и вдобавок генерировать новые прикладные знания (и может даже теоретические основы, но это совсем малая часть). Основная же часть впадёт в ступор если придётся переходить на незнакомый набор технологий, потому что в голове нет связей между инструментами и концепциями, хотя сами инструменты использовать умеют хорошо. Ступор когда-то закончится, разумеется, но у большинства это будет именно тяжёлый процесс с ломкой. И в этом свете настоящее образование должно давать именно способных к лёгкому переходу на новые инструменты за счёт глубины понимания основ. Хотя повторюсь, востребованы именно умеющие пользоваться конкретным списком инструментов, а не умеющие быстро адаптироваться, или, тем более, самим разрабатывать инструменты. Я уж не говорю про теоретические основы для них.
Поэтому в мире, где нужны "натасканные", следует говорить о курсах для натасканных. И совсем отдельным будет разговор о тех, кто двигает науку и технологии вперёд. Не разделяя эти два направления будем и далее получать множество статей с предложениями по улучшению натаскивания, но без малейшего внимания к развитию.
Конечно. Но изучение ведётся с какой-то целью. Цель типа "выявить неизвестное науке излучение" есть штука крайне важная. Но важна она для науки, а не для начальства. Из-за этой разницы мы и имеем массу упущенных (для науки, разумеется) возможностей. Ну а оправдание о непознаваемом полностью оставим именно им - ленивым и жадным вышестоящим.
Отсутствие критики объективного недостатка - не научный подход. Надеюсь, мой научный подход вы всё же одобрите :)
Не беспокойтесь, за свои слова я привык отвечать. Сертификаты же на самом деле ничего не доказывают, хоть и есть их у меня несколько штук, правда по технологиям IBM (MQ, Message Broker, etc).
Книги же - способ заработать. Никто не собирается давать вам систематизированные знания просто так, потому что систематизация затратна. Их дают исключительно ради прибыли, которая и окупает затраты. Ну а что бы была прибыль, нужна массовость. Поэтому про любой массовый продукт обязательно пишут книги. Да, про помаду и пенку для задницы малышей тоже пишут книги. Спросите у мамы, насколько сложно ей было разобраться с пенкой для задницы не читая соответствующие книги, поймёте смысл книжек про кафку.
Не своё, а организаторов науки. Хотя да, взять вину на себя и прикрыть зад начальника - почётное дело.
Публикация содержит исключительно выводы автора. Там нет ничего полезного про эксперименты.
Что такое "полезное" в данном случае? Очень просто - сухое и лишённое любых соприкосновений с автором описание реальности. То есть сначала сухо, без выводов, предположений, намёков и вселяющих оптимизм многозначительных экивоков, описываем контекст - где, кто, как сидит, что расположено рядом, на каком расстоянии, какой толщины, из какого материала, ну и т.д, со всеми подробностями, включая схемы и фотографии. Потом описываются действия. Сначала экспериментатора, его предложение сделать что-то, указания, подсказки, кивки головой и прочие доступные для восприятия БО действия. Затем реакция БО. Подробно. С фотографиями. А лучше с видео и хорошим звуком, что бы морзянку пяткой экспериментатора заметить, ну или вибрирующий стол, реагирующий на нервное почёсывание снизу ногтями эжкспериментатора.
И это ещё пол дела. Вторая часть - от фокусников. Да, именно эти эксперты развлекательного жанра могут определить подвох, ибо сами его неоднократно создавали. Поэтому мало того, что они обязательно должны прокомментировать подобные "исследования", но ещё и сам автор обязан написать в своём исследовании пару глав о том, как он собрался ловить за руку именно намеренный обман. Какие меры принял? Как их реализовал? Со всеми подробностями, что бы вменяемый критик мог легко указать пальцем на некомпетентность экспериментатора.
Но экспериментаторы обычно стесняются подробно излагать все детали. Тут либо лень, что есть признак халтурщика и такие эксперименты безжалостно отправляются в топку, либо страх за разоблачение, ну или хотя бы за психологически неприятную критику, и тогда таким пугливым опять нет места в настоящей науке - либо ты доказываешь своё мнение, не стесняясь и не опасаясь уколов критики, либо ты пишешь для себя и своей бабушки, которой очень нравится читать сказки на ночь..
Статья является просто кричащим противоречием заявленному в статье.
Хотя да, если не накидаешь англицизмов, то начальство может понять, что смысла в предлагаемой "архитектуре" нет никакого.
Зачем здесь 4 раза повторено выражение "бизнес-логика"? Её здесь нет. Ни одной. Потому что бизнес-логика - это правила ведения бизнеса. В бизнесе никто не мутирует состояния секретарши, не успевшей провалидировать состояние принтера с целью создания новой сущности "отчёт". Там просто дают втык. И это всем понятно, в отличии от.
Притянутый за уши формализм скрывает только одно - полное непонимание реальной задачи. Никакими ссылками на кандидатские западных теоретиков (столь же далёких от бизнеса) это безобразие не скрыть. Зато можно подменить задачи бизнеса на абсолютно произвольно трактуемые формулировки, что даёт бесконечный простор для пиления зарплат за счёт ничего-не-деланья.
Теория массового обслуживания занимается выявлением статистически описываемых закономерностей. Информационные системы занимаются обработкой информации. Статья - про последнее. Первое может помочь оптимизировать второе, но в целом имеет очень мало общего с предметом обработки информации в ИС.
Отличие от статистики в ИС простое - там детерминированные данные. Пропускная способность должна быть ХХХ на вход и УУУ на выход. И никаких вероятностей. Ну кроме флуктуаций в рамках максимально доступной пропускной способности. Эти флуктуации можно статистически оценивать и тем обосновывать выбор количественных показателей распределённых систем, но на практике почти никогда такие сложные вещи не приходят в голову большинству архитекторов ИС. Причина простая - оплачивается лишь возможность обработать некий поток, а минимизация стоимости обработки в список задач не входит из-за существенно большей стоимости разработки решения.
Kafka как раз имеет очень низкий порог вхождения, благодаря хорошей документации и качественной архитектуре. Высоким же этот порог становится лишь для тех, кто привык лишь аннотации расставлять, не понимая происходящего внутри. Мир разработки заполнен плохо понимающими общие принципы быстроделами, но как раз эти общие принципы и дают возможность понять кафку гораздо легче, чем какой-нибудь, прости хосспади, спринг. Спринг требует понимания, что было в голове у автора той или иной части и как он это сумел по быстрому сляпать в своей обвязке вокруг заимствованных компонентов. А кафка, если человек хорошо знаком с базовыми принципами, просто предлагает ему чистую реализацию, без малейшей каши из головы очередного мамкиного "архитектора".
Немного аналогий:
Кафка - это кольцо, оно вставляется в этот цилиндр.
Спринг - это магический круг вечного огня, он разжигает небесное пламя, и после всего лишь нескольких (но очень важных!) заклинаний вы сумеете победить подземного дракона, а потом поймать океанского кита, на чём вы заработаете огромную кучу денег и станете самым уважаемым архитектором в мире вечно зелёных цилиндров, поглощающих пламя вечного кругового огня! Скорее, все на спринг!
Все эти танцы с перекладыванием ответственности с одного сервиса на другой всегда ведут к одному и тому же - к неэффективности. К счастью для начинающих "архитекторов" владельцы бизнесов ни в зуб ногой в этих ваших брокерах, а потому легко выделяют огромные бюджеты на то, что наблюдали в соседнем бизнесе, а там такой же "архитектор" сочинил такое же перекладывание ответственности. Ну и распространяется эта волна бессмысленного раскладывания по очередям на весь мир.
Либо у вашего бизнеса есть нормальный архитектор, и тогда у вас всё быстро, дёшево и надёжно, либо вы наняли модного "архитектора", делающего "как у всех", и тогда ваши затраты увеличиваются на порядок в сравнении со случаем, где есть нормальный архитектор.
Ну да не будем мешать бизнесу сливать деньги акционеров. Благо, чем больше они сольют, тем больше айтишников останутся довольными.
И что будет? Ошибка и указание DBA увеличить размер лога?
Oracle адаптирован под длинные транзакции, то есть всё там пишется на диск, хотя может и не сразу.
Если в пакете инсерт и потом на него же апдейт, то достаточно одной записи в лог, а при коммите одна на диск. Если же оптимизатор глупый - будут две в лог и при коммите их обе придётся прочитать, что бы два раза записать в одно и то же место на диске.
Точность схемы не гарантирую, но надеюсь разжёвано достаточно подробно, что бы был очевиден главный принцип.
Приведите список всех операций чтения/записи с/на диск для следующего набора:
insert into t1 ...
insert into t2 ...
update t1 ...
update t2 ...
Операции включают как период до commit-a, так и сам commit. Ну а затем я покажу вам, что стоит сгруппировать.
Одна запись на диск стоит дешевле многих записей на диск. Вот и группируем многие записи в одну.
Ваш код, вам виднее.
Группировка для одномоментной записи на диск, например. Но вообще там много места для оптимизаций. Если время выполнения пакета можно улучшить - оптимизация нужна. Если вам кажется, что оптимизация сложная, это не повод от неё отказываться.
Создаём временную таблицу. Читаем из неё. Создаём две записи. Удаляем из временной. Пишем туда же новое значение. Читаем его. Снова создаём две записи.
Посчитайте, сколько обращений к БД вы сделали.
Такие же, как и при любых других вычислениях. Например, про объединение инсертов в одну запись мы тут уже который день говорим.