Микросервисы / распределенные системы
Мои заметки по этой главе (фактически краткий конспект, практически без моих вставок, будет только одна, но вообще-то спорных моментов там много) с подготовки к эфиру. Мы перешли от потребности в высокой доступности к потребности в полной доступности с предоставлением…
Измерение и обучение
- Встраивание механизмов измерения
- Регулярный анализ данных
- Проведение ретроспектив
- Выявление возможностей улучшения
- Непрерывное улучшение
Основные метрики доступности: 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).
Обучение должно проходить не только на ошибках, но и на успехе:
- По какой причине в данной ситуации система оказалась устойчивой?
- Люди предвидели проблемы и не позволили им проявится?
- Избежать проблем позволили хорошие автоматизированные механизмы?
- Это была просто удача?
Непрерывные улучшения
- возможны только в атмосфере психологической защищенности
- должны быть основаны на на ретроспективном анализе фактов, а не на фрагментированных воспоминаниях вперемешку с личным мнением.
- Встраивание механизмов измерения
- Регулярный анализ данных
- Проведение ретроспектив
- Выявление возможностей улучшения
- Непрерывное улучшение
Основные метрики доступности: 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).
Обучение должно проходить не только на ошибках, но и на успехе:
- По какой причине в данной ситуации система оказалась устойчивой?
- Люди предвидели проблемы и не позволили им проявится?
- Избежать проблем позволили хорошие автоматизированные механизмы?
- Это была просто удача?
Непрерывные улучшения
- возможны только в атмосфере психологической защищенности
- должны быть основаны на на ретроспективном анализе фактов, а не на фрагментированных воспоминаниях вперемешку с личным мнением.
🔥3👍2
Микросервисы / распределенные системы
Измерение и обучение - Встраивание механизмов измерения - Регулярный анализ данных - Проведение ретроспектив - Выявление возможностей улучшения - Непрерывное улучшение Основные метрики доступности: mean time between failures (MTBF) and mean time to recover…
Механизмы обеспечения 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
Решение проблемы
Обнаружение проблемы
- 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
Решение проблемы
👍3🔥3❤1
Code of Architecture
Заканчиваем книгу Continuous Architecture in Practice 📖 4 декабря в последнем выпуске разберем 7, 8 и 9 главы. Поговорим про надежность как атрибут качества в архитектуре и погрузимся в самые современные технологии. Обсудим: — что вообще такое надежность…
А смотрите, что нашел @izonov 🙂
Я и не знал, что оно есть в записи, почти 8 лет прошло.
https://www.youtube.com/watch?v=y3gSUa1U8E4
Вот в этом выступлении как раз, в конце, перечисляю некоторые из принципов, изложенных позднее в книге Cont. Arch. in Practice, что и удивило, когда книгу читал 🙂
Я и не знал, что оно есть в записи, почти 8 лет прошло.
https://www.youtube.com/watch?v=y3gSUa1U8E4
Вот в этом выступлении как раз, в конце, перечисляю некоторые из принципов, изложенных позднее в книге Cont. Arch. in Practice, что и удивило, когда книгу читал 🙂
YouTube
Как принимать инженерные решения в условиях неопределенности
Пишите ли вы код или интегрируетесь с очередной внешней системой — Вы всегда принимаете инженерные решения.
Ставить кэш между внешней и нашей системами?
Делить класс на два или не делить?
Использовать строгую типизацию в интерфейсе или нет?
…
Ставить кэш между внешней и нашей системами?
Делить класс на два или не делить?
Использовать строгую типизацию в интерфейсе или нет?
…
❤4👍2
Такая вот картинка, например.
Здесь связка проблемы, связанные с DevOps-инициативами в конкретной компании, их связка с конкретными архитектурными решениями (в той же конкретной компании) и влияние этих решений на NFR.
Название компании неизвестно, известно только, что это Social Media Platform.
Здесь связка проблемы, связанные с DevOps-инициативами в конкретной компании, их связка с конкретными архитектурными решениями (в той же конкретной компании) и влияние этих решений на NFR.
Название компании неизвестно, известно только, что это Social Media Platform.
👍5🤔2❤1
Какой вселенский стыд для 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. 🤯😳
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. 🤯😳
🔥6😁5👍1😱1
Forwarded from Kate Dulina
20 декабря в 19:00 мск, online, участие бесплатно.
Спикер: Екатерина Лысенко, RoboMarkets.
Тема: «Вначале было слово – архитектура от словаря».
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
08-adams-chatgpt.pdf
485 KB
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?
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?
👍5😁4
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Тем временем вышел второй, декабрьский, номер журнала IT-архитектор от @ceprojilisty: https://www.ozon.ru/product/zhurnal-it-arhitektor-1345346994/
👍10
У паттерна retry есть свои паттерны, смотрим статью:
https://engineering.mercari.com/en/blog/entry/20210126-retry-pattern-in-microservices/
https://engineering.mercari.com/en/blog/entry/20210126-retry-pattern-in-microservices/
Mercari
Retry pattern in microservices
If at first you don’t succeed, try, try again. Then quit. No use being a damn fool about it— W.C. FieldsHi,
❤5👎3
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Аутентификация для WebSocket до сих пор нет стандарта. Андрей Кузнецов.
Протокол WebSocket появился более 10 лет назад, однако, до сих пор в стандартах отсутствуют рекомендации по выполнению аутентификации для WebScoket-соединений. Обсудим, что же это за зверь такой – WebSocket, почему вообще нужна аутентификация и где здесь можно ошибиться, а также сравним разные варианты ее реализации, включая неочевидные особенности и проблемы.
https://youtu.be/coinSGTsge0
Протокол WebSocket появился более 10 лет назад, однако, до сих пор в стандартах отсутствуют рекомендации по выполнению аутентификации для WebScoket-соединений. Обсудим, что же это за зверь такой – WebSocket, почему вообще нужна аутентификация и где здесь можно ошибиться, а также сравним разные варианты ее реализации, включая неочевидные особенности и проблемы.
https://youtu.be/coinSGTsge0
YouTube
Аутентификация для WebSocket до сих пор нет стандарта. Андрей Кузнецов.
Выступление на ArchDays 2023. Забронируйте участие на следующей конференции: https://archconf.ru/arch
Протокол WebSocket появился более 10 лет назад, однако, до сих пор в стандартах отсутствуют рекомендации по выполнению аутентификации для WebScoket-соединений.…
Протокол WebSocket появился более 10 лет назад, однако, до сих пор в стандартах отсутствуют рекомендации по выполнению аутентификации для WebScoket-соединений.…
👍11👎1
Всех с наступающим новым годом!
🎉16👏13🔥4
Forwarded from Russian Association of Software Architects (Sergey Baranov)
И новое видео с ArchDays
Обсуждение синергии увязки компонентов бизнес- и ИТ-архитектуры.
https://www.youtube.com/watch?v=x8xEXAznrEk
Обсуждение синергии увязки компонентов бизнес- и ИТ-архитектуры.
https://www.youtube.com/watch?v=x8xEXAznrEk
YouTube
Увязка слоев архитектуры в Банке. Ксения Митрофанова.
Выступление на ArchDays 2023. Забронируйте участие на следующей конференции: https://archconf.ru/arch
Обсуждение синергии увязки компонентов бизнес- и ИТ-архитектуры.
Обсуждение синергии увязки компонентов бизнес- и ИТ-архитектуры.
👍4
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Какие очереди/брокеры вы используете у себя в проектах (можно выбрать несколько вариантов)?
Anonymous Poll
67%
Apache Kafka
52%
RabbitMQ
8%
ActiveMQ
0%
IronMQ
2%
ZeroMQ
30%
Redis
1%
TIBCO
10%
Облачные (Amazon / Azure / …)
5%
Другое, напишу в каментах
5%
Не использую
А вот на что наткнулся в свете разговоров и результатов опроса по кафке
https://www.youtube.com/watch?v=DYayslszfz8
https://www.youtube.com/watch?v=DYayslszfz8
YouTube
Distributing Computing – Key Player in Corebanking Platforms - Kafka Summit 2018
https://www.confluent.io/kafka-summit-london18/distributing-computing-key-player-in-corebanking-platforms
Mikhail Khasin, Sberbank
View Description View Video and Slides
A dramatic increase in usage of financial services through internet and digital channels…
Mikhail Khasin, Sberbank
View Description View Video and Slides
A dramatic increase in usage of financial services through internet and digital channels…
Так как на ИТ-пикнике не было записи, сегодня повторю это выступление, приходите. Так как это митап, то у нас не будет ограничения по времени :)
--------
4️⃣ ArchDays MeetUp - врываемся в 2024!
10 января в 19:00 мск состоится онлайн митап «Восстановление архитектурных знаний».
Разберем примеры того, как быстро восстанавливать знания об архитектуре, и почему это важно.
Ставьте уведомления и не пропускайте эфир – будет интересно!
--------
10 января в 19:00 мск состоится онлайн митап «Восстановление архитектурных знаний».
Разберем примеры того, как быстро восстанавливать знания об архитектуре, и почему это важно.
Ставьте уведомления и не пропускайте эфир – будет интересно!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥3
Микросервисы / распределенные системы
Так как на ИТ-пикнике не было записи, сегодня повторю это выступление, приходите. Так как это митап, то у нас не будет ограничения по времени :) -------- 4️⃣ ArchDays MeetUp - врываемся в 2024! 10 января в 19:00 мск состоится онлайн митап «Восстановление…
Быстрое_восстановление_архитектурных_знаний.pdf
21.7 MB
Презентация с выступления
👍10
Нас тут много, давайте замерим температуру :) Вы перешли с монолита на микросервисы и с ними субъективно, по ощущениям, стало
Anonymous Poll
29%
Лучше, чем было
14%
Хуже, чем было
11%
Ничего не поменялось
46%
Посмотреть результат
DevCon_2016_Влияение_DevOps_на_архитектуру.pdf
3.3 MB
Презентация с моего самого первого публичного выступления с упоминанием микросервисов.
Это было 8 лет назад. Их почти ни у кого не было. О них почти никто не слышал. И это было единственное выступление на той конфе, в котором упоминалось слово «микросервис». Можете себе такое представить сейчас? :)
UPD: пропустил, был еще один от Евгения Агафонова из ABBYY
Это было 8 лет назад. Их почти ни у кого не было. О них почти никто не слышал. И это было единственное выступление на той конфе, в котором упоминалось слово «микросервис». Можете себе такое представить сейчас? :)
UPD: пропустил, был еще один от Евгения Агафонова из ABBYY
👍11
chaos-engineering.pdf
1.6 MB
В прошлом году принимал участие в круглом столе на конфе от Сбера, речь шла об антихрупкости.
Вроде как должна быть запись, здесь поделюсь своими заметками о дорожной карте достижения антихрупкости.
Мне показалось, что это может быть интересно, потому что этого не было в обсуждении на круглом столе и здесь есть не очевидные мысли.
Антихрупкость – это свойство, при котором система становится лучше под воздействием стрессора. С возрастанием интесивности воздействия стрессора (до определенного предела) возрастает выгода (сокращается вред).
Стратегия достижения антихрупкости
1. Минимизировать возможные потери при отказах
2. Избежать катастрофических сценариев, правильно хеджируя риски. Риски, согласно этой модели, бывают только высокими и близкими к нулю. Эта мысль мне показалась не очевидной, но интересной. Как только наиболее серьезные угрозы устранены, менее серьезные могут видоизмениться за счет обучения на основе окружающей среды. Если ядро системы относительно безопасно, неосновные части системы могут извлечь выгоду из внешних стимулов для повышения антихрупкости.
3. Внедрить адаптивную отказоустойчивость. Автоматическое исправление ошибок (т. е. метод автоматического восстановления программного обеспечения) должно быть частью архитектуры. Я бы несколько удивлен, что существуют работы 90-х годов и более ранних о том, каким образом под изменяющийся контекст динамически меняется даже не исходный код или структура решения, а исполняемый код. Примерно об этом Digital Immunity
Микросервисный архитектурный стиль позволяет проявится антихрупкости. Однако микросервисы сами по себе не являются решением, а лишь enabler'ом. Они не «учатся» на ошибках, они просто устойчивы, а возможности обучения повышают, например техники fault injection (тот же chaos eng).
В аттаче пара важных статей и небольшая книжка по теме.
Вроде как должна быть запись, здесь поделюсь своими заметками о дорожной карте достижения антихрупкости.
Мне показалось, что это может быть интересно, потому что этого не было в обсуждении на круглом столе и здесь есть не очевидные мысли.
Антихрупкость – это свойство, при котором система становится лучше под воздействием стрессора. С возрастанием интесивности воздействия стрессора (до определенного предела) возрастает выгода (сокращается вред).
Стратегия достижения антихрупкости
1. Минимизировать возможные потери при отказах
2. Избежать катастрофических сценариев, правильно хеджируя риски. Риски, согласно этой модели, бывают только высокими и близкими к нулю. Эта мысль мне показалась не очевидной, но интересной. Как только наиболее серьезные угрозы устранены, менее серьезные могут видоизмениться за счет обучения на основе окружающей среды. Если ядро системы относительно безопасно, неосновные части системы могут извлечь выгоду из внешних стимулов для повышения антихрупкости.
3. Внедрить адаптивную отказоустойчивость. Автоматическое исправление ошибок (т. е. метод автоматического восстановления программного обеспечения) должно быть частью архитектуры. Я бы несколько удивлен, что существуют работы 90-х годов и более ранних о том, каким образом под изменяющийся контекст динамически меняется даже не исходный код или структура решения, а исполняемый код. Примерно об этом Digital Immunity
Микросервисный архитектурный стиль позволяет проявится антихрупкости. Однако микросервисы сами по себе не являются решением, а лишь enabler'ом. Они не «учатся» на ошибках, они просто устойчивы, а возможности обучения повышают, например техники fault injection (тот же chaos eng).
В аттаче пара важных статей и небольшая книжка по теме.
❤9👍4👏3👎1🤔1