Поговорим немного об атрибутах качества применительно к микросервисам.

Reusability (возможность повторного использования)

Повторное использования – основной способ снижения затрат. Хотя достижение возможностей повторного использования может быть дорогим, оно может существенно снизить стоимость разработки. В основном это достигается за счет закладывания возможностей изменения целей использования микросервиса для использования за пределами домена для которого он проектировался с минимальными изменениями кода.

Ключевая мысль: это не повторное использование того же микросервиса, это возможность минимальными затратами адаптировать микросервис для самостоятельного использования в другом домене. То есть reusability в микросервисах тесно связана с возможностями кастомизации.

Для обоснования достаточно посмотреть на это через призму наличия/отсутствия [блокирующих] зависимостей и координационную нагрузку при согласовании вносимых изменений.

Разумеется, необходимо различать прикладные сервисы, вроде «Уведомлений», «Идентификации» и доменно-специфичные микросервисы.

Например, сервис «Уведомлений» может использоваться множеством других сервисов, но при этом ничего не будет знать о доменной специфике сервисов, использующих его. Но представим, что наш сервис уведомлений изначально был разработан в домене «Кредитования» под собственные задачи. Он знает, что такое «Уведомление о просроченном платеже», что такое «Уведомение о следующем платеже». И вот мы решили его заиспользовать еще и для домена страхования, дополнив событиями «Уведомение о страховом случае», «Уведомлении о необходимости продлить страховой контракт». Тем самым была создана сильная зависимость между доменами Страхования и Кредитования и теперь изменения, вносимые одним из доменов в сервис «Уведомлений» потребуют координаци с другим доменом. Этот сервис более не является микросервисом, так как его граница не проходит по границе бизнес-домена, он совмещает в себе ответственности двух различных доменов. Вариантов здесь может быть два:
1. Выделить наравне с доменами «Кредитование» и «Страхование» домен «Уведомления», в домен «Уведомления» войдет только специфичная для этого домена функциональность и никаких знаний о кредитовании или страховании.
2. Развернуть в домене «Страхование» собственный сервис «Уведомлений», который будет знать только об специфичных для страхования уведомлениях.

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

А вот здесь было еще про повторное использование:
https://tttttt.me/microservices_arch/171

Напомню вывод в конце:
Итого, делаем вывод, что для микросервисов в их первоначальном определении повторное использование не применимо из прагматичных соображений. Каждый микросервис создается под свои границы в конкретной модели предметной области бизнеса. Повторное использование микросервиса приводит к появлению нового микросервиса в новом контексте, развивающегося автономно от изначального микросервиса.

Мои заметки по этой главе (фактически краткий конспект, практически без моих вставок, будет только одна, но вообще-то спорных моментов там много) с подготовки к эфиру.

Мы перешли от потребности в высокой доступности к потребности в полной доступности с предоставлением хотя бы минимально-функционирующего сервиса в случае возникновения любой проблемы.

Сбой (fault) – это некоторое случайное  состояние/условие, возникновение которого может привести к тому, что система или ее компонент не будут работать должным образом. Сбой может привести к отказу.

Отказ (failure) – отклонение системы или компонента от требуемого поведения.

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

Лучше определять доступность применительно к конкретным сценариям, а не системе в целом, но даже в этом случае есть проблемы с измерением доступности в девятках:
- бизнес хочет максимум (но это дорого)
- на практике бизнес не видит разницы между пятью и тремя девятками
- девятки не берут во внимание момент наступления отказа (утро воскресенья vs черная пятница)

Надежность (Reliability) – вероятность работы программного обеспечения без отказов (failure) в течение заданного периода времени в заданной среде. Строится поверх доступности, система может быть доступной, но не надежной

Доступность и надежность – это наблюдаемое поведение реальной системы.

Способы достижения доступности и надежности:
– Высокая доступность (high-availability) в основном через кластеризацию и репликацию всей системы и/или всей базы данных соответственно, – заточены под большие, монолитные системы.
– Устойчивость (Resilience) – каждая часть системы несет ответственность за доступность системы в целом путем адаптации своего поведения при возникновении сбоев, например, через ретраи или автоматический рестарт процессов, ограничение распространения ошибок.

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

Аспекты предотвращения отказов, все три применяются к людям, процессам и технологиям (Jean Pariès, John Wreathall, David Woods, and Erik Hollnagle, Resilience Engineering in Practice: A Guidebook (CRC Press, 2013))
- Знать что делать для того, чтобы можно было продолжить оказание сервиса (добавить capacity, перезагрузить, ограничить нагрузку)
- Знать что искать, – это про мониторинг для отслеживания ситуаций, которые привели или могут привести к снижению доступности
- Знать, что произошло, чтобы иметь возможность учиться на ошибка
- Знать, чего ожидать, – используя накопленную информацию и предсказательные модели определять потенциальные проблемы

Измерение и обучение
- Встраивание механизмов измерения
- Регулярный анализ данных
- Проведение ретроспектив
- Выявление возможностей улучшения
- Непрерывное улучшение

