Микросервисы / распределенные системы
3.87K subscribers
105 photos
1 video
21 files
312 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Если есть вопросы или предложения, пишите @sergey486
Download Telegram
chaos-engineering.pdf
1.6 MB
В прошлом году принимал участие в круглом столе на конфе от Сбера, речь шла об антихрупкости.
Вроде как должна быть запись, здесь поделюсь своими заметками о дорожной карте достижения антихрупкости.

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

Антихрупкость – это свойство, при котором система становится лучше под воздействием стрессора. С возрастанием интесивности воздействия стрессора (до определенного предела) возрастает выгода (сокращается вред).

Стратегия достижения антихрупкости
1. Минимизировать возможные потери при отказах
2. Избежать катастрофических сценариев, правильно хеджируя риски. Риски, согласно этой модели, бывают только высокими и близкими к нулю. Эта мысль мне показалась не очевидной, но интересной. Как только наиболее серьезные угрозы устранены, менее серьезные могут видоизмениться за счет обучения на основе окружающей среды. Если ядро системы относительно безопасно, неосновные части системы могут извлечь выгоду из внешних стимулов для повышения антихрупкости.
3. Внедрить адаптивную отказоустойчивость. Автоматическое исправление ошибок (т. е. метод автоматического восстановления программного обеспечения) должно быть частью архитектуры. Я бы несколько удивлен, что существуют работы 90-х годов и более ранних о том, каким образом под изменяющийся контекст динамически меняется даже не исходный код или структура решения, а исполняемый код. Примерно об этом Digital Immunity

Микросервисный архитектурный стиль позволяет проявится антихрупкости. Однако микросервисы сами по себе не являются решением, а лишь enabler'ом. Они не «учатся» на ошибках, они просто устойчивы, а возможности обучения повышают, например техники fault injection (тот же chaos eng).

В аттаче пара важных статей и небольшая книжка по теме.
Микросервисы / распределенные системы
Путь в хаос или как мы строили Chaos Engineering в банке Дмитрий Якубовский и Максим Козлов https://www.youtube.com/watch?v=PVufzlkhRcI Доклад расскажет о том, как мы на реальном проекте погрузились в мир Chaos Engineering (CE), ощутили всю боль мониторинга…
Было и такое выступление на первом ArchDays

Путь в хаос или как мы строили Chaos Engineering в банке
Дмитрий Якубовский и Максим Козлов


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

Доклад расскажет о том, как мы на реальном проекте погрузились в мир Chaos Engineering (CE), ощутили всю боль мониторинга, узнали о психологии инженеров и как вставляли "напильники в серверы". Мы поговорим о преимуществах Chaos Engineering и без чего он не получится, расскажем, почему он отличается от нагрузочного тестирования и поделимся опытом организации экспертизы в компании. Цель доклада — рассказать о том, с какими проблемами и их решениями мы столкнулись при проведении "атак" на реальном проекте, сравним инструменты и их автоматизацию для проведения этих "атак". Это живой опыт, который мы проходим до сих пор.
Ностальгия по 2017-у году, когда еще все было очно :)

Наша производственная система – это тоже распределенная система, а не набор независимых функций.

PS: А рисую я по-прежнему так себе.
О масштабировании

Будем считать систему масштабируемой, если она способна справляться с возрастающей нагрузкой при добавлении ресурсов. Например, мы добавляем новые узлы в систему, что позволяет ей справится с возрастающей нагрузкой. То же самое с компанией — если при увеличении количества планируемой работы добавляются новые команды и при этом система команд продолжает справляться с возрастающей нагрузкой, то система масштабируема (в реальности это далеко не всегда так).

Производительность и масштабируемость — это связанные, но различные концепции. Производительность — это оптимизация времени ответа. Масштабируемость — это оптимизация возможности держать возрастающую нагрузку.

С точки зрения организационной структуры производительность — это то, насколько быстро мы можем выпускать новую функциональность, а масштабируемость — это возможность реализовать большее число бизнес-инициатив, причем не обязательно с увеличением штата сотрудников.

Улучшение производительности сокращает время ответа, однако поддерживаемая нагрузка может не измениться. При этом улучшение масштабируемости увеличивает возможности держать возрастающую нагрузку. Производительность каждого запроса в отдельности может не измениться.

Что сдерживает машстабирование?

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

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

Микросервисы — это распределенные системы. Распределенные системы разделены в пространстве. Физика накладывает ограничение на скорость передачи информации (скорость света). Когда две системы разделены в пространстве, всегда требуется время для достижения консенсуса. В то время, когда информация передается от источника к потребителю, состояние источника может измениться.

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

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

Существуют и другие виды согласованности — строгая, последовательная, причинно-следственная. Традиционные монолитные системы опираются на строгую согласованность. Строгая согласованность означает, что прежде чем обновленные данные станут доступными, все узлы должны должны подтвердить, что обновили свое состояние. Примеры строгой согласованности в жизни — суд присяжных или жюри, которые должны прийти к общей договоренности (или признать, что это сделать не удалось).

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

