Всем привет!
Когда-то на своей первой работе я услышал от коллеги совет: "Не надо бросаться реализовывать в коде первую попавшуюся идею. Подумай, найди пару альтернативных решений и сравни их".
Так вот, спустя более 15 лет практики хочу сказать - это очень важная и полезная мысль!)
По моему собственному опыту в 25-50% случаев первая пришедшая в голову идея не является оптимальной. Иногда приходится выкинуть все сделанное, иногда - сильно ее видоизменить. Причем часто это происходит еще в процессе работы над исходной задачей, при попытке вписать свой новый код в существующий сервис.
По сути речь идет о проектировании и его качестве. Когда нужно проектирование? Почти всегда, кроме исправления тривиальных багов - опечаток, замены текстовок например. А на самом деле даже простой в исправлении баг может указать на необходимость рефакторинга, а рефакторинг в любом случае требует проектирования.
Хорошим вариантом проверить качество идеи является практика TDD - в этом случае придется сразу написать типовые примеры использования вашего нового класса в виде тестов. Соответственно, сразу будет видно как новый код интегрируется с существующим, подходит ли для всех случаев использования.
При этом важно отметить, что TDD не заменяет проектирование.
Единственная альтернатива проектированию, которую я вижу - закладывать 1,5х или 2х времени для работы над задачей, чтобы была возможность все переделать) Альтернатива так себе, по моей оценке время на проектирование будет ниже.
Еще худший вариант: видя, что новый код придется переделывать - "докостылить" его до работающего варианта и записать себе задачу с техдолгом. К таким техдолгам, увы, долго не возвращаются.
Резюме - закладывайте время на предварительное проектирование по любой не тривиальной задаче. Ищите и сравнивайте альтернативные варианты, выбирайте оптимальный.
#arch
Когда-то на своей первой работе я услышал от коллеги совет: "Не надо бросаться реализовывать в коде первую попавшуюся идею. Подумай, найди пару альтернативных решений и сравни их".
Так вот, спустя более 15 лет практики хочу сказать - это очень важная и полезная мысль!)
По моему собственному опыту в 25-50% случаев первая пришедшая в голову идея не является оптимальной. Иногда приходится выкинуть все сделанное, иногда - сильно ее видоизменить. Причем часто это происходит еще в процессе работы над исходной задачей, при попытке вписать свой новый код в существующий сервис.
По сути речь идет о проектировании и его качестве. Когда нужно проектирование? Почти всегда, кроме исправления тривиальных багов - опечаток, замены текстовок например. А на самом деле даже простой в исправлении баг может указать на необходимость рефакторинга, а рефакторинг в любом случае требует проектирования.
Хорошим вариантом проверить качество идеи является практика TDD - в этом случае придется сразу написать типовые примеры использования вашего нового класса в виде тестов. Соответственно, сразу будет видно как новый код интегрируется с существующим, подходит ли для всех случаев использования.
При этом важно отметить, что TDD не заменяет проектирование.
Единственная альтернатива проектированию, которую я вижу - закладывать 1,5х или 2х времени для работы над задачей, чтобы была возможность все переделать) Альтернатива так себе, по моей оценке время на проектирование будет ниже.
Еще худший вариант: видя, что новый код придется переделывать - "докостылить" его до работающего варианта и записать себе задачу с техдолгом. К таким техдолгам, увы, долго не возвращаются.
Резюме - закладывайте время на предварительное проектирование по любой не тривиальной задаче. Ищите и сравнивайте альтернативные варианты, выбирайте оптимальный.
#arch
Всем привет!
Могу порекомендовать неплохую статью, объясняющую в чем принципиальная разница между классической архитектурой, основанной на слоях, и более современными и в целом похожими Onion Architecture (ну не привычно мне называть ее луковой :) ), и гексагональной, она же Порты и адаптеры.
Собственно статья https://habr.com/ru/articles/344164/
#arch
Могу порекомендовать неплохую статью, объясняющую в чем принципиальная разница между классической архитектурой, основанной на слоях, и более современными и в целом похожими Onion Architecture (ну не привычно мне называть ее луковой :) ), и гексагональной, она же Порты и адаптеры.
Собственно статья https://habr.com/ru/articles/344164/
#arch
Хабр
Слои, Луковицы, Гексогоны, Порты и Адаптеры — всё это об одном
Перевод статьи Mark Seemann о популярных архитектурах разработки ПО и о том, что между ними общего. Один из моих читателей спросил меня: Вернон, в своей книге «Implementing DDD» много говорит об...
Всем привет!
Если просто написать какой-то правильный тезис - скорее всего он забудется и на зайдет.
Поэтому проиллюстрирую тезис, даже два, случаем из моей практики.
Была задача сделать систему управления контентом. Она же CMS. Но вот беда - в организации, где я работал, такой системы не было. А так как мы являемся бизнес-подразделением - внедрить готовое решение своими силами было очень сложно, практически невозможно.
Что ж, будем искать - а что же есть подходящее. Нашел систему управления справочниками. Свои справочники заводить можно. UI для их редактирования есть. Есть ролевая модель для управления доступом. Есть даже версионность - можно изменения заводить в виде версий, включаемых на ПРОМ атомарно.
Да, не UI бедноват, но на безрыбье и рак рыба...
В общем тогда мне это показалось хорошей идей.
Сейчас считаю это одним из самых больших своих факапов как архитектора.
В чем основные проблемы:
1) выяснилось, что заведение прикладных справочников хоть и технически возможно, но по факту запрещено. Точнее разрешено только через отдельную процедуру согласования. Т.е. из справочников хотят таки сделать как ни банально бы это звучало справочники - систему хранения нормативной, редко меняющейся информации. И с этим аргументом сложно поспорить)
2) более того - не только у нас одних возникла задача ведения контента, в недрах нашей организации ведется работа над CMS. На тот момент она была в пилотной эксплуатации, но при большом желании можно даже было в этом пилоте поучаствовать.
3) самое главное - даже если бы мы внедрили нашу реализацию, то с очень большой вероятностью через год-два столкнулись бы с тем, что UI справочников не позволяет удобно настраивать контент, также, как это делается в CMS. А дорабатывать UI никто не будет, т.к. это же справочники.
В итоге через год команда перешла на ту самую CMS, уже после начала ее промышленной эксплуатации.
Выводы:
1) не надо использовать сервисы, утилиты, фреймворки нецелевым образом. Рано или поздно это аукнется. В данном случае я считаю - хорошо, что аукнулось рано)
2) не изобретайте велосипеды, используйте уже существующие) А они в 95% случаев уже есть.
#fuckup #projects #arch
Если просто написать какой-то правильный тезис - скорее всего он забудется и на зайдет.
Поэтому проиллюстрирую тезис, даже два, случаем из моей практики.
Была задача сделать систему управления контентом. Она же CMS. Но вот беда - в организации, где я работал, такой системы не было. А так как мы являемся бизнес-подразделением - внедрить готовое решение своими силами было очень сложно, практически невозможно.
Что ж, будем искать - а что же есть подходящее. Нашел систему управления справочниками. Свои справочники заводить можно. UI для их редактирования есть. Есть ролевая модель для управления доступом. Есть даже версионность - можно изменения заводить в виде версий, включаемых на ПРОМ атомарно.
Да, не UI бедноват, но на безрыбье и рак рыба...
В общем тогда мне это показалось хорошей идей.
Сейчас считаю это одним из самых больших своих факапов как архитектора.
В чем основные проблемы:
1) выяснилось, что заведение прикладных справочников хоть и технически возможно, но по факту запрещено. Точнее разрешено только через отдельную процедуру согласования. Т.е. из справочников хотят таки сделать как ни банально бы это звучало справочники - систему хранения нормативной, редко меняющейся информации. И с этим аргументом сложно поспорить)
2) более того - не только у нас одних возникла задача ведения контента, в недрах нашей организации ведется работа над CMS. На тот момент она была в пилотной эксплуатации, но при большом желании можно даже было в этом пилоте поучаствовать.
3) самое главное - даже если бы мы внедрили нашу реализацию, то с очень большой вероятностью через год-два столкнулись бы с тем, что UI справочников не позволяет удобно настраивать контент, также, как это делается в CMS. А дорабатывать UI никто не будет, т.к. это же справочники.
В итоге через год команда перешла на ту самую CMS, уже после начала ее промышленной эксплуатации.
Выводы:
1) не надо использовать сервисы, утилиты, фреймворки нецелевым образом. Рано или поздно это аукнется. В данном случае я считаю - хорошо, что аукнулось рано)
2) не изобретайте велосипеды, используйте уже существующие) А они в 95% случаев уже есть.
#fuckup #projects #arch
Всем привет!
Сегодняшний пост начну издалека. Распределенные системы обмениваются сообщениями. Каждое сообщение можно рассматривать как событие, требующее какой-то обработки и передачи дальше - в другую подобную систему или для хранения в БД. Т.об. мы получаем распределенную цепочку микросервисов, через которые проходит событие. Существуют т.наз. семантики доставки сообщений:
- at-most-once
- at-least-once
- exactly-once
at-most-once - максимум один раз, т.е. 0 или 1. Т.е. есть вероятность потерять и не обработать сообщение. Подходит для случаев, когда поток сообщений большой, используется для сбора статистики и потеря одного сообщения не критична. Например - статистика по кликам на сайте.
at-least-once - минимум один раз, т.е. 1 или более. Т.е. есть вероятность повторно отправить какое-то сообщение и, соответственно, обработать его дважды. Подходит для систем, где важно знать последнее значение. Пример: стоимость акции на сайте брокера. Или для систем, идемпотентно обрабатывающих входящие сообщения - https://habr.com/ru/companies/domclick/articles/779872/
exactly-once - строго один раз. Идеальный случай.
Да, система может поддерживать сразу несколько семантик, т.е. по сути иметь несколько режимов работы.
Самый интересный и сложный - это конечно exactly-once. Как с ним обстоят дела?
Например, его поддерживает Kafka - самая распространённая система потоковой передачи сообщений - https://docs.confluent.io/kafka/design/delivery-semantics.html
А также самые распространенные системы потоковой обработки данных:
Kafka Streams - https://kafka.apache.org/33/documentation/streams/core-concepts
Flink - https://flink.apache.org/2018/02/28/an-overview-of-end-to-end-exactly-once-processing-in-apache-flink-with-apache-kafka-too/
Spark - https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html
Кажется, что все хорошо. Но не совсем)
Если прочитать внимательнее, что пишут, например, создатели Kafka, то выяснится что exactly-once гарантируется на участке Producer - Kafka, но далее все зависит от того, как организована работа в Consumer-е. Вот неплохая переводная статья на эту тему от одного из создателей Kafka: https://habr.com/ru/companies/badoo/articles/333046/ // в статье detected american style самореклама, но все равно она неплохая)))
Создатели Flink тоже говорят, что
а) мы даем механизм для exactly-once - в случае сбоя мы откатим ваш обрабатывающий процесс на конкретное состояние (checkpoint), и вы четко будете знать, что это за состояние - его метку времени, что было до и после него, но
б) что делать уже обработанными записями, находящимися после восстановленного состояния - разбирайтесь сами
в) возможность вернуться к сообщениям, на которые указывает checkpoint - тоже на стороне разработчика. В случае Kafka это чаще всего элементарно - сообщения не удаляются сразу после чтения из топика, а если это MQ или сетевой сокет...
г) а еще можно рассмотреть кейс, если кто-то обновил хранилище, где хранится состояние
д) или если в функции потоковой обработки используются какие-то внешние вызовы, которые сломаются на повторах после отката...
Но по большому счету это частности. Основная проблема - системы типа Kafka или Flink могут обеспечить exactly-once на какой-то небольшой части вашей микросервисной системы. Как обеспечить ее на всей системе - в любом случае задача архитектора и разработчика.
Подсказка: наличие operationId (traceId), идемпотентность, транзакции там где это возможно, докаты и наконец админка для ручного разбора инцидентов если не помогли все предыдущие варианты.
#streaming #kafka #flink #arch #microservices #exactly_once
Сегодняшний пост начну издалека. Распределенные системы обмениваются сообщениями. Каждое сообщение можно рассматривать как событие, требующее какой-то обработки и передачи дальше - в другую подобную систему или для хранения в БД. Т.об. мы получаем распределенную цепочку микросервисов, через которые проходит событие. Существуют т.наз. семантики доставки сообщений:
- at-most-once
- at-least-once
- exactly-once
at-most-once - максимум один раз, т.е. 0 или 1. Т.е. есть вероятность потерять и не обработать сообщение. Подходит для случаев, когда поток сообщений большой, используется для сбора статистики и потеря одного сообщения не критична. Например - статистика по кликам на сайте.
at-least-once - минимум один раз, т.е. 1 или более. Т.е. есть вероятность повторно отправить какое-то сообщение и, соответственно, обработать его дважды. Подходит для систем, где важно знать последнее значение. Пример: стоимость акции на сайте брокера. Или для систем, идемпотентно обрабатывающих входящие сообщения - https://habr.com/ru/companies/domclick/articles/779872/
exactly-once - строго один раз. Идеальный случай.
Да, система может поддерживать сразу несколько семантик, т.е. по сути иметь несколько режимов работы.
Самый интересный и сложный - это конечно exactly-once. Как с ним обстоят дела?
Например, его поддерживает Kafka - самая распространённая система потоковой передачи сообщений - https://docs.confluent.io/kafka/design/delivery-semantics.html
А также самые распространенные системы потоковой обработки данных:
Kafka Streams - https://kafka.apache.org/33/documentation/streams/core-concepts
Flink - https://flink.apache.org/2018/02/28/an-overview-of-end-to-end-exactly-once-processing-in-apache-flink-with-apache-kafka-too/
Spark - https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html
Кажется, что все хорошо. Но не совсем)
Если прочитать внимательнее, что пишут, например, создатели Kafka, то выяснится что exactly-once гарантируется на участке Producer - Kafka, но далее все зависит от того, как организована работа в Consumer-е. Вот неплохая переводная статья на эту тему от одного из создателей Kafka: https://habr.com/ru/companies/badoo/articles/333046/ // в статье detected american style самореклама, но все равно она неплохая)))
Создатели Flink тоже говорят, что
а) мы даем механизм для exactly-once - в случае сбоя мы откатим ваш обрабатывающий процесс на конкретное состояние (checkpoint), и вы четко будете знать, что это за состояние - его метку времени, что было до и после него, но
б) что делать уже обработанными записями, находящимися после восстановленного состояния - разбирайтесь сами
в) возможность вернуться к сообщениям, на которые указывает checkpoint - тоже на стороне разработчика. В случае Kafka это чаще всего элементарно - сообщения не удаляются сразу после чтения из топика, а если это MQ или сетевой сокет...
г) а еще можно рассмотреть кейс, если кто-то обновил хранилище, где хранится состояние
д) или если в функции потоковой обработки используются какие-то внешние вызовы, которые сломаются на повторах после отката...
Но по большому счету это частности. Основная проблема - системы типа Kafka или Flink могут обеспечить exactly-once на какой-то небольшой части вашей микросервисной системы. Как обеспечить ее на всей системе - в любом случае задача архитектора и разработчика.
Подсказка: наличие operationId (traceId), идемпотентность, транзакции там где это возможно, докаты и наконец админка для ручного разбора инцидентов если не помогли все предыдущие варианты.
#streaming #kafka #flink #arch #microservices #exactly_once
Хабр
Идемпотентность: больше, чем кажется
Друзья, всем привет! Идемпотентность в проектировании API — не просто формальность. Это свойство, часто рассматриваемое как способ получения одинакового ответа на повторяющийся запрос, на самом деле...
Всем привет!
Недавно набрел на интересную статью - https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness
Настоятельно рекомендую ее прочитать, но как всегда вкратце перескажу)
В крупную клетку любой нормально спроектированный сервис включает в себя контроллер (порт в терминологии гексагональной архитекторы), модель и адаптеры.
Вся логика должна быть в модели. Но что делать, если предварительная проверка данных требует обращения к внешней системе (БД), и при этом построение запроса для проверки - это тоже бизнес-логика.
Варианта предлагается три:
1) внести ее в модель, скрыть обращение к данным за интерфейсами, но в любом случае в итоге наше ядро (модель) лезет в БД, что плохо. В первую очередь плохо концептуально, а если "спустится на землю" - сложнее писать модульные тесты, увеличиваются риски "загрязнения" ядра. Т.е. следующие поколения разработчиков видя, что из модели вызывается СУБД, скажут - а что, так можно было?) И будут тянуть в модель другие внешние зависимости. Теория еще такая есть, разбитых окон. К слову - автор статьи также автор отличной книги о модульном тестировании, я о ней уже писал https://t.me/javaKotlinDevOps/50, возможно поэтому ему данный вариант не нравится
2) оставить часть логики в контроллере. Но тогда получается, что логика размазана по двум слоям
3) заранее загрузить нужные данные в ядро. Допустимо, но только для каких-то маленьких и редко меняющихся справочников, типа регионов. Т.е. только в отдельных случаях.
В итоге у нас компромисс между полнотой модели, строгостью соблюдения архитектурных принципов и скоростью работы.
Что тут интересно - главная идея статьи не о том, как сделать правильно, а про то, что разработка ПО - это искусство компромиссов.
Теорема CAP, упоминаемая в статье, к слову о том же. Единственного правильного для всех случаев жизни решения нет. Увы(
Еще одно дополнение. В теории возможен еще один вариант, расширяющий пространство компромиссов. Он немного "наркоманский" в том плане, что усложняет систему.
Предположим мы сделаем интерфейс валидатора в модели. Правила валидации будет задавать декларативно и хранить в модели, не привязывая их к конкретному хранилищу. Т.е. код контроллера вместо:
validateLogic()
callModel()
превращается в:
val rules = getValidateRulesFromModel()
val request = buildValidateRequest()
validate(request)
callModel()
Сам же и покритикую. Задача вроде решена, но дополнительного кода потребуется много. Второй минус, тоже важный - последовательность вызовов неочевидна. Если новый разработчик придет в команду - очень может быть он скажет "WTF" и захочет переписать. Как решение этой проблемы могу предложить описывать алгоритм в документации к коду или аналитике. Документация не нужна с "говорящим" кодом, но тут как раз исключение. Но сложность понимания кода в любом случае повышается.
Т.об. в пространство компромиссов мы вводим еще один параметр - сложность. Полнота модели, целостность архитектуры, скорость и сложность.
#arch #unittests #dev_compromises
Недавно набрел на интересную статью - https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness
Настоятельно рекомендую ее прочитать, но как всегда вкратце перескажу)
В крупную клетку любой нормально спроектированный сервис включает в себя контроллер (порт в терминологии гексагональной архитекторы), модель и адаптеры.
Вся логика должна быть в модели. Но что делать, если предварительная проверка данных требует обращения к внешней системе (БД), и при этом построение запроса для проверки - это тоже бизнес-логика.
Варианта предлагается три:
1) внести ее в модель, скрыть обращение к данным за интерфейсами, но в любом случае в итоге наше ядро (модель) лезет в БД, что плохо. В первую очередь плохо концептуально, а если "спустится на землю" - сложнее писать модульные тесты, увеличиваются риски "загрязнения" ядра. Т.е. следующие поколения разработчиков видя, что из модели вызывается СУБД, скажут - а что, так можно было?) И будут тянуть в модель другие внешние зависимости. Теория еще такая есть, разбитых окон. К слову - автор статьи также автор отличной книги о модульном тестировании, я о ней уже писал https://t.me/javaKotlinDevOps/50, возможно поэтому ему данный вариант не нравится
2) оставить часть логики в контроллере. Но тогда получается, что логика размазана по двум слоям
3) заранее загрузить нужные данные в ядро. Допустимо, но только для каких-то маленьких и редко меняющихся справочников, типа регионов. Т.е. только в отдельных случаях.
В итоге у нас компромисс между полнотой модели, строгостью соблюдения архитектурных принципов и скоростью работы.
Что тут интересно - главная идея статьи не о том, как сделать правильно, а про то, что разработка ПО - это искусство компромиссов.
Теорема CAP, упоминаемая в статье, к слову о том же. Единственного правильного для всех случаев жизни решения нет. Увы(
Еще одно дополнение. В теории возможен еще один вариант, расширяющий пространство компромиссов. Он немного "наркоманский" в том плане, что усложняет систему.
Предположим мы сделаем интерфейс валидатора в модели. Правила валидации будет задавать декларативно и хранить в модели, не привязывая их к конкретному хранилищу. Т.е. код контроллера вместо:
validateLogic()
callModel()
превращается в:
val rules = getValidateRulesFromModel()
val request = buildValidateRequest()
validate(request)
callModel()
Сам же и покритикую. Задача вроде решена, но дополнительного кода потребуется много. Второй минус, тоже важный - последовательность вызовов неочевидна. Если новый разработчик придет в команду - очень может быть он скажет "WTF" и захочет переписать. Как решение этой проблемы могу предложить описывать алгоритм в документации к коду или аналитике. Документация не нужна с "говорящим" кодом, но тут как раз исключение. Но сложность понимания кода в любом случае повышается.
Т.об. в пространство компромиссов мы вводим еще один параметр - сложность. Полнота модели, целостность архитектуры, скорость и сложность.
#arch #unittests #dev_compromises
Enterprise Craftsmanship
Domain model purity vs. domain model completeness (DDD Trilemma)
I’ve been meaning to write this article for a long time and, finally, here it is: the topic of domain model purity versus domain model completeness.
Всем привет!
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.
Объясняется это тем, что любую внешнюю систему кто-то должен поддерживать, а сейчас в компании этим никто не занимается.
И это на самом деле сильный аргумент, т.к. в больших компаниях разработка и поддержка разделены. А это значит разработчик может затащить новую систему, разворачивать, настраивать и поддерживать которую будет кто-то еще. Более того, если говорить о крупных компаниях - сопровождение там может делиться на прикладное, канальное и инфраструктурное. За СУБД и очереди отвечает последнее.
Что же тут можно сделать?
Просто запретить все новое - вариант очевидно плохой.
А вот снизить "боль" разработчиков, пытающихся внедрить что-то новое, можно так:
1) вести открытый реестр разрешенных технологий. Открытый - значит информацию о нем не нужно искать через корпоративных архитекторов, секретные ссылки и т.д
2) около каждой системы должно быть описание - чем она сильна, какие альтернативы рассматривались и почему в конченом итоге была выбрана именно она
3) должна быть процедура предложений по внедрению новых решений, доступная любой команде
4) в этой процедуре должны быть описаны необходимые для внедрения условия. Тут видится два варианта:
а) внедрение поддерживает множество команд, с конкретными сроками, тогда компания сама "покупает" поддержку - создает команду сопровождения внутри или берет внешних подрядчиков.
б) команда, предложившая новую технологию, сама начинает отвечать за ее поддержку. Как она будет совмещать это со своей текущей деятельностью, потребуется ли ее перевод в инфраструктурные, возможно ее разделение на 2 части - вопрос договоренностей. Ну и да, инициатива имеет инициатора, к этому нужно быть готовым)
5) должны существовать открытые канала для обсуждения новых технологий. Чаты, рассылки, база знаний
Я не изучал, как этот вопрос решается в Agile, но кажется, что должен решаться именно так. В рамках подхода снизу-вверх.
Ну а плохой вариант - когда список технологий спускается откуда-то сверху, назовем это место башней из слоновой кости) А вопросы почему именно это и можно ли что-то добавить подвисают в воздухе, т.к. не понятно, кому их вообще задавать.
#arch #technology
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.
Объясняется это тем, что любую внешнюю систему кто-то должен поддерживать, а сейчас в компании этим никто не занимается.
И это на самом деле сильный аргумент, т.к. в больших компаниях разработка и поддержка разделены. А это значит разработчик может затащить новую систему, разворачивать, настраивать и поддерживать которую будет кто-то еще. Более того, если говорить о крупных компаниях - сопровождение там может делиться на прикладное, канальное и инфраструктурное. За СУБД и очереди отвечает последнее.
Что же тут можно сделать?
Просто запретить все новое - вариант очевидно плохой.
А вот снизить "боль" разработчиков, пытающихся внедрить что-то новое, можно так:
1) вести открытый реестр разрешенных технологий. Открытый - значит информацию о нем не нужно искать через корпоративных архитекторов, секретные ссылки и т.д
2) около каждой системы должно быть описание - чем она сильна, какие альтернативы рассматривались и почему в конченом итоге была выбрана именно она
3) должна быть процедура предложений по внедрению новых решений, доступная любой команде
4) в этой процедуре должны быть описаны необходимые для внедрения условия. Тут видится два варианта:
а) внедрение поддерживает множество команд, с конкретными сроками, тогда компания сама "покупает" поддержку - создает команду сопровождения внутри или берет внешних подрядчиков.
б) команда, предложившая новую технологию, сама начинает отвечать за ее поддержку. Как она будет совмещать это со своей текущей деятельностью, потребуется ли ее перевод в инфраструктурные, возможно ее разделение на 2 части - вопрос договоренностей. Ну и да, инициатива имеет инициатора, к этому нужно быть готовым)
5) должны существовать открытые канала для обсуждения новых технологий. Чаты, рассылки, база знаний
Я не изучал, как этот вопрос решается в Agile, но кажется, что должен решаться именно так. В рамках подхода снизу-вверх.
Ну а плохой вариант - когда список технологий спускается откуда-то сверху, назовем это место башней из слоновой кости) А вопросы почему именно это и можно ли что-то добавить подвисают в воздухе, т.к. не понятно, кому их вообще задавать.
#arch #technology
Всем привет!
Периодически я вижу в коде такую ситуацию.
Есть метод с 5 параметрами, надо передать ему еще 5. Если сделать это "в лоб" - и выглядит ужасно, и SonarQube ругается.
Что можно сделать?
Ну, например, завести объект XYZParams. По сути DTO, используемую в двух классах - вызывающем и вызываемом.
Мне это решение изначально не понравилось, но я не сразу смог объяснить чем именно) Самое простое объяснение - выглядит как lifehack. Требует SonarQube меньше параметров - вот тебе один параметр. Но объяснение мне не нравилось, стал копать дальше.
И как часто бывает - набрел на статью метра, почему это плохо.
https://martinfowler.com/bliki/LocalDTO.html
Советую почитать и вообще занести этот сайт себе в закладки.
Но если вкратце:
1) DTO - как Transfer объект был создан для передачи по сети, когда велики накладные расходы. Ну или для удовлетворения требований безопасности
2) новая DTO - это всегда маппинг, как минимум односторонний. Маппинг - потенциальный источник ошибок при изменениях
3) и добавка от меня: если доменную модель со всех сторон обложить DTO и маппингами - а зачем она тогда вообще нужна?)
Решение же проблемы может быть два:
1) завести подходящие доменные объекты и передавать их, а не одиночные параметры
2) реорганизовать логику, чтобы одному методу не требовалось столько данных
#arch #dto
Периодически я вижу в коде такую ситуацию.
Есть метод с 5 параметрами, надо передать ему еще 5. Если сделать это "в лоб" - и выглядит ужасно, и SonarQube ругается.
Что можно сделать?
Ну, например, завести объект XYZParams. По сути DTO, используемую в двух классах - вызывающем и вызываемом.
Мне это решение изначально не понравилось, но я не сразу смог объяснить чем именно) Самое простое объяснение - выглядит как lifehack. Требует SonarQube меньше параметров - вот тебе один параметр. Но объяснение мне не нравилось, стал копать дальше.
И как часто бывает - набрел на статью метра, почему это плохо.
https://martinfowler.com/bliki/LocalDTO.html
Советую почитать и вообще занести этот сайт себе в закладки.
Но если вкратце:
1) DTO - как Transfer объект был создан для передачи по сети, когда велики накладные расходы. Ну или для удовлетворения требований безопасности
2) новая DTO - это всегда маппинг, как минимум односторонний. Маппинг - потенциальный источник ошибок при изменениях
3) и добавка от меня: если доменную модель со всех сторон обложить DTO и маппингами - а зачем она тогда вообще нужна?)
Решение же проблемы может быть два:
1) завести подходящие доменные объекты и передавать их, а не одиночные параметры
2) реорганизовать логику, чтобы одному методу не требовалось столько данных
#arch #dto
martinfowler.com
bliki: Local D T O
a bliki entry for Local D T O
Всем привет!
Вытяну ссылку из комментариев сюда: https://youtu.be/hUzpe73Oa3g?si=c_dY1YU2Cc_F8YiY
Хороший ролик про границы применимости паттерна Value Object.
На всякий случай - что такое Value Object и чем он отличается от DTO - https://matthiasnoback.nl/2022/09/is-it-a-dto-or-a-value-object/
Также стоит отметить, что данный паттерн является одним из основных в DDD - Domain Driven Development.
А по видео у меня такой краткий вывод - а точнее два:
1) у любого паттерна есть своя область применения
2) когда вы придумали некий хитрый лайфхак, перед тем как реализовывать его в коде стоит взять паузу и подумать.
Насколько он понятен для новичка? Не усложнит ли он код? Насколько? Не станет ли поддержка такого кода сложнее? Не добавит ли он в вашу модель "уязвимость", позволяющую использовать классы и методы не так, как задумывалось изначально?
Часто лучше написать больше простого кода, чем меньше, но неочевидного и допускающего неверное использование. И далее либо разбить этот код на микросервисы, либо на модули - например, см. мой пост про Modulith - https://t.me/javaKotlinDevOps/143
#patterns #arch #dev_compromises
Вытяну ссылку из комментариев сюда: https://youtu.be/hUzpe73Oa3g?si=c_dY1YU2Cc_F8YiY
Хороший ролик про границы применимости паттерна Value Object.
На всякий случай - что такое Value Object и чем он отличается от DTO - https://matthiasnoback.nl/2022/09/is-it-a-dto-or-a-value-object/
Также стоит отметить, что данный паттерн является одним из основных в DDD - Domain Driven Development.
А по видео у меня такой краткий вывод - а точнее два:
1) у любого паттерна есть своя область применения
2) когда вы придумали некий хитрый лайфхак, перед тем как реализовывать его в коде стоит взять паузу и подумать.
Насколько он понятен для новичка? Не усложнит ли он код? Насколько? Не станет ли поддержка такого кода сложнее? Не добавит ли он в вашу модель "уязвимость", позволяющую использовать классы и методы не так, как задумывалось изначально?
Часто лучше написать больше простого кода, чем меньше, но неочевидного и допускающего неверное использование. И далее либо разбить этот код на микросервисы, либо на модули - например, см. мой пост про Modulith - https://t.me/javaKotlinDevOps/143
#patterns #arch #dev_compromises
YouTube
Семен Киреков — Spring, Hibernate, паттерн Value Object и границы его применения
Ближайшая конференция — JPoint 2025, 3–4 апреля (Москва + трансляция).
Подробности и билеты: https://jrg.su/T2zfbS
— —
При разработке ПО всегда заходит вопрос о валидации и корректной работе с данными. Если выполнить бизнес-операцию с неверными входными…
Подробности и билеты: https://jrg.su/T2zfbS
— —
При разработке ПО всегда заходит вопрос о валидации и корректной работе с данными. Если выполнить бизнес-операцию с неверными входными…
Всем привет!
Уже писал от проблеме внедрения новых технологий в enterprise компаниях https://t.me/javaKotlinDevOps/250
Два дополнения.
1) предлагаемое решение можно назвать технологическим стеком, но есть более распространенное «импортное» название - техрадар.
2) вот пример реальной компании, которая серьезно занялась этой проблемой https://habr.com/ru/companies/sbermarket/articles/645661/
Особенно хочу подчеркнуть принцип построения снизу-вверх, или поощряющая vs принуждающая система.
И идею, что техрадар может быть ориентиром для карьерного роста, он же план развития.
#arch #technology #techradar
Уже писал от проблеме внедрения новых технологий в enterprise компаниях https://t.me/javaKotlinDevOps/250
Два дополнения.
1) предлагаемое решение можно назвать технологическим стеком, но есть более распространенное «импортное» название - техрадар.
2) вот пример реальной компании, которая серьезно занялась этой проблемой https://habr.com/ru/companies/sbermarket/articles/645661/
Особенно хочу подчеркнуть принцип построения снизу-вверх, или поощряющая vs принуждающая система.
И идею, что техрадар может быть ориентиром для карьерного роста, он же план развития.
#arch #technology #techradar
Telegram
(java || kotlin) && devOps
Всем привет!
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.…
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.…
Всем привет!
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
1) изучить кукбук, подключить правильные зависимости и сделать правильные настройки) Зависимости - это очевидно для разработки, а вот настройки - далеко не всегда.
2) административка: завести заявку на подключение - в JIRA, Confluence или даже по почте. Вот это совсем не интуитивно, а ошибки, связанные с отсутствием заявки сложно отлаживать. Оправдывают такой процесс обычно так:
а) что новый потребитель - это дополнительная нагрузка, ее нужно запланировать.
б) требованиями безопасности.
в) просто считается, что это нормально
А хуже, если заявки придется делать на каждый используемый стенд.
Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.
Настройки:
а) максимум настроек должны иметь приемлемые значения по умолчанию
б) там, где это невозможно - нужен генератор приложения из каркаса, который сгенерирует шаблон и файл fixme.md с инструкцией как заполнять. Там, где настройки лежат вне приложения - или положить в приложение, или тоже генератор.
Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)
Повторюсь - это концепт, при реализации возможны неочевидные на первый взгляд проблемы, т.к. подключаемые компоненты платформы имеют разную архитектуру и требования.
А основная цель предлагаемых изменений - автоматизировать ручной неочевидный труд, и т.об. снизить число ошибок и время на отладку.
#it #infrastructure #arch #platform
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
1) изучить кукбук, подключить правильные зависимости и сделать правильные настройки) Зависимости - это очевидно для разработки, а вот настройки - далеко не всегда.
2) административка: завести заявку на подключение - в JIRA, Confluence или даже по почте. Вот это совсем не интуитивно, а ошибки, связанные с отсутствием заявки сложно отлаживать. Оправдывают такой процесс обычно так:
а) что новый потребитель - это дополнительная нагрузка, ее нужно запланировать.
б) требованиями безопасности.
в) просто считается, что это нормально
А хуже, если заявки придется делать на каждый используемый стенд.
Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.
Настройки:
а) максимум настроек должны иметь приемлемые значения по умолчанию
б) там, где это невозможно - нужен генератор приложения из каркаса, который сгенерирует шаблон и файл fixme.md с инструкцией как заполнять. Там, где настройки лежат вне приложения - или положить в приложение, или тоже генератор.
Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)
Повторюсь - это концепт, при реализации возможны неочевидные на первый взгляд проблемы, т.к. подключаемые компоненты платформы имеют разную архитектуру и требования.
А основная цель предлагаемых изменений - автоматизировать ручной неочевидный труд, и т.об. снизить число ошибок и время на отладку.
#it #infrastructure #arch #platform
Всем привет!
Продолжение про сагу.
Когда мы говорим про транзакции, сначала всплывает аббревиатура ACID. Транзакции должны обеспечивать принципы ACID. Посмотрим что тут у нас с сагой.
A - атомарность: или все выполняется, или все откатывается. Собственно атормарность есть в определении паттерна, см. выше. Единственное отличие - у нас нет волшебного rollback на всю распределённую транзакцию, бизнес логику отката придётся писать руками.
C - консистентность данных. Сага обеспечивает т.наз. eventually consistentcy - конечную согласованность. Т.е. данные будут согласованы только после окончания распределённой транзакции. В течение транзакции данные в разных микросервисах могут расходится. Транзакция в БД может обеспечить строгую согласованность изменяемых данных с нужным уровнем изоляции. Поэтому переходим к
I - изоляции изменений внутри транзакции от других операций. Сага не обеспечивает ее совсем, что с этим можно сделать описано в статье про это патерн от Microsoft по ссылке выше. Важный момент - в отличие от транзакции в БД, которая как правило длится миллисекунды, распределённая транзакция - это секунды, может даже десятки секунд. Несогласованность данных в течение этого времени из-за отсутствия изоляции нужно иметь в виду. В дополнение к описанным в статье по ссылке способом скажу ещё один - завершать транзакцию как можно быстрее и игнорировать несогласованность данных) Пример: клиент вряд ли будет жаловаться в службу поддержки, если после отмены заказа деньги и бонусы вернутся на счёт в течение минуты. И скорее всего будет - если это не будет сделано через час.
D - надёжность хранения данных, к саге отношения напрямую не имеет, обеспечивается используемыми хранилищами.
Т.к. в итоге мы получили ACD, причем неполноценный, то для распределенных транзакций придумали новую аббревиатуру - Basically Available, Soft-state, Eventually consistent - https://ru.m.wikipedia.org/wiki/Теорема_CAP#BASE-архитектура
Ещё один интересный момент про сагу: определение последовательности шагов - локальных транзакций. Единственно верной схемы нет, но есть рекомендации. Первая - fail fast. Т.е. если есть локальная транзакция, которая упадёт с большей вероятностью - ее нужно ставить вначале. Пример: резерв билета или товара. Вторая - если какая-то локальная транзакция проводит к критичной для клиента несогласованность данных - ее нужно выполнять как можно позже. Что делать, если эти рекомендации противоречат друг другу - зависит от сценария, но в целом я бы выбрал уменьшение времени неконсистентности.
Еще интересный момент касается саги в виде оркестрации. Т.к. ее главный плюс - сделать простой и понятной бизнес логику саги, то самая очевидная ее реализация вот такая:
class OrderSaga {
SagaResult execute() {
// шаг 1
// шаг 2
// ...
}
}
Назовём этот подход Transaction Script, есть такой Паттерн организации бизнес логики.
Просто - да. Но если процесс сложный, каждый шаг тоже, то мы ухудшим читаемость кода, получим замечание SonarQube про длину метода да и нарушим S из SOLID, принцип единой ответственности. Что делать? Использовать event driven подход:
class OrderSaga {
PrepareEvent start(...) {..}
ReserveEvent makeReservation(...) {...}
// ...
}
При необходимости обработку событий можно разнести в разные классы. Чтобы было понимание как работает процесс нужно написать пару модульных тестов - позитивный и негативные сценарии, ведь тесты в идеале - лучшая документация к коду. Ещё один плюс - в событийной стиле легко сделать весь процесс неблокирующим, например, через адаптер отправляя и принимая все события в Kafka. Да, есть ещё БД, запись в БД в эту парадигме - это такое же событие. В этом случае стоит посмотреть в сторону R2DBC https://www.baeldung.com/r2dbc Для REST endpoint и client есть Spring WebFlux.
К слову, Transaction script тоже может обеспечить неблокирующее выполнение, но только в языках программирования с async await: c#, python, rust https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/await
To be continued...
#patterns #saga #microservices #acid #arch_compromises
Продолжение про сагу.
Когда мы говорим про транзакции, сначала всплывает аббревиатура ACID. Транзакции должны обеспечивать принципы ACID. Посмотрим что тут у нас с сагой.
A - атомарность: или все выполняется, или все откатывается. Собственно атормарность есть в определении паттерна, см. выше. Единственное отличие - у нас нет волшебного rollback на всю распределённую транзакцию, бизнес логику отката придётся писать руками.
C - консистентность данных. Сага обеспечивает т.наз. eventually consistentcy - конечную согласованность. Т.е. данные будут согласованы только после окончания распределённой транзакции. В течение транзакции данные в разных микросервисах могут расходится. Транзакция в БД может обеспечить строгую согласованность изменяемых данных с нужным уровнем изоляции. Поэтому переходим к
I - изоляции изменений внутри транзакции от других операций. Сага не обеспечивает ее совсем, что с этим можно сделать описано в статье про это патерн от Microsoft по ссылке выше. Важный момент - в отличие от транзакции в БД, которая как правило длится миллисекунды, распределённая транзакция - это секунды, может даже десятки секунд. Несогласованность данных в течение этого времени из-за отсутствия изоляции нужно иметь в виду. В дополнение к описанным в статье по ссылке способом скажу ещё один - завершать транзакцию как можно быстрее и игнорировать несогласованность данных) Пример: клиент вряд ли будет жаловаться в службу поддержки, если после отмены заказа деньги и бонусы вернутся на счёт в течение минуты. И скорее всего будет - если это не будет сделано через час.
D - надёжность хранения данных, к саге отношения напрямую не имеет, обеспечивается используемыми хранилищами.
Т.к. в итоге мы получили ACD, причем неполноценный, то для распределенных транзакций придумали новую аббревиатуру - Basically Available, Soft-state, Eventually consistent - https://ru.m.wikipedia.org/wiki/Теорема_CAP#BASE-архитектура
Ещё один интересный момент про сагу: определение последовательности шагов - локальных транзакций. Единственно верной схемы нет, но есть рекомендации. Первая - fail fast. Т.е. если есть локальная транзакция, которая упадёт с большей вероятностью - ее нужно ставить вначале. Пример: резерв билета или товара. Вторая - если какая-то локальная транзакция проводит к критичной для клиента несогласованность данных - ее нужно выполнять как можно позже. Что делать, если эти рекомендации противоречат друг другу - зависит от сценария, но в целом я бы выбрал уменьшение времени неконсистентности.
Еще интересный момент касается саги в виде оркестрации. Т.к. ее главный плюс - сделать простой и понятной бизнес логику саги, то самая очевидная ее реализация вот такая:
class OrderSaga {
SagaResult execute() {
// шаг 1
// шаг 2
// ...
}
}
Назовём этот подход Transaction Script, есть такой Паттерн организации бизнес логики.
Просто - да. Но если процесс сложный, каждый шаг тоже, то мы ухудшим читаемость кода, получим замечание SonarQube про длину метода да и нарушим S из SOLID, принцип единой ответственности. Что делать? Использовать event driven подход:
class OrderSaga {
PrepareEvent start(...) {..}
ReserveEvent makeReservation(...) {...}
// ...
}
При необходимости обработку событий можно разнести в разные классы. Чтобы было понимание как работает процесс нужно написать пару модульных тестов - позитивный и негативные сценарии, ведь тесты в идеале - лучшая документация к коду. Ещё один плюс - в событийной стиле легко сделать весь процесс неблокирующим, например, через адаптер отправляя и принимая все события в Kafka. Да, есть ещё БД, запись в БД в эту парадигме - это такое же событие. В этом случае стоит посмотреть в сторону R2DBC https://www.baeldung.com/r2dbc Для REST endpoint и client есть Spring WebFlux.
К слову, Transaction script тоже может обеспечить неблокирующее выполнение, но только в языках программирования с async await: c#, python, rust https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/await
To be continued...
#patterns #saga #microservices #acid #arch_compromises
Baeldung
R2DBC – Reactive Relational Database Connectivity | Baeldung
A quick and practical overview of R2DBC - reactive database connectivity.
Всем привет!
При проектировании системы применяя микросервисный подход всегда появляется главный вопрос - как делить?
Сделаешь слишком крупно - получишь маленький монолит. Это как правило всем понятно, т.к. от монолита мы пытаемся уйти создавая микросервисы.
Но есть и другая крайность - слишком мелкое деление. Уже немного писал об этом https://t.me/javaKotlinDevOps/57
Сейчас же хочу проиллюстрировать эту крайность примером.
Предположим у нас есть некая система, представляющая клиентам CRUD REST API. Create, Read, Update, Delete методы. И еще List, который сильно отличается от Read поэтому должен быть выделен отдельно - pagination, сортировка, кэширование...
Можно применить назовем его "наивный" подход к микросервисам и сделать 5 микросервисов по числу методов API. Точнее даже "миллисервисов")
Что получим?
Вспоминаем, что у каждого микросервиса должна быть своя БД.
Это значит что от микросервисов Create и Delete зависят все остальные, т.к. им нужно будет обновить свою копию данных. Это может быть event driven подход с Kafka, CQRS или что-то другое, но в любом случае это зависимость.
От микросервиса Update зависят Read и List.
А если структура данных меняется?
И это зависимости "из коробки" на сферическом CRUD в вакууме. В реальном кейсе по мере развития системы число зависимостей будет больше. Что получилось? Получился распределённый "ком грязи". Такой же "ком грязи", как в старом неподдерживаемом монолите, от которого мы уходили, только хуже. Там хоть БД одна была и интеграций сильно меньше.
Можно попробовать вынести все взаимодействие с БД в отдельный микросервис Storage, но тогда мы нарушаем Single Responsibility - за ту же операцию Create отвечает и микросервис Create, и микросервис Storage. И Create скорее всего станет слишком простым для отдельного микросервиса.
Пример специально взят простой, в реальности выбор может быть сложнее. Зато на этом примере хорошо видны недостатки "миллисервисов".
P.S. За идею примера спасибо все из той же книжке по DDD, расскажу о ней в ближайшее время.
#microservices #rest #arch_compromises
При проектировании системы применяя микросервисный подход всегда появляется главный вопрос - как делить?
Сделаешь слишком крупно - получишь маленький монолит. Это как правило всем понятно, т.к. от монолита мы пытаемся уйти создавая микросервисы.
Но есть и другая крайность - слишком мелкое деление. Уже немного писал об этом https://t.me/javaKotlinDevOps/57
Сейчас же хочу проиллюстрировать эту крайность примером.
Предположим у нас есть некая система, представляющая клиентам CRUD REST API. Create, Read, Update, Delete методы. И еще List, который сильно отличается от Read поэтому должен быть выделен отдельно - pagination, сортировка, кэширование...
Можно применить назовем его "наивный" подход к микросервисам и сделать 5 микросервисов по числу методов API. Точнее даже "миллисервисов")
Что получим?
Вспоминаем, что у каждого микросервиса должна быть своя БД.
Это значит что от микросервисов Create и Delete зависят все остальные, т.к. им нужно будет обновить свою копию данных. Это может быть event driven подход с Kafka, CQRS или что-то другое, но в любом случае это зависимость.
От микросервиса Update зависят Read и List.
А если структура данных меняется?
И это зависимости "из коробки" на сферическом CRUD в вакууме. В реальном кейсе по мере развития системы число зависимостей будет больше. Что получилось? Получился распределённый "ком грязи". Такой же "ком грязи", как в старом неподдерживаемом монолите, от которого мы уходили, только хуже. Там хоть БД одна была и интеграций сильно меньше.
Можно попробовать вынести все взаимодействие с БД в отдельный микросервис Storage, но тогда мы нарушаем Single Responsibility - за ту же операцию Create отвечает и микросервис Create, и микросервис Storage. И Create скорее всего станет слишком простым для отдельного микросервиса.
Пример специально взят простой, в реальности выбор может быть сложнее. Зато на этом примере хорошо видны недостатки "миллисервисов".
P.S. За идею примера спасибо все из той же книжке по DDD, расскажу о ней в ближайшее время.
#microservices #rest #arch_compromises
Telegram
(java || kotlin) && devOps
Всем привет!
Пару заблуждений про микросервисы.
1) Облачные технологии (k8s) не равно микросервисам. Да, если вы начинаете проект с микросервисами с нуля и есть возможность развернуть его в облаке - так и нужно делать.
Облако упрощает развертывание и масштабирование…
Пару заблуждений про микросервисы.
1) Облачные технологии (k8s) не равно микросервисам. Да, если вы начинаете проект с микросервисами с нуля и есть возможность развернуть его в облаке - так и нужно делать.
Облако упрощает развертывание и масштабирование…
Всем привет!
Одна из моих любимых тем: разработка - искусство компромиссов. Поиск по тэгам #dev_compromises и #arch_compromises. Следствие этого подхода, принцип, который я бы назвал - "не все так однозначно".
Вопрос - как вы относитесь к рефлексии в Java?
Досрочный ответ: рефлексия - это плохо, лучше не использовать. Если дошло до рефлексии - значит в архитектуре проблема.
Чтобы лучше разобраться в теме надо ответить на вопрос: а почему плохо?
Ответа два:
1) рефлексия позволяет нарушить принципы ООП и, следовательно, архитектуру приложения. Автор скрыл внутренности класса через private, а мы туда лезем своими "грязными руками")))
2) снижение производительности. Тут частично работает тот факт, что делаются лишние вызовы кода. Но самое главное - JIT компилятор плохо умеет оптимизировать такой код, т.к. он слишком динамический. Изменится может сам класс, который приходит на вход метода с рефлексией
Окей, инкапсуляция нарушается, код работает медленно. Не используем?
А что с поиском аннотаций по коду? Не своих - до них мы еще дойдем - чужих, чтобы получить некие метаданные об объекте. Большинство вариантов вот тут основано на рефлексии https://www.baeldung.com/java-scan-annotations-runtime
Или у нас есть аннотации, созданные с помощью Spring AOP - это проще, чем AspectJ, если у вас используется Spring. А Spring AOP использует динамические прокси, создаваемые в runtime https://www.baeldung.com/spring-aop-vs-aspectj А с помощью чего создается прокси в runtime - правильно, рефлексии.
Да что там AOP - создание бинов из @Configuration - это тоже вызов методов @Bean через рефлексию.
Почему же рефлексию используют и предлагают к использованию, если это такая проблемная технология?
Вернемся к двум ее недостаткам:
1) не надо использовать рефлексию для вызова private методов или доступа к private полям. Если такая задача встала - у вас в самом деле проблемы с архитектурой
2) не надо использовать рефлексию часто и при этом в высоконагруженных приложениях. Тот же Spring использует рефлексию только при старте приложения для инициализации прокси и бинов. И к слову в т.ч. и поэтому старт Spring приложения может быть долгим, и люди с этим борются, см. мой цикл статей про ускорение старта #java_start_boost Более того, разработчикам Spring для поддержки native image пришлось серьезно допиливать его в т.ч. из-за динамических прокси и @Configuration https://docs.spring.io/spring-boot/reference/packaging/native-image/introducing-graalvm-native-images.html
Итого: рефлексию стоит рассматривать как возможность получить метаданные о классе. Помня при этом о производительности.
И если вопрос упирается в производительность - всегда есть альтернативы рефлексии. Это работа с байт-кодом не в runtime:
1) compile time (свой компилятор, см. статью про AspectJ)
2) post-compile time (свой плагин для сборки, см. Jandex для поиска аннотаций https://smallrye.io/jandex/jandex/3.2.2/index.html)
3) load-time (свой агент+classloader, см. статью про AspectJ)
Все варианты сложнее в реализации и подключении к проекту, зато вносят минимальное влияние в runtime.
P.S. Да, если при упоминании о динамических прокси вы вспомнили про задачку с собесов о вложенном @Transactional - это оно. И ответ на этот вопрос не так очевиден https://habr.com/ru/articles/347752/
#java #reflection #dev_compromises
Одна из моих любимых тем: разработка - искусство компромиссов. Поиск по тэгам #dev_compromises и #arch_compromises. Следствие этого подхода, принцип, который я бы назвал - "не все так однозначно".
Вопрос - как вы относитесь к рефлексии в Java?
Досрочный ответ: рефлексия - это плохо, лучше не использовать. Если дошло до рефлексии - значит в архитектуре проблема.
Чтобы лучше разобраться в теме надо ответить на вопрос: а почему плохо?
Ответа два:
1) рефлексия позволяет нарушить принципы ООП и, следовательно, архитектуру приложения. Автор скрыл внутренности класса через private, а мы туда лезем своими "грязными руками")))
2) снижение производительности. Тут частично работает тот факт, что делаются лишние вызовы кода. Но самое главное - JIT компилятор плохо умеет оптимизировать такой код, т.к. он слишком динамический. Изменится может сам класс, который приходит на вход метода с рефлексией
Окей, инкапсуляция нарушается, код работает медленно. Не используем?
А что с поиском аннотаций по коду? Не своих - до них мы еще дойдем - чужих, чтобы получить некие метаданные об объекте. Большинство вариантов вот тут основано на рефлексии https://www.baeldung.com/java-scan-annotations-runtime
Или у нас есть аннотации, созданные с помощью Spring AOP - это проще, чем AspectJ, если у вас используется Spring. А Spring AOP использует динамические прокси, создаваемые в runtime https://www.baeldung.com/spring-aop-vs-aspectj А с помощью чего создается прокси в runtime - правильно, рефлексии.
Да что там AOP - создание бинов из @Configuration - это тоже вызов методов @Bean через рефлексию.
Почему же рефлексию используют и предлагают к использованию, если это такая проблемная технология?
Вернемся к двум ее недостаткам:
1) не надо использовать рефлексию для вызова private методов или доступа к private полям. Если такая задача встала - у вас в самом деле проблемы с архитектурой
2) не надо использовать рефлексию часто и при этом в высоконагруженных приложениях. Тот же Spring использует рефлексию только при старте приложения для инициализации прокси и бинов. И к слову в т.ч. и поэтому старт Spring приложения может быть долгим, и люди с этим борются, см. мой цикл статей про ускорение старта #java_start_boost Более того, разработчикам Spring для поддержки native image пришлось серьезно допиливать его в т.ч. из-за динамических прокси и @Configuration https://docs.spring.io/spring-boot/reference/packaging/native-image/introducing-graalvm-native-images.html
Итого: рефлексию стоит рассматривать как возможность получить метаданные о классе. Помня при этом о производительности.
И если вопрос упирается в производительность - всегда есть альтернативы рефлексии. Это работа с байт-кодом не в runtime:
1) compile time (свой компилятор, см. статью про AspectJ)
2) post-compile time (свой плагин для сборки, см. Jandex для поиска аннотаций https://smallrye.io/jandex/jandex/3.2.2/index.html)
3) load-time (свой агент+classloader, см. статью про AspectJ)
Все варианты сложнее в реализации и подключении к проекту, зато вносят минимальное влияние в runtime.
P.S. Да, если при упоминании о динамических прокси вы вспомнили про задачку с собесов о вложенном @Transactional - это оно. И ответ на этот вопрос не так очевиден https://habr.com/ru/articles/347752/
#java #reflection #dev_compromises
Baeldung
Scanning Java Annotations at Runtime | Baeldung
Learn about scanning Java annotations at runtime.
Ещё интересный доклад - про нетривиальное использование трейсинга (tracing).
Начнём с того, что далеко не у всех он настроен. Окей, настроили. Теперь нам проще разбирать проблемы на ПРОМ в микросервисной архитектуре.
Все?
Нет) А если взять трейсы за некий период, отсемплировать их уменьшив объём и сложить их в графовую БД? Получим реверс-инжиниринг архитектуры. Причём это будет не «мертвая» архитектура, по кем-то когда-то написанной аналитике, а настоящая. Да, не 100% точная, из-за мертвых интеграций и поломанного трейсинга, но все же. Что с ней можно сделать? Контролировать... архитектуру. Например:
- Общая схема вызовов
- Циклические ссылки
- Длина цепочек вызовов
- Лишние с точки зрения разделения на бизнес-домены связи
- Критичность сервисов - сервисы, которые чаще всего используются другими сервисами
- Однотипные вызовы, которые можно объединить в batch запрос
- Вызовы в цикле
- Анализ использования практики Graceful degradation
Сама идея - практически бесплатный для бизнес-команд инструмент анализа архитектуры - отлично IMHO.
P.S. для этих же целей в теории можно использовать данные из Service Mesh, только добавляется ещё один снижающий точность фактор - не все компоненты находятся в облаке (и не все компоненты в облаке используют Service Mesh)
P.P.S. Конечно идея идеально подходит для компаний а-ля Яндекс и Авито (собственно в Авито ее и внедрили) - там, где нет жёсткого контроля интеграций на уровне согласования аналитики. Но IMHO в любом случае можно использовать как контрольный механизм, ещё одну «сеть»
#arch #tracing
Начнём с того, что далеко не у всех он настроен. Окей, настроили. Теперь нам проще разбирать проблемы на ПРОМ в микросервисной архитектуре.
Все?
Нет) А если взять трейсы за некий период, отсемплировать их уменьшив объём и сложить их в графовую БД? Получим реверс-инжиниринг архитектуры. Причём это будет не «мертвая» архитектура, по кем-то когда-то написанной аналитике, а настоящая. Да, не 100% точная, из-за мертвых интеграций и поломанного трейсинга, но все же. Что с ней можно сделать? Контролировать... архитектуру. Например:
- Общая схема вызовов
- Циклические ссылки
- Длина цепочек вызовов
- Лишние с точки зрения разделения на бизнес-домены связи
- Критичность сервисов - сервисы, которые чаще всего используются другими сервисами
- Однотипные вызовы, которые можно объединить в batch запрос
- Вызовы в цикле
- Анализ использования практики Graceful degradation
Сама идея - практически бесплатный для бизнес-команд инструмент анализа архитектуры - отлично IMHO.
P.S. для этих же целей в теории можно использовать данные из Service Mesh, только добавляется ещё один снижающий точность фактор - не все компоненты находятся в облаке (и не все компоненты в облаке используют Service Mesh)
P.P.S. Конечно идея идеально подходит для компаний а-ля Яндекс и Авито (собственно в Авито ее и внедрили) - там, где нет жёсткого контроля интеграций на уровне согласования аналитики. Но IMHO в любом случае можно использовать как контрольный механизм, ещё одну «сеть»
#arch #tracing
Highload прошел, но интересные доклады еще остались)
"AppHost: как Яндекс организует взаимодействие сотен микросервисов"
Честно - не ожидал такого хода от Яндекса.
В чем суть?
У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.
Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.
Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.
Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.
Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.
#arch #aac #saga #esb
"AppHost: как Яндекс организует взаимодействие сотен микросервисов"
Честно - не ожидал такого хода от Яндекса.
В чем суть?
У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.
Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.
Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.
Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.
Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.
#arch #aac #saga #esb
Всем привет!
Нужно ли хранить информация об архитектуре АС?
Я считаю, что да, нужно.
Почему?
1) контроль интеграций
2) контроль использования компонентов и технологий
3) обмен информацией между командами
Т.к. в канале была серия про AI - вспомним его и сейчас. А что если AI агент будет ходить по репозиториям и собирать информацию об архитектуре в одном месте? В теории да, но есть ряд важных нюансов:
1) доступы ко всем репозиториям. В целом решаемо.
2) достаточность данных в коде для точного определения архитектуры. Трудно решить, часто нужных данных просто нет в коде, т.к. они стендозависимы. Отсюда потенциальные пробелы и галлюцинации.
3) мы получаем слепок AS IS, но TO BE все равно придется рисовать ручками
В целом идея перспективная, но требует проработки. Решения, принятые при анализе архитектуры большой АС или экосистемы имеют сильное влияние на работу множества команд, и хочется принимать их на точных данных.
Поэтому пока рассмотрим другие варианты.
Ок, заводим отдельную АС для хранения архитектуры. Есть UI, можно легко описывать компоненты, интеграции и технологии.
Да, я совершенно забыл о главной проблеме - я практически не встречал разработчиков, горящих желанием описать архитектуру. Где-то на уровне техлида появляются такие люди. Техлид по определению отвечает за архитектуру, но встречается он редко(
Что же делать? А пусть команды сами выбирают, кто отвечает за описание. Весьма вероятно, что этим кем-то станет аналитик. Аналитик конечно же знает архитектуру, но сверху, до определенного уровня. Например, на уровне единиц деплоя, технологий точно будут проблемы. Ок, архитектура описана. К чему приведет данных подход? К тому, что в нашей архитектурной АС будет некое представление актуальной архитектуры, неполное, устаревшее сразу после создания. И поддерживать такую архитектуру в актуальном состоянии никто не будет. Если только из под палки. И самое главное - системой никто не пользуется. Но заполнять надо(
Итого - так можно, но не нужно делать.
Какие главные проблемы:
1) нежелание разработчиков работать за пределами IDE. А именно разработчик понимает архитектуру в целом, как минимум с уровня Senior
2) UI представление данных, к которому так просто не применишь diff и которое легко сломать
3) разрыв AS IS и TO BE - релиза и архитектуры
И, соответственно, как их фиксить:
1) у нас есть IDEA и рабочий проект в git, архитектура должна лежать в проекте вместе кодом. Также нужен плагин IDEA для удобства работы с файлами архитектуры
2) по аналогии с Infrastructure as Code, Documentation as code - Architecture as Code. Вообще говоря Everything as Code, но сегодня про архитектуру). Т.е. все в текстовом виде. OpenAPI, PlantUML в эту парадигму отлично вписываются
3) актуальная архитектура хранится в ветке релиза и согласовывается командой на уровне Pull Request (Merge Request). Целевая - в централизованном репозитории, тоже в git. Актуальная архитектура синхронизируется с целевой тоже через Pull Request, но уже с другими согласующими.
Если до сих пор казалось, что я слишком абстрактен - открою тайну, я веду к конкретной системе, о которой недавно узнал - DocHub.
Снова спасибо @AViIgnatov
Исходники https://github.com/DocHubTeam/DocHub
Живой проект с описанием архитектуре на примере самого себя: https://dochub.info
Цикл статей на Хабре: https://habr.com/ru/articles/659595/ и далее по автору.
К слову, разработка российская, из rabota.ru
Итого: я не уверен, что DocHub - это серебряная пуля. Не могу гарантировать, что он решит проблему контроля и вообще наличия актуальной архитектуры в компании. Все-таки, повторюсь - очень мало людей хотят описывать архитектуру, во многих командах нет соответствующей роли. Я про факт, а не формальности. Но у данного подхода IMHO шансов побольше, чем у всего, что я видел.
#aac #arch
Нужно ли хранить информация об архитектуре АС?
Я считаю, что да, нужно.
Почему?
1) контроль интеграций
2) контроль использования компонентов и технологий
3) обмен информацией между командами
Т.к. в канале была серия про AI - вспомним его и сейчас. А что если AI агент будет ходить по репозиториям и собирать информацию об архитектуре в одном месте? В теории да, но есть ряд важных нюансов:
1) доступы ко всем репозиториям. В целом решаемо.
2) достаточность данных в коде для точного определения архитектуры. Трудно решить, часто нужных данных просто нет в коде, т.к. они стендозависимы. Отсюда потенциальные пробелы и галлюцинации.
3) мы получаем слепок AS IS, но TO BE все равно придется рисовать ручками
В целом идея перспективная, но требует проработки. Решения, принятые при анализе архитектуры большой АС или экосистемы имеют сильное влияние на работу множества команд, и хочется принимать их на точных данных.
Поэтому пока рассмотрим другие варианты.
Ок, заводим отдельную АС для хранения архитектуры. Есть UI, можно легко описывать компоненты, интеграции и технологии.
Да, я совершенно забыл о главной проблеме - я практически не встречал разработчиков, горящих желанием описать архитектуру. Где-то на уровне техлида появляются такие люди. Техлид по определению отвечает за архитектуру, но встречается он редко(
Что же делать? А пусть команды сами выбирают, кто отвечает за описание. Весьма вероятно, что этим кем-то станет аналитик. Аналитик конечно же знает архитектуру, но сверху, до определенного уровня. Например, на уровне единиц деплоя, технологий точно будут проблемы. Ок, архитектура описана. К чему приведет данных подход? К тому, что в нашей архитектурной АС будет некое представление актуальной архитектуры, неполное, устаревшее сразу после создания. И поддерживать такую архитектуру в актуальном состоянии никто не будет. Если только из под палки. И самое главное - системой никто не пользуется. Но заполнять надо(
Итого - так можно, но не нужно делать.
Какие главные проблемы:
1) нежелание разработчиков работать за пределами IDE. А именно разработчик понимает архитектуру в целом, как минимум с уровня Senior
2) UI представление данных, к которому так просто не применишь diff и которое легко сломать
3) разрыв AS IS и TO BE - релиза и архитектуры
И, соответственно, как их фиксить:
1) у нас есть IDEA и рабочий проект в git, архитектура должна лежать в проекте вместе кодом. Также нужен плагин IDEA для удобства работы с файлами архитектуры
2) по аналогии с Infrastructure as Code, Documentation as code - Architecture as Code. Вообще говоря Everything as Code, но сегодня про архитектуру). Т.е. все в текстовом виде. OpenAPI, PlantUML в эту парадигму отлично вписываются
3) актуальная архитектура хранится в ветке релиза и согласовывается командой на уровне Pull Request (Merge Request). Целевая - в централизованном репозитории, тоже в git. Актуальная архитектура синхронизируется с целевой тоже через Pull Request, но уже с другими согласующими.
Если до сих пор казалось, что я слишком абстрактен - открою тайну, я веду к конкретной системе, о которой недавно узнал - DocHub.
Снова спасибо @AViIgnatov
Исходники https://github.com/DocHubTeam/DocHub
Живой проект с описанием архитектуре на примере самого себя: https://dochub.info
Цикл статей на Хабре: https://habr.com/ru/articles/659595/ и далее по автору.
К слову, разработка российская, из rabota.ru
Итого: я не уверен, что DocHub - это серебряная пуля. Не могу гарантировать, что он решит проблему контроля и вообще наличия актуальной архитектуры в компании. Все-таки, повторюсь - очень мало людей хотят описывать архитектуру, во многих командах нет соответствующей роли. Я про факт, а не формальности. Но у данного подхода IMHO шансов побольше, чем у всего, что я видел.
#aac #arch
GitHub
GitHub - DocHubTeam/DocHub: Управление архитектурой как кодом
Управление архитектурой как кодом. Contribute to DocHubTeam/DocHub development by creating an account on GitHub.
Всем привет!
Хочу порекомендовать хорошую статью на Хабре о необходимости кэша.
https://habr.com/ru/companies/oleg-bunin/articles/883422/
Со сравнительными тестами Redis, Memcached, PostgreSQL и MySQL.
Из статьи я почерпнул для себя несколько основных тезисов:
1) в наше время получить 1 000 000 rps с сервера на чтение - это реальность. И это круто! Речь про стандартный сервер, а не 100 ядер\1000 Гб памяти как можно было бы подумать
2) реляционные СУБД приблизились к кэшам (key-value noSQL хранилищам если хотите) по скорости чтения
3) как правильно заметил автор: будь он СТО - не разрешил бы использовать СУБД как кэш. И вот почему. Сравнимая производительность БД-кэш достигается при 2 условиях - нет операций записи в БД (а соответственно и блокировок записей) и все выборки идут по первичному ключу (это самая быстрая операция выборки). Казалось бы - соблюдай эти условия и все будет работать. Но ведь у нас СУБД. Окей, GRANT на запись отберем у всех. Но ведь СУБД может сложные JOIN-ы. И это никак не ограничить правами. Там могут быть сложные индексы. И рано или поздно найдется разработчик, которые эти возможности захочет использовать))) И в пике производительность упадет даже не в разы, а на порядки. Например, не провели НТ. Или забыли обновить профиль НТ. С кэшом такого по понятным причинам не произойдет. Вывод - у каждого инструмента свое назначение.
4) проблема неконсистентности данных кэш-БД все равно будет. Поэтому перед тем, как добавлять в систему кэш - стоит подумать, провести НТ и еще раз подумать. Возможно где-то есть или планируется архивная реплика БД. Там проблема констистентности данных решается механизмом репликации .Если часть нагрузки на чтение увести на нее - возможно кэш и не нужен.
P.S. Отдельная интересная тема: PostgreSQL показывает, что принцип число процессов ОС = числу ядер - не аксиома)
#rdbmc #cache #arch_compromises
Хочу порекомендовать хорошую статью на Хабре о необходимости кэша.
https://habr.com/ru/companies/oleg-bunin/articles/883422/
Со сравнительными тестами Redis, Memcached, PostgreSQL и MySQL.
Из статьи я почерпнул для себя несколько основных тезисов:
1) в наше время получить 1 000 000 rps с сервера на чтение - это реальность. И это круто! Речь про стандартный сервер, а не 100 ядер\1000 Гб памяти как можно было бы подумать
2) реляционные СУБД приблизились к кэшам (key-value noSQL хранилищам если хотите) по скорости чтения
3) как правильно заметил автор: будь он СТО - не разрешил бы использовать СУБД как кэш. И вот почему. Сравнимая производительность БД-кэш достигается при 2 условиях - нет операций записи в БД (а соответственно и блокировок записей) и все выборки идут по первичному ключу (это самая быстрая операция выборки). Казалось бы - соблюдай эти условия и все будет работать. Но ведь у нас СУБД. Окей, GRANT на запись отберем у всех. Но ведь СУБД может сложные JOIN-ы. И это никак не ограничить правами. Там могут быть сложные индексы. И рано или поздно найдется разработчик, которые эти возможности захочет использовать))) И в пике производительность упадет даже не в разы, а на порядки. Например, не провели НТ. Или забыли обновить профиль НТ. С кэшом такого по понятным причинам не произойдет. Вывод - у каждого инструмента свое назначение.
4) проблема неконсистентности данных кэш-БД все равно будет. Поэтому перед тем, как добавлять в систему кэш - стоит подумать, провести НТ и еще раз подумать. Возможно где-то есть или планируется архивная реплика БД. Там проблема констистентности данных решается механизмом репликации .Если часть нагрузки на чтение увести на нее - возможно кэш и не нужен.
P.S. Отдельная интересная тема: PostgreSQL показывает, что принцип число процессов ОС = числу ядер - не аксиома)
#rdbmc #cache #arch_compromises
Хабр
Нужен ли нам сейчас кеш-слой перед СУБД
Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши,...
Всем привет!
Я уже писал про то, что не люблю код, в котором интерфейсы делаются ради интерфейсов. Самый яркий антипаттерн: интерфейс с единственной реализацией, лежащей рядом. Подозреваю, одной из причин такого проектирования является принцип Dependency Inversion - в модели должны быть интерфейсы, а в сервисном слое - их реализации. И они разнесены по разным слоям приложения. Тут вроде все сходится?
Как бы да, но я нашел интересное возражение: https://habr.com/ru/articles/888428/
Как всегда побуду в роли ChatGPT) Суть статьи, а точнее продвигаемого там принципа структурного дизайна в том, что вместо создания интерфейса, любой сложный сервис можно отрефакторить (или спроектировать), выделив 3 метода:
1) чтение - все интеграции по чтению из внешних источников
2) бизнес-логика - тут должны быть чистые классы модели, принимающие на вход только простые типы или коллекции, без побочных эффектов
3) запись результата во внешние источники
2-я часть - это ядро, все остальное - imperative shell. Методы ядра вызываются из imperative shell, зависимости направлены в одну сторону.
Потенциальная проблема - возможно, читать придется много, чтобы загрузить данные для всех условий в бизнес-логике. Решение - дробить бизнес-логику на более мелкие части.
Еще проблема - как отследить, что в метод с бизнес-логикой не передали "побочный эффект". Например, класс, делающий вызов к БД - JPA lazy initialized DTO. Или ссылку на синглтон - Spring bean. Навскидку - только ручное код-ревью. Формально описать проверку объекта на отсутствие побочных эффектов сложно.
Огромный плюс - бизнес-логика всегда легко тестируется, даже без mock-ов.
Еще плюс - код проще.
Вот пример такого рефакторинга: https://www.youtube.com/watch?v=wq9LBouRULs
До чтения статьи, по заголовку, "покушение" на основы чистой архитектуры я воспринял критически. Но после ее прочтения и дальнейших размышлений идея понравилась.
Очевидно, она применима не всегда. Можно описать такую эвристику:
Простой сервис:
1) используем структурный дизайн, четко разделяем чтение с записью от бизнес-логики. С интерфейсами не заморачиваемся.
2) нужна вторая реализация какого-то сервиса - для тестового mock-а, динамической замены в runtime - легко вводим интерфейс с помощью IDE там, где он нужен
Сложный сервис, например:
1) библиотека
2) система с плагинами
3) коробочный продукт с несколькими реализациями под разных клиентов
4) наличие ядра, которое нужно защитить от правок "не доверенными лицами" -
изначально проектируем с интерфейсами в модели и реализациями в сервисах и портах\адаптерах
Принципу KISS - соответствует. Dependency Inversion - как ни странно тоже, т.к. в точной формулировке он звучит так: ядро не должно зависеть от деталей реализации. А структурном дизайне в ядро передаются только простые типы данных и коллекции с ними.
#arch #clean_code #principles
Я уже писал про то, что не люблю код, в котором интерфейсы делаются ради интерфейсов. Самый яркий антипаттерн: интерфейс с единственной реализацией, лежащей рядом. Подозреваю, одной из причин такого проектирования является принцип Dependency Inversion - в модели должны быть интерфейсы, а в сервисном слое - их реализации. И они разнесены по разным слоям приложения. Тут вроде все сходится?
Как бы да, но я нашел интересное возражение: https://habr.com/ru/articles/888428/
Как всегда побуду в роли ChatGPT) Суть статьи, а точнее продвигаемого там принципа структурного дизайна в том, что вместо создания интерфейса, любой сложный сервис можно отрефакторить (или спроектировать), выделив 3 метода:
1) чтение - все интеграции по чтению из внешних источников
2) бизнес-логика - тут должны быть чистые классы модели, принимающие на вход только простые типы или коллекции, без побочных эффектов
3) запись результата во внешние источники
2-я часть - это ядро, все остальное - imperative shell. Методы ядра вызываются из imperative shell, зависимости направлены в одну сторону.
Потенциальная проблема - возможно, читать придется много, чтобы загрузить данные для всех условий в бизнес-логике. Решение - дробить бизнес-логику на более мелкие части.
Еще проблема - как отследить, что в метод с бизнес-логикой не передали "побочный эффект". Например, класс, делающий вызов к БД - JPA lazy initialized DTO. Или ссылку на синглтон - Spring bean. Навскидку - только ручное код-ревью. Формально описать проверку объекта на отсутствие побочных эффектов сложно.
Огромный плюс - бизнес-логика всегда легко тестируется, даже без mock-ов.
Еще плюс - код проще.
Вот пример такого рефакторинга: https://www.youtube.com/watch?v=wq9LBouRULs
До чтения статьи, по заголовку, "покушение" на основы чистой архитектуры я воспринял критически. Но после ее прочтения и дальнейших размышлений идея понравилась.
Очевидно, она применима не всегда. Можно описать такую эвристику:
Простой сервис:
1) используем структурный дизайн, четко разделяем чтение с записью от бизнес-логики. С интерфейсами не заморачиваемся.
2) нужна вторая реализация какого-то сервиса - для тестового mock-а, динамической замены в runtime - легко вводим интерфейс с помощью IDE там, где он нужен
Сложный сервис, например:
1) библиотека
2) система с плагинами
3) коробочный продукт с несколькими реализациями под разных клиентов
4) наличие ядра, которое нужно защитить от правок "не доверенными лицами" -
изначально проектируем с интерфейсами в модели и реализациями в сервисах и портах\адаптерах
Принципу KISS - соответствует. Dependency Inversion - как ни странно тоже, т.к. в точной формулировке он звучит так: ядро не должно зависеть от деталей реализации. А структурном дизайне в ядро передаются только простые типы данных и коллекции с ними.
#arch #clean_code #principles
Хабр
Вам не нужна Чистая архитектура. Скорее всего
Введение Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных...
Всем привет!
Я уже подымал тему готовых архитектурных решений, а точнее их отсутствия в большинстве случаев https://t.me/javaKotlinDevOps/134
Хочу развернуть тему с другой стороны.
Стоит ли тратить силы на поиск целевого архитектурного решения?
Написал эту фразу, и понял, что не всем она может быть понятна) Расшифрую. В больших компаниях ака "кровавый enterprise" есть некий список разрешенных технологий и архитектурных принципов. Оформленный в виде техрадара, карты технологических стеков и сборника архитектурных стандартов. Это и есть целевая архитектура.
Так вот, беда с этим стандартами одна - со временем их становится слишком много, понять - как сделать правильно, чтобы работало годами без переделки - сложно. Нужно на это тратить время: для того, чтобы обойти всех заинтересованных архитекторов, смежные команды, и выработать целевое решение.
Так вот - а надо ли его искать? Несмотря на то, что ответ вроде бы очевиден, хотел бы подсветить несколько потенциальных проблем.
Затрачивая время на поиск и согласование целевого решения мы взамен хотим получить уверенность, что решение с нами останется "на века". Так ли это? Нет, не так. Во-первых мир меняется очень сильно, бизнес задачи меняются вместе с ним. Во-вторых технологии меняются еще сильнее. В-третьих - "кассандр" среди нас мало, и если есть несколько разрешенных технологий - угадать правильную сложно.
К чему это приводит? Мы потратили время на выбор и реализацию "целевки", а через год нам говорят - переделывайте. Отрицание, гнев, фрустрация. Обида на архитекторов. Причем даже если архитектор признает ошибку (и вообще эта ошибка была) - вряд ли он поможет переписать код. Обида на менеджеров - да они издеваются что ли, вечно меняют правила игры, вечная миграция... Желание сменить компанию...
Поэтому видится, что есть более надежный подход.
1) смириться с тем, что все течет, все меняется, и миграции будут всегда
2) искать целевые решение, но всегда держать в уме, что это целевое решение на данный момент
3) разделить весь код на ядро и инфраструктурный код. Ядро стараться писать на чистой Java \ Kotlin, с минимальным использованием фреймворков. Особенно, внутренних, которые еще не доказали свою стабильность. Внешние интеграции закрывать - предохранительный слой (anticorruption layer), шлюзы (gateway), адаптеры.
4) очень важно - уметь и хотеть быстро выпускать релизы, разбивать любые доработки на небольшие инкременты. Это можно сделать как улучшением качества проектирования, увеличением покрытия тестами и автотестами, так и различного рода договоренностями со смежниками, (не забываем, что мы в "кровавом enterprise")
Если вам показывался знакомым последний пункт - то да, это Agile. Или то самое снижение Lead Time (LT), о котором любят говорить менеджеры. И не только говорить) Но в данном случае они правы.
Еще пример - фондовый рынок и диверсификация. Диверсификация считается основным принципом разумного инвестора, и означает, что нельзя "класть все яйца в одну корзину". Т.е. нужно покупать разные классы активов: акции, облигации, вклады, кэш, золото, недвижимость. Причина - сложно угадать, что именно "выстрелит". В случае кода сложно конечно реализовать диверсификацию прямолинейно: часть данных хранить в PostgreSQL, а часть - в Oracle. Да и не нужно. Но предусмотреть возможность замены поставщика - нужно.
#agile #arch #arch_compromisses
Я уже подымал тему готовых архитектурных решений, а точнее их отсутствия в большинстве случаев https://t.me/javaKotlinDevOps/134
Хочу развернуть тему с другой стороны.
Стоит ли тратить силы на поиск целевого архитектурного решения?
Написал эту фразу, и понял, что не всем она может быть понятна) Расшифрую. В больших компаниях ака "кровавый enterprise" есть некий список разрешенных технологий и архитектурных принципов. Оформленный в виде техрадара, карты технологических стеков и сборника архитектурных стандартов. Это и есть целевая архитектура.
Так вот, беда с этим стандартами одна - со временем их становится слишком много, понять - как сделать правильно, чтобы работало годами без переделки - сложно. Нужно на это тратить время: для того, чтобы обойти всех заинтересованных архитекторов, смежные команды, и выработать целевое решение.
Так вот - а надо ли его искать? Несмотря на то, что ответ вроде бы очевиден, хотел бы подсветить несколько потенциальных проблем.
Затрачивая время на поиск и согласование целевого решения мы взамен хотим получить уверенность, что решение с нами останется "на века". Так ли это? Нет, не так. Во-первых мир меняется очень сильно, бизнес задачи меняются вместе с ним. Во-вторых технологии меняются еще сильнее. В-третьих - "кассандр" среди нас мало, и если есть несколько разрешенных технологий - угадать правильную сложно.
К чему это приводит? Мы потратили время на выбор и реализацию "целевки", а через год нам говорят - переделывайте. Отрицание, гнев, фрустрация. Обида на архитекторов. Причем даже если архитектор признает ошибку (и вообще эта ошибка была) - вряд ли он поможет переписать код. Обида на менеджеров - да они издеваются что ли, вечно меняют правила игры, вечная миграция... Желание сменить компанию...
Поэтому видится, что есть более надежный подход.
1) смириться с тем, что все течет, все меняется, и миграции будут всегда
2) искать целевые решение, но всегда держать в уме, что это целевое решение на данный момент
3) разделить весь код на ядро и инфраструктурный код. Ядро стараться писать на чистой Java \ Kotlin, с минимальным использованием фреймворков. Особенно, внутренних, которые еще не доказали свою стабильность. Внешние интеграции закрывать - предохранительный слой (anticorruption layer), шлюзы (gateway), адаптеры.
4) очень важно - уметь и хотеть быстро выпускать релизы, разбивать любые доработки на небольшие инкременты. Это можно сделать как улучшением качества проектирования, увеличением покрытия тестами и автотестами, так и различного рода договоренностями со смежниками, (не забываем, что мы в "кровавом enterprise")
Если вам показывался знакомым последний пункт - то да, это Agile. Или то самое снижение Lead Time (LT), о котором любят говорить менеджеры. И не только говорить) Но в данном случае они правы.
Еще пример - фондовый рынок и диверсификация. Диверсификация считается основным принципом разумного инвестора, и означает, что нельзя "класть все яйца в одну корзину". Т.е. нужно покупать разные классы активов: акции, облигации, вклады, кэш, золото, недвижимость. Причина - сложно угадать, что именно "выстрелит". В случае кода сложно конечно реализовать диверсификацию прямолинейно: часть данных хранить в PostgreSQL, а часть - в Oracle. Да и не нужно. Но предусмотреть возможность замены поставщика - нужно.
#agile #arch #arch_compromisses
Telegram
(java || kotlin) && devOps
Всем привет!
Выпил бокал пива и захотелось немного пофилософствовать)
У меня часть просят готовое решение какой-то проблемы. Это может быть способ интеграции, выбор места для хранения данных, языка программирования, способ разбиения проекта на микросервисы…
Выпил бокал пива и захотелось немного пофилософствовать)
У меня часть просят готовое решение какой-то проблемы. Это может быть способ интеграции, выбор места для хранения данных, языка программирования, способ разбиения проекта на микросервисы…
Качественное ли у вас API? А чем докажете?)
Как мы проверяем код на качество? SonarQube, покрытие кода тестами. Если говорить о code style - CheckStyle-ом. Если говорить об уязвимостях - проверка по базам уязвимостей (разные тулы), Checkmarx.
А можно ли как-то проверить API на соответствие лучшим практикам? В частности, OpenAPI как самый типовой на данный момент вариант.
Да - для этого есть Spectral linter https://meta.stoplight.io/docs/spectral/a630feff97e3a-concepts
У него три основных достоинства:
1) это linter и его можно включить в CI pipeline
2) у него есть наборы предустановленных правил, в частности:
а) OpenAPI rules https://meta.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules
б) URL rules https://apistylebook.stoplight.io/docs/url-guidelines - использование kebab-case, не использование get в URL...
в) OWASP rules https://apistylebook.stoplight.io/docs/owasp-top-10 - безопасность, например, использование uuid вместо чисел в идентификаторах
...
3) возможность добавлять свои правила https://meta.stoplight.io/docs/spectral/01baf06bdd05a-create-a-ruleset в том числе наследуясь от существующих
Ну и отдельно отмечу, что есть плагин для IDEA https://plugins.jetbrains.com/plugin/25989-spectral-linter
Итого - штука полезная, настоятельно рекомендую попробовать.
#api #arch #code_quality
Как мы проверяем код на качество? SonarQube, покрытие кода тестами. Если говорить о code style - CheckStyle-ом. Если говорить об уязвимостях - проверка по базам уязвимостей (разные тулы), Checkmarx.
А можно ли как-то проверить API на соответствие лучшим практикам? В частности, OpenAPI как самый типовой на данный момент вариант.
Да - для этого есть Spectral linter https://meta.stoplight.io/docs/spectral/a630feff97e3a-concepts
У него три основных достоинства:
1) это linter и его можно включить в CI pipeline
2) у него есть наборы предустановленных правил, в частности:
а) OpenAPI rules https://meta.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules
б) URL rules https://apistylebook.stoplight.io/docs/url-guidelines - использование kebab-case, не использование get в URL...
в) OWASP rules https://apistylebook.stoplight.io/docs/owasp-top-10 - безопасность, например, использование uuid вместо чисел в идентификаторах
...
3) возможность добавлять свои правила https://meta.stoplight.io/docs/spectral/01baf06bdd05a-create-a-ruleset в том числе наследуясь от существующих
Ну и отдельно отмечу, что есть плагин для IDEA https://plugins.jetbrains.com/plugin/25989-spectral-linter
Итого - штука полезная, настоятельно рекомендую попробовать.
#api #arch #code_quality
docs.stoplight.io
Concepts | Spectral
The power of integrating linting into the design-first workflow, or any workflow which involves API descriptions, is often overlooked. Linting isn't just about validating OpenAPI or JSON Schema documents against specifications. It's for enforcing ... Powered…