http://microservices.io/i/SuccessTriangleWithBooks.png

Красивая картинка у К. Ричардсона.

"Ignoring those two elements is a common anti-pattern of microservice adoption."

Нефункциональные требования и ограничения (Constraints)

Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).

Часть этих данных структурирована, часть нет (т.н. контекст проектирования).

В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".

В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.

Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?

Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.

Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.

Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.

2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.

3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.

#АрхитектурныеДрайвера

База знаний в обсидиане

Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.

Теперь для включения в новый проект достаточно распаковать и запустить.

Положу здесь. Возможно, еще кому-нибудь пригодится.

#Документирование

Анти-паттерн "42"

Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.

Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.

При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.

#Антипаттерны #Сарказм

Транзакционность

Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.

Хотел бы здесь зафиксировать своё понимание транзакционности.

1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.

План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )

#Транзакционность

Сага

Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.

Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.

#Сага #Транзакционность

BPM-движки

Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.

Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?

Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?

По факту пробел заполняют разработчики, внося в начальную красивую диаграмму массу деталей. При этом преодолевая вязкость нотации bpmn, которая вовсе не хочет становиться языком программирования.

Архитектурное решение

Мне не нравится когда говорят, что архитектор принимает решение.

Принимать решение удел менеджера.

Архитектор обдумывает и прорабатывает решение.

Процесс архитектора несколько более затратный.

Это не сложный выбор и не волевое действие.

Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.

Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".

Аутсорсинг

Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.

Только что был экспертом и опять джун)

Фрагментарность ИТ-знаний

Большая проблема ИТ инженерии - фрагментарность знаний.
При этом каждый фрагмент написан автором на своём, зачастую уникальном, языке.

Причины понятны:
1. Знания формируются бессистемно, рецептурно различными, не связанными с друг другом авторами.
2. Цель - найти приемлемое рабочее решение, и не более.

Приведу пример.

1. Сущность (entity) у Эванса это идентифицируемый объект.
В DDD идентифицируемость указывается как самое важное свойство сущности. При этом Эванс предостерегает от превращения в сущности всего и вся, намекая на некоторые проблемы связанные с поиском эквивалентности.
2. Проблемы сущностей описаны у М. Фаулера в "Аналитических паттернах". Правда термин "сущность" здесь не упоминается. Паттерн называется "обращение к объектам" ("Referring to Objects"). Основные проблемы по Фаулеру порождаются несколькими источниками возникновения сущности. Эти проблемы: множественная идентификация, слияние и поиск эквивалента. Фаулер даёт несколько паттернов решения проблем не углубляясь в их реализацию.
3. Столкнувшись на практике с проблемами сущности вы скорее всего будете реализовывать сущность как золотую запись. Еще один термин, в этот раз из мира управления данными.
Вам потребуется MDM система. Возникнут вопросы связанные с природой сущности (НСИ, товар, продукт, контакт и т. п.), так как для каждого вида существует своя оптимальная MDM (RDM, PDM, CDI и др.)

То есть три разных фрагмента демонстрируют разные уровни работы с одним и тем же объектом, используя разные термины и в общем случае не связанные с друг другом.

Синтезируем это всё в голове архитектора.