Любые две системы, соперничающие за доступ к общему ресурсу находятся в отношении конкуренции. Эта конкуренция может иметь только одного победителя. Остальные вынуждены ждать, пока победитель не закончит работу и не освободит ресурс. По мере роста уровня конкуренции, возрастает время освобождения ресурса (так как увеличивается размер очереди для доступа к ресурсу).

По мере увеличения нагрузки в конечном счете система выйдет за рамки приемлемого времени выполнения.
Продолжение

Здесь стоит сделать отсылку с CAP-теореме, но чтобы не усложнять, приведу пример. У вас была одна команда. Вы добавили вторую. Обе команды разрабатывают разные части системы, но используют одно тестовое окружение. Им нужно договориться (добиться согласованности) о внесении изменений в это окружение. CAP теорема говорит, что достижение одновременно 100%-й согласованности, 100%-й доступности и устойчивости к разделению невозможно. То есть, пока команды не имеют возможности договориться, но им требуется 100%-я согласованность, они теряют свойство доступности, – просто не могут начать тестировать. В распределенных системах, в том числе в структуре команд, необходимо при проектировании закладывать такие принципы и свойства, которые позволят принимать максимальное число решений автономно (в данном случае – собственные тестовые среды), а оставшиеся зависимости должны быть неблокирующими (например, – выпуск частей солюшена разными командами в удобном им ритме, но с испоьзованием версионирования API и Feature Toggle). Это и есть обеспечение устойчивости к разделению с использованием согласованности в конечном счете.

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

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

Обобщая вышесказанное, – говоря о масштабировании микросервисов чаще всего подразумевается возможность технически поддержать возрастающую нагрузку. Но это половина правда. Особенность этого стиля в том, что он явным образом поддерживает и масштабируемость разработки (производственной системы), что для компании иногда даже более важно, а этого добиться без организационных изменений в общем случае невозможно.
Полезное про k8s

Two reasons Kubernetes is so complex
https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/

Working with Kubernetes API
https://iximiuz.com/en/series/working-with-kubernetes-api/

Kubernetes Troubleshooting – The Complete Guide
https://komodor.com/learn/kubernetes-troubleshooting-the-complete-guide/

Automating quality checks for Kubernetes YAMLs
https://dev.to/wkrzywiec/automating-quality-checks-for-kubernetes-yamls-398

When to Use Kubernetes (And When Not to)
https://cult.honeypot.io/reads/when-to-use-kubernetes-and-when-not-to/

Learn How To Create Network Policies for Kubernetes : An online editor and visualisation tool, along with a built-in tutorial, for writing Kubernetes network policies.
https://editor.networkpolicy.io/?id=Dz5waQsJQOTwDm58

Writing your first kubectl plugin with Go
https://bmuschko.com/blog/writing-your-first-kubectl-plugin/
Тут такая идея пришла, сам не пробовал, но может кто-то пробовал или попробует 🙂

Есть хорошая практика - детализация типов работы. Вроде дефект, новая фича, инцидент.

Выглядит так, что если разделить новую функциональность на
- Новая функциональность
- Доработка существующей функциональность

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

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

Такая вот мысль 🙂
Небольшая, хорошая статья:

https://jessitron.com/2021/01/18/when-costs-are-nonlinear-keep-it-small/

Краткая выдержка:

When costs increase nonlinearly with delay or batch size, larger batches are not more efficient.
1. Batch when incremental cost decreases with batch size.
2. Don’t batch when time delay increases the risk.
3. Do not batch for efficiency when costs increase nonlinearly with size.
Микросервисы / распределенные системы
Небольшая, хорошая статья: https://jessitron.com/2021/01/18/when-costs-are-nonlinear-keep-it-small/ Краткая выдержка: When costs increase nonlinearly with delay or batch size, larger batches are not more efficient. 1. Batch when incremental cost decreases…
Вдогонку

Small batches for the win / Continuous Delivery
https://www.eferro.net/2021/01/small-batches-for-win-continuous.html

Small batches -> faster feedback
Small batches -> Customer Value sooner
Small batches -> Reduce direct cost
Small batches -> Reduce deployment risk
Small batches -> Reduce errors
Small batches -> Reduce mean time to recover
Small batches -> Improve psychological safety
Новый стандарт UUID (rfc9562) вступил в силу
https://datatracker.ietf.org/doc/html/rfc9562

Тут кратко об изменениях: https://habr.com/ru/articles/795909/

UPD: еще статья о стандарте (объемнее): https://habr.com/ru/articles/813229/
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Разом всем отвечу – я не имею отношения к Сберовскому Arch.Meetup и то, что стилистика и название совпадает, - ну вот такой организаторы Arch.Meetup выбрали, стилистика ArchDays не менялась ни разу за 6 лет :)
ArchDays

1 ноября пройдет конференция ArchDays. Мы продолжаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

Как и прежде есть желание сделать упор на практическую деятельность: порешать архитектурные кейсы, провести архитектурную Ката, собрать архитектурное видение новых концепций архитектуры.

Подавайте темы для выступлений, приглашайте выступить знакомых.

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Репост привествуется :)
Поделитесь собственным опытом применения AsyncAPI, особенно с какими сложностями столкнулись на старте и при развитии API
https://www.asyncapi.com/