Основные метрики доступности: mean time between failures (MTBF) and mean time to recover (MTTR), но с ними есть проблемы:
- Что понимать под отказом?
- Что понимать под восстановлением?
- Если произошел отказ, но он скрыт от пользователя, это отказ или нет?


TTR = RTO + N, RTO = f(RPO)

recovery time objective (RTO) - за какое время данные должны быть восстановлены
N - время на восстановление функциональности
recovery point objective (RPO) - сколько данных может быть потеряно

RPO -> inf => RTO -> 0
RPO -> 0 => RTO -> max

RTO/RPO измеряются на уровне системы и на уровне компонентов.

John Allspaw, was that “TTR is more important than TBF (for most types of F).

Обучение должно проходить не только на ошибках, но и на успехе:
- По какой причине в данной ситуации система оказалась устойчивой?
- Люди предвидели проблемы и не позволили им проявится?
- Избежать проблем позволили хорошие автоматизированные механизмы?
- Это была просто удача?

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

Механизмы обеспечения Resilience

Обнаружение проблемы
- Health Checks - рекомендуются синтетические транзакции
- Watchdogs and Alerts(A watchdog is a piece of software whose only responsibility is to watch for a specific condition and then perform an action, usually creating some form of alert, in response.)
- monitoring (metrics, traces, and logs)Metrics are the numeric measurements tracked over time. Traces are sequences of related events that reveal how requests flow through the system. Logs are the timestamped records of events.
- observability(extending monitoring to provide insight into the internal state of the system to allow its failure modes to be better predicted and understood)
(we need to understand how the system works and the various states it can be in, and we must be able to correlate from the data we have collected to what state the system is in (or was in) and how it got there)

Изоляция проблемы
- Synchronous versus Asynchronous Communication: RPCs versus Messages
- Limit the scope of a failure- Bulkheads (по сути - не клади все яйца в одну корзину, тут все от отдельных потоков до зон доступности)
- Defaults and Caches

Защита компонентов системы от перегргузки
– Back Pressure(some sort of signaling back through the system so that the clients can tell that the servers are over- loaded and there is no point in sending more requests yet)
- Load Shedding(reject workload that can’t be processed or that would cause the system to become unstable)
– rate limiting usually defined in terms of the rate of requests arriving from a particular source (e.g., a client ID, a user, or an IP address) in a time period
- Timeouts(defines how long the caller will wait, and we need a mechanism to interrupt or notify the caller that the timeout has occurred so that it can abandon the request and perform whatever logic is needed to clean things up)
- Circuit Breakers(small, state machine–based proxy that sits in front of our service request code;)

Смягчение проблемы
- Data Consistency: Compensation(for any change to a database (a transaction), the caller has the ability to make another change that undoes the change (a compensating transaction))
- Data Availability: Replication(mitigate node failure by ensuring that the data from the failed node is immediately available on other nodes)
- Data Availability: Checks (checking the underlying storage mecha- nism’s integrity and checking the integrity of the system’s data) (tactics to use to mitigate data corruption are regular checking of database integrity, regular backup of the databases, and fix- ing corruption in place)
- Data Availability: Backups

Решение проблемы

А смотрите, что нашел @izonov 🙂
Я и не знал, что оно есть в записи, почти 8 лет прошло.

https://www.youtube.com/watch?v=y3gSUa1U8E4

Вот в этом выступлении как раз, в конце, перечисляю некоторые из принципов, изложенных позднее в книге Cont. Arch. in Practice, что и удивило, когда книгу читал 🙂

Такая вот картинка, например.

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

Название компании неизвестно, известно только, что это Social Media Platform.

Какой вселенский стыд для dev.to :)

https://dev.to/nikl/how-to-build-a-containerized-microservice-in-golang-a-step-by-step-guide-with-example-use-case-5ea8



Database Service
This service manages the application's databases, storing user information, their roles, access privileges, and documents without watermarks. Documents can't have watermarks when created; success is achieved only when data input is valid, and the database service returns success.

We'll use two separate databases for the two services, adhering to the "Single Database per Service" principle of microservices architecture. 🤯😳

ChatGPT for Microservice Development: How far can we go?

RQ1 Is it possible to fully build a microservices system only using ChatGPT?
RQ2 What are the limitations of ChatGPT for building microservice architecture?
RQ3 What manual/human interventions are needed?

У паттерна retry есть свои паттерны, смотрим статью:

https://engineering.mercari.com/en/blog/entry/20210126-retry-pattern-in-microservices/

Аутентификация для WebSocket до сих пор нет стандарта. Андрей Кузнецов.

Протокол WebSocket появился более 10 лет назад, однако, до сих пор в стандартах отсутствуют рекомендации по выполнению аутентификации для WebScoket-соединений. Обсудим, что же это за зверь такой – WebSocket, почему вообще нужна аутентификация и где здесь можно ошибиться, а также сравним разные варианты ее реализации, включая неочевидные особенности и проблемы.

https://youtu.be/coinSGTsge0

Всех с наступающим новым годом!

И новое видео с ArchDays

Обсуждение синергии увязки компонентов бизнес- и ИТ-архитектуры.

https://www.youtube.com/watch?v=x8xEXAznrEk