ТРАЗ: Снятие противоречия
Снятие противоречия возможно при сопоставлении утверждения и его цели.
Возможны варианты:
1. утверждение не связано с целью
1. возможно что озвученная цель скрывает реальную (корысть)
2. возможно заблуждение (например - используем микросервисы для упрощения процесса разработки)
2. утверждение не единственный способ реализации озвученной цели
необходимо рассмотрение и сравнение всех вариантов
Пример
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Обеспечить надежность (по метрике RPO) можно не только архивированием.
Переход на Event Source позволяет произвести откат на любое состояние.
При этом архитектура Event Source более производительна при записи.
#ТРАЗ
Снятие противоречия возможно при сопоставлении утверждения и его цели.
Возможны варианты:
1. утверждение не связано с целью
1. возможно что озвученная цель скрывает реальную (корысть)
2. возможно заблуждение (например - используем микросервисы для упрощения процесса разработки)
2. утверждение не единственный способ реализации озвученной цели
необходимо рассмотрение и сравнение всех вариантов
Пример
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Обеспечить надежность (по метрике RPO) можно не только архивированием.
Переход на Event Source позволяет произвести откат на любое состояние.
При этом архитектура Event Source более производительна при записи.
#ТРАЗ
🔥1
ТРАЗ: Идеальный объект
Объект идеален, если его нет, а функция выполняется.
Пример 1
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Переход на Event Source позволяет произвести откат на любое состояние. Архив - идеальный объект. Его больше нет, но его функции выполняются.
Пример 2
Некоторый шлюз перенаправляет запросы и возвращает ответы.
Обслуживается множество клиентов.
Шлюз держит таблицу маршрутизации ID запроса - ID клиента
Необходимо масштабировать шлюз.
Противоречие:
Шлюз должен иметь состояние чтобы маршрутизировать ответы.
Шлюз не должен иметь состояния для масштабирования.
Решение: пусть запрос и ответ содержат ID клиента.
Таблица маршрутизации - идеальный объект.
Общий подход перехода к идеальным объектам
Если при разборе противоречия определяем объект, который должен быть и не быть одновременно - пытаемся избавится от него, переносим его функции на уже имеющиеся объекты.
#ТРАЗ
#TRIZ
#идеальный_объект
Объект идеален, если его нет, а функция выполняется.
Пример 1
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Переход на Event Source позволяет произвести откат на любое состояние. Архив - идеальный объект. Его больше нет, но его функции выполняются.
Пример 2
Некоторый шлюз перенаправляет запросы и возвращает ответы.
Обслуживается множество клиентов.
Шлюз держит таблицу маршрутизации ID запроса - ID клиента
Необходимо масштабировать шлюз.
Противоречие:
Шлюз должен иметь состояние чтобы маршрутизировать ответы.
Шлюз не должен иметь состояния для масштабирования.
Решение: пусть запрос и ответ содержат ID клиента.
Таблица маршрутизации - идеальный объект.
Общий подход перехода к идеальным объектам
Если при разборе противоречия определяем объект, который должен быть и не быть одновременно - пытаемся избавится от него, переносим его функции на уже имеющиеся объекты.
#ТРАЗ
#TRIZ
#идеальный_объект
#ТРАЗ: Правильно сформулированная задача
При решении архитектурных задач часто используют понятие компромисс.
Безопасность или надежность противопоставляется производительности и предлагается найти решение используя более сложные паттерны.
В случае изобретения решения подобные противопоставления не эффективны.
Я не могу решить проблему "надежность против производительности".
Проблема должна быть сформулирована как противоречие.
Например:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
Напрашивается решение рассматривать архив как #идеальный_объект, с выносом его функций на уже существующие объекты системы.
Адепты #ТРИЗ говорят, что не существует правильно сформулированных задач.
Правильно сформулированная задача - это уже решение.
При решении архитектурных задач часто используют понятие компромисс.
Безопасность или надежность противопоставляется производительности и предлагается найти решение используя более сложные паттерны.
В случае изобретения решения подобные противопоставления не эффективны.
Я не могу решить проблему "надежность против производительности".
Проблема должна быть сформулирована как противоречие.
Например:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
Напрашивается решение рассматривать архив как #идеальный_объект, с выносом его функций на уже существующие объекты системы.
Адепты #ТРИЗ говорят, что не существует правильно сформулированных задач.
Правильно сформулированная задача - это уже решение.
#ТРАЗ: Решение задачи переходом на другие уровни
Идеальный объект - не единственный способ снятия противоречия.
Можно решать задачу выводя ее на другие уровни. Для архитектуры ПО это будут уровни инфраструктуры, системы, аппаратного обеспечения и т. п.
Например:
Мы должны передавать данные пакетами (batch) для обеспечения приемлемой пропускной способности.
Мы не должны передавать данные пакетами для обеспечения приемлемой задержки (latency)
Задаем вопрос, почему пропускная способность снижается при передаче одиночных сообщений.
Ответ - накладные расходы. При передаче сообщения дополнительно передаются метаданные в заголовках сообщений. И их процент в общем потоке тем выше чем меньше объем передаваемых данных.
Переформулируем противоречие на другом уровне.
Мы должны передавать метаданные с каждым сообщением для решения транспортных задач.
Мы не должны передавать метаданные с каждым сообщением для обеспечения приемлемых пропускной способности и задержки.
Можем ли мы отказаться от заголовков сообщений ?
Вопрос может решаться на системном и даже на аппаратном уровне.
Идеальный объект - не единственный способ снятия противоречия.
Можно решать задачу выводя ее на другие уровни. Для архитектуры ПО это будут уровни инфраструктуры, системы, аппаратного обеспечения и т. п.
Например:
Мы должны передавать данные пакетами (batch) для обеспечения приемлемой пропускной способности.
Мы не должны передавать данные пакетами для обеспечения приемлемой задержки (latency)
Задаем вопрос, почему пропускная способность снижается при передаче одиночных сообщений.
Ответ - накладные расходы. При передаче сообщения дополнительно передаются метаданные в заголовках сообщений. И их процент в общем потоке тем выше чем меньше объем передаваемых данных.
Переформулируем противоречие на другом уровне.
Мы должны передавать метаданные с каждым сообщением для решения транспортных задач.
Мы не должны передавать метаданные с каждым сообщением для обеспечения приемлемых пропускной способности и задержки.
Можем ли мы отказаться от заголовков сообщений ?
Вопрос может решаться на системном и даже на аппаратном уровне.
image_2022-03-13_13-26-21.png
29.2 KB
#Производительность: Анти-паттерн "Порожняк" (Empty semi trucks)
#ТРАЗ: Разрешение противоречий
Если нет возможности снять противоречие его можно разрешить.
Сквозной пример:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
1. Разрешение во времени (#ТРИЗ предлагает начать с этого)
Пусть архивирование идет тогда когда система бездействует.
2. Разрешение в пространстве
Пусть архивирование идет с копии данных на отдельном носителе.
3. Разрешение в структуре (мой любимый способ - декомпозиция)
Разбиваем хранилище данных по назначению. Рабочая и архивная БД.
4. Разрешение по взаимодействиям
Создаем архив, но приостанавливаем активность при поступлении запроса к данным.
5. Разрешение в отношении (уменьшаем потребность)
Архивируем реже - убеждаем клиентов, что этого достаточно.
Убеждаем, тех кто нуждается в высокой производительности, что производительность удовлетворительная.
Если нет возможности снять противоречие его можно разрешить.
Сквозной пример:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
1. Разрешение во времени (#ТРИЗ предлагает начать с этого)
Пусть архивирование идет тогда когда система бездействует.
2. Разрешение в пространстве
Пусть архивирование идет с копии данных на отдельном носителе.
3. Разрешение в структуре (мой любимый способ - декомпозиция)
Разбиваем хранилище данных по назначению. Рабочая и архивная БД.
4. Разрешение по взаимодействиям
Создаем архив, но приостанавливаем активность при поступлении запроса к данным.
5. Разрешение в отношении (уменьшаем потребность)
Архивируем реже - убеждаем клиентов, что этого достаточно.
Убеждаем, тех кто нуждается в высокой производительности, что производительность удовлетворительная.
При́нцип Ле Шателье́ — Бра́уна (1884 г.) — если на систему, находящуюся в устойчивом равновесии, воздействовать извне, изменяя какое-либо из условий равновесия, то в системе усиливаются процессы, направленные в сторону противодействия изменениям.
Еще раз к вопросу почему переписать систему сложнее чем создать новую.
Еще раз к вопросу почему переписать систему сложнее чем создать новую.
👍1
#ТРАЗ: Ситуация и задача
С точки зрения #ТРИЗ важно различать ситуацию и задачу.
Большинство (~100%) людей пытаются разрешить ситуацию не поставив задачу.
Это же нам рекомендуют во всяких методологиях (например ADD)
Конкретно в ADD поэтапно выявляются архитектурно значимые требования (драйвера) и по ним предлагается решение.
Пример:
Драйвера:
1. Система должна поддерживать доступность 99.99%
2. Время отклика в 99% процентах случаев должно быть ниже 1 сек. при нагрузке 10krps
- Это описание ситуации а не задачи
Решать подобное можно только по инерции (инерция мышления).
Например:
В прошлый раз у нас была такая же задача, мы ее решили используя Кафку.
Решение: используем Кафку
Это решение без постановки задачи, и без определения противоречий.
#ТРИЗ предлагает преодолевать инерцию мышления и первым делом сформулировать задачу.
Например так:
1. Сервис должен поддерживать RTO=0.1 сек для поддержания доступности в 99.99 %
2. Сервис поддерживает RTO=1 сек (по результату моделирования/прототипирования)
Это уже можно решать !
Цитаты в тему
1. Ситуация это еще не задача (ТРИЗ)
2. Нельзя лечить больного по жалобам
С точки зрения #ТРИЗ важно различать ситуацию и задачу.
Большинство (~100%) людей пытаются разрешить ситуацию не поставив задачу.
Это же нам рекомендуют во всяких методологиях (например ADD)
Конкретно в ADD поэтапно выявляются архитектурно значимые требования (драйвера) и по ним предлагается решение.
Пример:
Драйвера:
1. Система должна поддерживать доступность 99.99%
2. Время отклика в 99% процентах случаев должно быть ниже 1 сек. при нагрузке 10krps
- Это описание ситуации а не задачи
Решать подобное можно только по инерции (инерция мышления).
Например:
В прошлый раз у нас была такая же задача, мы ее решили используя Кафку.
Решение: используем Кафку
Это решение без постановки задачи, и без определения противоречий.
#ТРИЗ предлагает преодолевать инерцию мышления и первым делом сформулировать задачу.
Например так:
1. Сервис должен поддерживать RTO=0.1 сек для поддержания доступности в 99.99 %
2. Сервис поддерживает RTO=1 сек (по результату моделирования/прототипирования)
Это уже можно решать !
Цитаты в тему
1. Ситуация это еще не задача (ТРИЗ)
2. Нельзя лечить больного по жалобам
Говорим по-русски
Solution architect - зодчий-решала
Solution architect - зодчий-решала
😁4
Еще два класса
“Ninja architect”: Disappears at the same speed as it appeared.
“Master of wizards”: It has the noscript but disappears in the most critical moments.
отсюда - https://dzone.com/articles/defining-architecture-decision-record
“Ninja architect”: Disappears at the same speed as it appeared.
“Master of wizards”: It has the noscript but disappears in the most critical moments.
отсюда - https://dzone.com/articles/defining-architecture-decision-record
DZone
Defining Architecture Decision Record (ADR)
Find out what ADR is and how this document supports software architecture decision-making in addition to making your architecture more scalable in this article.
👍2
Добрые люди поделились книжкой "Mastering ArchiMate"
https://libgen.is/book/index.php?md5=449A2BF7488A69C830BD06027E58FD16
https://libgen.is/book/index.php?md5=449A2BF7488A69C830BD06027E58FD16
libgen.is
Library Genesis: Gerben Wierda - Mastering ArchiMate Edition III: A serious introduction to the ArchiMate® enterprise architecture…
Library Genesis is a scientific community targeting collection of books on natural science disciplines and engineering.
👍3
Методы принятия арх. решений v1.pdf
1.1 MB
Презентация выступления на Сообществе архитекторов IT-One
Тема: Методы принятия архитектурных решений
Тема: Методы принятия архитектурных решений
👍2
Messaging
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍3😁1
Messaging.Topic
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍1
Прямоугольники и стрелочки
Messaging.Topic Возвращаясь к теме обмена сообщениями👆 Чем топик хуже нетипизированого набора данных в БД: 1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное. Тем более со всей этой распределёнкой порядок сообщений в топике все…
Топики против базы данных (продолжение)
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
architectural-decision-records.pdf
266.9 KB
Гайд по ADR от AWS