И к сожалению, никто не берётся за систематизацию этого бардака (

Утилита для расчета SLA по доступности

Понадобилось быстро перекинуть девятки в часы.
Обычно пользуюсь для этого таблицами.
Сегодня набрел на удобную утилиту, ссылку на которую оставлю здесь.
https://shootnick.ru/uptime/

Связывание по структуре данных (stamp coupling)

Казалось, что времена огромных отраслевых XML и таблиц в далёком прошлом.
Ан нет.(

Очередной заказчик предлагает собрать все возможные документы и обобщить их в единую структуру.

Нехилое развлечение для аналитиков.

Вопрос "что будет при появлении новых документов или при модификации существующих" - не возникает.

То, что сервисы шарящие базу, будут связаны как сиамские близнецы - проблема технарей, бизнес не волнует.

Архитектора убежали от SOAP и с ужасом косятся на всякие gRPC. Так получим это все в реляционку.

Есть решение снимающее эти проблемы?

Есть и даже два:
1. Свободный контракт от потребителя
(идеален, но требует зрелости команды)
2. Свободная форма (а ля k-v) + мета
(снимает связанность, но усложняет систему)

Продавливаем второй вариант

Архитектор-пропагандист

Хочу представить очень распространенный анти-паттерн "Архитектор-пропагандист".

Проблема:
"Специалист" вместо поиска решения активно продвигает "правильный" вариант, забыв основную мантру архитектора "It depends".

Симптомы:
Фразы типа:
- Это best practices, так все делают
- Это паттерн взятый у [имярек] и он не может быть неправильным
- Мы делали так на предыдущем проекте, и это великолепно работает

Решение:
Любое правильное "решение" должно быть взвешено в конкретном контексте и подвергнуто сравнению с другими решениями.

Следствие:
Приведенное выше решение тоже не всегда верно)

#Антипаттерны

Логический и физический уровни системы

При архитектурном анализе системы рекомендую подход, разбивающий модель на логический и физический уровни.
Очень многое становится понятным.
Хороший пример области проблемы и решения в DDD.
Другой пример - распределённые транзакции (см. рисунок)

Бизнес процесс состоит из атомарных действий, которые отображаются на физические транзакции и (сюрприз!) не один в один.

Варианты:
Действие1. Идеальный расклад однозначного соответствия. Атомарность действия и атомарность реализации.
Действие 2. Грустный случай разбиения атомарного действия на две не атомарные транзакции. Этого стоило бы избегать, но не всегда возможно.
Можно попытаться связать физические транзакции блокировками (распределённая транзакция) - но получится нестабильно и медленно.
Делаем сагу. На логическом уровне атомарность. На физическом отменяемость (abortability у Martin Kleppmann).
Есть масса способов не дать клиенту увидеть проблемы реализации.
И пусть специалисты спорят атомарна ли сага))
3. Действия 3,4. Чрезмерное усложнение. Так лучше не надо.
Два неатомарных действия лучше догнать по итогу (eventually), чем мучиться с откатом и возможным неуспешным откатом.

#Сага #Saga

Контроль потока

При формировании сервисной архитектуры одним из первых стоит вопрос о механизме взаимодействия.
И перед тем как снизойти до технологии нужно определить что это будет sync или async.
То есть будет клиент ждать ответ или отпустит ресурсы и займется своими делами.

Критерии выбора описаны во множестве пособий.
За асинку - эффективность (низкая ресурсоемкость), надежность, безопасность.
За синку - простота (обработка ошибок, отладка), распространённость.

Хотел бы подсветить еще один, редко упоминаемый фактор.

Синк формирует т.н. закрытую модель взаимодействия с предсказуемой нагрузкой.
Пропускная способность здесь пропорциональна количеству пользователей и обратно пропорциональна времени оборота запроса - X <= M/T (до участка насыщения)
Синхронная система саморегулируема.
Появляются новые пользователи -> растет нагрузка -> растет время оклика -> снижается нагрузка. Клиент не шлет новый запрос не дождавшись завершения предыдущего.

В асинке такой защиты нет. Один клиент может накидать в очередь сколь угодно много запросов.
Асинхронная система открыта, в частности всякому DOSу, и должна быть защищена.

Выбирая асинк честный архитектор должен сразу же усложнить нагруженную систему механизмом контроля потока.
Реализовать контроль потока можно по разному:
1. Ограничением нагрузки (rate limiting)
2. Ограничением времени выполнения (deadline)
3. Дросселированием участников (throttling)
4. Обратным давлением (back pressure)
Но сделать это нужно обязательно.

Так что выбирая async на нагруженном участке вы заодно принимаете и усложнение системы. (

#производительность

"Типы" производительности

Любой архитектор знает, что производительность одно из основных качеств программной системы.
Риск не попасть в требования по производительности один из самых вероятных.

Многие при этом догадываются, что под словом "производительность" скрываются абсолютно разные хотелки заказчика.

Розански и Вудс выделили целых шесть типов заинтересованности:
1. Приемлемое время отклика (Фаулер называет это Отзывчивостью, Responsiveness)
2. Приемлемая пропускная способность (Мощность, Capacity)
3. Способность системы справляться с ростом нагрузки (Масштабируемость, Scalability)
4. Приемлемый разброс минимальных и максимальных времен отклика (Предсказуемость, Predictability)
5. Низкая потребность в аппаратных ресурсах (Эффективность, Efficiency)
6. Приемлемое поведение при пиковых нагрузках (Нил Форд и Марк Ричардс называют это качество Адаптируемостью, Adaptability)

Список большой, но на мой взгляд всё-таки не полный 🙂

Часто сталкиваюсь с заинтересованностью заказчика в справедливости (fairness):
Маленькие задачи должны обрабатываться быстро, вне зависимости от наличия больших задач.

У справедливости есть своя метрика - slowdown (отношение времени отклика к размеру задачи).
Желательно, чтобы это отношение было константой.

Есть свои приемы достижения справедливости. В частности различные алгоритмы планирования и балансировки.

Так что справедливость вполне состоявшееся качество.

Включаю в свой список.)

#производительность

Задачка на справедливость

Реальная задача из прошлого:
Есть кластер БД (Postgres), который кормится с очереди (Kafka).
Высокая нагрузка. И очень высокие требования по производительности.
Заказчик желает минимизировать задержку.
Неповторяющиеся запросы поступают через случайные промежутки времени (М) и имеют существенный разброс по времени выполнения (G).
То есть очередь M/G/N.
В плюс: запросы регламентированы и можно оценить время их выполнения.

Мы не можем улучшить эффективность выполнения запросов.
Мы не можем докинуть железа.

Что остается?
Играть с планировщиком запросов.
Многие недооценивают этот механизм, но он реально позволяет в разы улучшить среднее время выполнения запросов .

Идеальное решение:

По условию задачи идеальной политикой балансировки/планировщика должна быть общая очередь на SQRT(1) (Central-Queue-SRPT)
Не тут то было (. Сыграть на Postgres "мелодию" с вытеснением запросов - нереально.
- ограничение №1 - слоник.

Можно было бы использовать TAGS(2):
Поставить в ряд несколько инстансов с возрастающими таймаутами и тот, кто не успел обработать свой запрос, передает следующему.
Postgres вполне может прервать задачу по таймауту.
Но нет (
ограничение №2 кластер PG чужой (AD) и кроме тупого FIFO ничего не умеет.

Остаются самые скучные варианты: SJF(3) и FSFC (FIFO).
По среднему времени отклика в наших условиях SJF чуть лучше и вроде бы игра не стоит свеч.
Однако здесь вспоминаем о справедливости.

Клиент, посылающий короткий запрос, не хотел бы ждать, пока система провернет глыбу аналитики.

Строим две очереди: легкие и тяжелые запросы.
Тянем из первой, пока не пусто. Если кончились, идём во вторую.

Но будь моя воля, разобрал бы кластер и поставил цепь из инстансов PG с мапом на размер запроса.
Получил бы очень хорошие показатели )

(1) SQRT - вытесняющий алгоритм планирования, пропускающий вперед запросы с минимальным оставшимся временем обработки
(2) TAGS - “Task Assignment by Guessing Size” успешно используется в Microsoft и Unix системах
(3) SJF - Вначале обрабатывает быстрые запросы

#производительность

Иллюстрация к предыдущему посту

Зависимость среднего времени отклика от нагрузки для разных алгоритмов планировщика

Source: Prof. Mor Harchol-Balter, http://www.cs.cmu.edu/~harchol/


P.S. Заменил на гифку - чтобы оценить масштаб проблемы при увеличении вариативности времени выполнения

БД и алгоритмы планирования

К слову, вот такая интересная табличка по БД

👆 Ну да.)

Любимый "Слоник" вытягивает вариативность за счет многопоточности. Вероятность того что одновременно придет 16 "аналитических" запросов не должна быть высокой.

MS же честно пилит запросы на кванты обеспечивая идеальную справедливость при приемлемой задержке.

Кстати, в следующую пятницу т.е. 27.10.2023
читаю доклад на ArchDays 2023

Простая «архитектурная» задача и немного ТРИЗ

Заходите, пообщаемся )

https://archdays.ru/?speaker=1346&session=1469