Целостность данных в микросервисах или как не дать неконсистентным данным сломать сервис
В микросервисной ахриктектуре бывают зависимости, которые накладывают определенные ограничения на используемые сервисы.
Для примера, рассмотрим сервис аренды машин, где используется принцип database per service:
- Микросервис geoareas владеет данными о разных географических полигонах - городах, районах:
В какой-то момент нам понадобилось удалить объект из микросервиса geoareas - вызвать endpoint:
Это может повлечь ряд проблем вплоть до недоступности микросервиса, т.к. у нас останутся тарифы, указывающие на удаленную геозону.
Появляется неприятная зависимость: чтобы удалить геозону из geoareas нужно в момент удаления сделать запрос в tariffs, чтобы проверить - не зависит ли от нее какой тариф.
Появляется опасная связанность - при таком подходе geoareas в будущем будет отправлять запросы во все микросервисы, где используются геозоны.
В базах данных, кстати, есть автоматический контроль целостности с помощью внешних ключей.
У нас же распределенная микросервисная архитектура и есть несколько вариантов решения:
1. Webhooks
Вариант подразумевает создание в микросервисе, от которого будут зависеть другие микросервисы унифицированного механизма веб-хуков.
Микросервис будет исполнять эти хуки перед тем, как изменить объект. Если хоть один хуков завершился неудачей, то действие над объектом невозможно.
Примером такого веб-хука может быть запрос в сторонний микросервис с предопределенным API.
Для нашего примера веб-хук в микросервисе geoareas выглядел бы следуюшим образом:
Унифицированность таких хуков позволяет легко конфигурировать их на лету. При появлении нового микросервиса, который использует geoareas добавлять в список хуков новую проверку.
Таким образом, geoareas поддерживает механизм унифицированных веб-хуков, но ничего не знает про то, что за логика внутри этих хуков.
2. Reference Counting
В этом варианте мы будем следить за тем, кто использует геозоны.
Расширяем API нашего микросервиса geoareas следующими endpoints:
При попытке удаления геозоны проверяем список держателей и не даем удалять, если список не пуст.
Если тариф, держащий геозону, удаляется, то после удаления нужно отпустить блокировку, например:
В микросервисной ахриктектуре бывают зависимости, которые накладывают определенные ограничения на используемые сервисы.
Для примера, рассмотрим сервис аренды машин, где используется принцип database per service:
- Микросервис geoareas владеет данными о разных географических полигонах - городах, районах:
{id, geometry}
- Микросервис tariffs в свою очередь распоряжается данными о стоимости аренды: {id, geoarea_id, price_per_minute}. Есть зависимость от сервиса geoareas.В какой-то момент нам понадобилось удалить объект из микросервиса geoareas - вызвать endpoint:
DELETE /geoarea?id={id}.Это может повлечь ряд проблем вплоть до недоступности микросервиса, т.к. у нас останутся тарифы, указывающие на удаленную геозону.
Появляется неприятная зависимость: чтобы удалить геозону из geoareas нужно в момент удаления сделать запрос в tariffs, чтобы проверить - не зависит ли от нее какой тариф.
Появляется опасная связанность - при таком подходе geoareas в будущем будет отправлять запросы во все микросервисы, где используются геозоны.
В базах данных, кстати, есть автоматический контроль целостности с помощью внешних ключей.
У нас же распределенная микросервисная архитектура и есть несколько вариантов решения:
1. Webhooks
Вариант подразумевает создание в микросервисе, от которого будут зависеть другие микросервисы унифицированного механизма веб-хуков.
Микросервис будет исполнять эти хуки перед тем, как изменить объект. Если хоть один хуков завершился неудачей, то действие над объектом невозможно.
Примером такого веб-хука может быть запрос в сторонний микросервис с предопределенным API.
Для нашего примера веб-хук в микросервисе geoareas выглядел бы следуюшим образом:
target="pre-delete" action="POST tariffs/check_delete?geoarea_id={id}"
В микросервисе tariffs, соответственно, нужно реализовать endpoint /check_delete для проверки того, что зону можно удалить и микросервис tariffs "не против".Унифицированность таких хуков позволяет легко конфигурировать их на лету. При появлении нового микросервиса, который использует geoareas добавлять в список хуков новую проверку.
Таким образом, geoareas поддерживает механизм унифицированных веб-хуков, но ничего не знает про то, что за логика внутри этих хуков.
2. Reference Counting
В этом варианте мы будем следить за тем, кто использует геозоны.
Расширяем API нашего микросервиса geoareas следующими endpoints:
/hold?geoarea_id={id}&holder={holder}
POST /release?geoarea_id={id}&holder={holder}
Таким образом, если хотим создать новый тариф в зоне, то перед этим нужно эту зону заблокировать в сервисе geoareas, например:/hold?geoarea_id=moscow&holder=tariffs_tariffmoscow1Рядом с геозонами в микросервисе geoareas будем хранить список тех, кто "держит" эти геозоны.
При попытке удаления геозоны проверяем список держателей и не даем удалять, если список не пуст.
Если тариф, держащий геозону, удаляется, то после удаления нужно отпустить блокировку, например:
/release?geoarea_id=moscow&holder=tariffs_tariffmoscow1
Wikipedia
Ссылочная целостность
Ссы́лочная це́лостность (англ. referential integrity) — корректность значений внешних ключей реляционной базы данных.
Базы данных. Тенденции общемировые и в России.
Если кто-то пропустил - хорошая статья про текущие тренды в мире баз данных.
И если сильным ростом хранилищ с SSD по отношению к HDD никого не увидишь, то совсем другое дело рост рынка облачных решений в 2 раза за 5 лет.
https://habr.com/en/post/533880/
#article #database #habr #ru
Если кто-то пропустил - хорошая статья про текущие тренды в мире баз данных.
И если сильным ростом хранилищ с SSD по отношению к HDD никого не увидишь, то совсем другое дело рост рынка облачных решений в 2 раза за 5 лет.
https://habr.com/en/post/533880/
#article #database #habr #ru
Habr
Базы данных. Тенденции общемировые и в России
Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о трендах, стараясь опираться...
Tarantool vs Redis: что умеют in-memory технологии
Очередная хорошая статья на хабре про бд, а именно in-memory технологии - Redis и Tarantool. Это базы, которые весь объём данных хранят целиком в оперативной памяти. Размер такой базы лимитирован ёмкостью оперативной памяти узла, что может ограничивать нас в количестве данных, но увеличивает скорость на порядок.
В статье подробно рассмотрены архитектурная часть самих бд и их технические особенности, в чем они схожи и в чем различны.
https://habr.com/en/company/mailru/blog/550062/
#article #database #habr #ru #redis #tarantool
Очередная хорошая статья на хабре про бд, а именно in-memory технологии - Redis и Tarantool. Это базы, которые весь объём данных хранят целиком в оперативной памяти. Размер такой базы лимитирован ёмкостью оперативной памяти узла, что может ограничивать нас в количестве данных, но увеличивает скорость на порядок.
В статье подробно рассмотрены архитектурная часть самих бд и их технические особенности, в чем они схожи и в чем различны.
https://habr.com/en/company/mailru/blog/550062/
#article #database #habr #ru #redis #tarantool
Хабр
Tarantool vs Redis: что умеют in-memory технологии
В этой статье я хочу сравнить Redis и Tarantool. У меня нет цели сделать громогласный вывод «Tarantool лучше!» или «Redis круче!». Я хочу понять их сходства и о...
👍1
Алгоритм консенсуса в распределенных системах — Пакcос (Paxos).
Паксос — алгоритм принятия решений в распределённых системах, лежащий в основе многих современных инструментов — Consul, Zookeeper, etcd и других.
Зачастую при работе распределенной системы возникает необходимость принимать общие решения, например, на каком из инстансов запустить задачу, которая должна быть выполнена один раз.
Задача решается просто, когда есть арбитр — главный в принятии решений. Проблема в том, что такой арбитр становится узким местом и при его отказе происходит сбой в работе.
Устойчивая к неполадкам система должна состоять из равноправных участников, способных договариваться между собой — достигать консенсуса.
Алгоритм Паксос (Paxos), придуманный и доказанный Лесли Лампортом, говорит нам о том, как этого консенсуса можно достичь. Критерием достижения является согласие с предложением более половины участников.
Алгоритм состоит из двух этапов:
Подготовительный этап:
1. Предлагающий рассылает анонс, что он планирует сделать предложение n (в момент времени n).
2. Принимающие получившие анонс посылают в ответ обещание не принимать никаких предложений с номерами меньшими n (до момента n), а также последнее принятое предложение (номер и значение) или не отвечают вовсе, если номер последнего принятого принимающим предложения превосходит n.
Предложение:
1. Предлагающий, получив ответы от большинства принимающих, выбирает в качестве значения предложения v значение из ответа с максимальным номером предложения и рассылает предложение (n, v).
2. Принимающий, получив предложение (n, v), обязан принять его если он, конечно, не пообещал другому предлагающему не принимать предложений с номерами меньшими n, где n > n.
Интересные моменты:
— Консенсуса можно вовсе не достигнуть из-за большого количества предлагающих. Для решения этой проблемы можно ввести случайные задержки.
— Повреждение данных на доле узлов может расколоть вашу систему на несколько частей.
Ссылки:
https://habr.com/ru/post/346180/
https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
https://en.wikipedia.org/wiki/Paxos_(computer_science)
Доклад на ближайшем Highload++ “Паксос в картинках” (https://www.highload.ru/spring/2021/abstracts/7677) Консантина Осипова.
#consensus #algorithm #highload #microservices #distributed #habr #ru #en
Паксос — алгоритм принятия решений в распределённых системах, лежащий в основе многих современных инструментов — Consul, Zookeeper, etcd и других.
Зачастую при работе распределенной системы возникает необходимость принимать общие решения, например, на каком из инстансов запустить задачу, которая должна быть выполнена один раз.
Задача решается просто, когда есть арбитр — главный в принятии решений. Проблема в том, что такой арбитр становится узким местом и при его отказе происходит сбой в работе.
Устойчивая к неполадкам система должна состоять из равноправных участников, способных договариваться между собой — достигать консенсуса.
Алгоритм Паксос (Paxos), придуманный и доказанный Лесли Лампортом, говорит нам о том, как этого консенсуса можно достичь. Критерием достижения является согласие с предложением более половины участников.
Алгоритм состоит из двух этапов:
Подготовительный этап:
1. Предлагающий рассылает анонс, что он планирует сделать предложение n (в момент времени n).
2. Принимающие получившие анонс посылают в ответ обещание не принимать никаких предложений с номерами меньшими n (до момента n), а также последнее принятое предложение (номер и значение) или не отвечают вовсе, если номер последнего принятого принимающим предложения превосходит n.
Предложение:
1. Предлагающий, получив ответы от большинства принимающих, выбирает в качестве значения предложения v значение из ответа с максимальным номером предложения и рассылает предложение (n, v).
2. Принимающий, получив предложение (n, v), обязан принять его если он, конечно, не пообещал другому предлагающему не принимать предложений с номерами меньшими n, где n > n.
Интересные моменты:
— Консенсуса можно вовсе не достигнуть из-за большого количества предлагающих. Для решения этой проблемы можно ввести случайные задержки.
— Повреждение данных на доле узлов может расколоть вашу систему на несколько частей.
Ссылки:
https://habr.com/ru/post/346180/
https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
https://en.wikipedia.org/wiki/Paxos_(computer_science)
Доклад на ближайшем Highload++ “Паксос в картинках” (https://www.highload.ru/spring/2021/abstracts/7677) Консантина Осипова.
#consensus #algorithm #highload #microservices #distributed #habr #ru #en
Привет, возвращаюсь немного после режима отпусков, болезней и прививок в режим ведения канала. Уже даже поднакопилось немного материала (плюс даже есть на препродакшене на хабр очень классная статья про V8).
Канал по-прежнему открыт для всех желающих и в него можно приглашать друзей и коллег, если вы этого еще не сделали: https://news.1rj.ru/str/startup_architecture
Канал по-прежнему открыт для всех желающих и в него можно приглашать друзей и коллег, если вы этого еще не сделали: https://news.1rj.ru/str/startup_architecture
Introduction to Fulfillment at Uber
Несколько недель назад Uber выпустила большую статью про переосмысление Fulfillment платформы 2014 года, на которой строятся основные бизнес-сценарии компании. Из-за роста функциональности (аэропорты, еда, доставка…) платформа перестала легко масштабироваться.
Вводные:
— Более миллиона одновременных пользователей и миллиарды поездок в год по более чем десяти тысячам городов.
— Миллиарды транзакций БД в день.
— Сотни микросервисов полагаются на платформу как на источник информации о поездках и водителях.
— События, генерируемые платформой, используются для создания сотен офлайновых датасетов данных для принятия бизнес-решений.
— Более 500 разработчиков расширяют платформу.
Проблемы старой архитектуры:
— Проблемы согласованности — вся архитектура была построена на предпосылке, что можно жертвовать согласованностью в пользу доступности и задержки.
— Multi-Entity Writes — например, сага паттерн, контролирующий логическую транзацию между микросервисами. С ростом бизнеса такие транзакции становились все больше по размеру и сложнее диагностируемыми.
— Проблемы масштабируемости — ringpop страдает от ограничений, из-за которых были проблемы при перемасштабировании распределенных по городам "подов".
Какие основные решения были приняты:
— Использовать Google Cloud Spanner как основную БД.
— Использовать диаграммы состояний (Statecharts) для объектов бизнеса (каждый объект задается как набор состояний, переходов состояний и триггеров.
— Transaction Coordinator — координатор переходов бизнес сущностей между состояниями.
— ORM layer для абстракции над БД.
https://eng.uber.com/fulfillment-platform-rearchitecture/
#uber #microservices #practices #highload #distributed #en
Несколько недель назад Uber выпустила большую статью про переосмысление Fulfillment платформы 2014 года, на которой строятся основные бизнес-сценарии компании. Из-за роста функциональности (аэропорты, еда, доставка…) платформа перестала легко масштабироваться.
Вводные:
— Более миллиона одновременных пользователей и миллиарды поездок в год по более чем десяти тысячам городов.
— Миллиарды транзакций БД в день.
— Сотни микросервисов полагаются на платформу как на источник информации о поездках и водителях.
— События, генерируемые платформой, используются для создания сотен офлайновых датасетов данных для принятия бизнес-решений.
— Более 500 разработчиков расширяют платформу.
Проблемы старой архитектуры:
— Проблемы согласованности — вся архитектура была построена на предпосылке, что можно жертвовать согласованностью в пользу доступности и задержки.
— Multi-Entity Writes — например, сага паттерн, контролирующий логическую транзацию между микросервисами. С ростом бизнеса такие транзакции становились все больше по размеру и сложнее диагностируемыми.
— Проблемы масштабируемости — ringpop страдает от ограничений, из-за которых были проблемы при перемасштабировании распределенных по городам "подов".
Какие основные решения были приняты:
— Использовать Google Cloud Spanner как основную БД.
— Использовать диаграммы состояний (Statecharts) для объектов бизнеса (каждый объект задается как набор состояний, переходов состояний и триггеров.
— Transaction Coordinator — координатор переходов бизнес сущностей между состояниями.
— ORM layer для абстракции над БД.
https://eng.uber.com/fulfillment-platform-rearchitecture/
#uber #microservices #practices #highload #distributed #en
❤1
V8 в бэкенде С++: от одного JS-скрипта до фреймворка онлайн-вычислений.
При разработке новой функциональности мы продвигаем платформенные решения.
Это значит, что вместо того, чтобы писать бизнес код, мы инвестируем в разработку платформ, на базе которых можно строить уже непосредственно бизнес решения за очень короткий срок.
Одной из таких платформ является js-pipeline. Система выносит управление бизнес логикой приложения уровень выше. Вместо того, чтобы описывать бизнес логику разработчиком на каком-нибудь C++, мы выносим большую часть бизнес логики в веб-интерфейс. Теперь новую бизнес логику можно описывать на JavaScript прямо из админки.
Это невероятно снижает time to market. Новая бизнес логика долгого деплоя может быть раскатана на пользователей буквально через несколько минут после самой идеи.
Все это сильно прибавляет скорости разработки и открывает огромные просторы для бизнеса.
Сегодня мой коллега Ислам приоткрывает завесу над технической частью этого большого проекта. Лайки и комментарии строго приветствуются =)
https://habr.com/ru/company/yandex/blog/572880/
#practices #highload #javanoscript #platform #distributed #article #habr #ru
При разработке новой функциональности мы продвигаем платформенные решения.
Это значит, что вместо того, чтобы писать бизнес код, мы инвестируем в разработку платформ, на базе которых можно строить уже непосредственно бизнес решения за очень короткий срок.
Одной из таких платформ является js-pipeline. Система выносит управление бизнес логикой приложения уровень выше. Вместо того, чтобы описывать бизнес логику разработчиком на каком-нибудь C++, мы выносим большую часть бизнес логики в веб-интерфейс. Теперь новую бизнес логику можно описывать на JavaScript прямо из админки.
Это невероятно снижает time to market. Новая бизнес логика долгого деплоя может быть раскатана на пользователей буквально через несколько минут после самой идеи.
Все это сильно прибавляет скорости разработки и открывает огромные просторы для бизнеса.
Сегодня мой коллега Ислам приоткрывает завесу над технической частью этого большого проекта. Лайки и комментарии строго приветствуются =)
https://habr.com/ru/company/yandex/blog/572880/
#practices #highload #javanoscript #platform #distributed #article #habr #ru
Хабр
V8 в бэкенде С++: от одного JS-скрипта до фреймворка онлайн-вычислений
В этой статье я расскажу о долгом путешествии, в котором простая идея выноса в JavaScript часто меняющихся фрагментов алгоритма постепенно выросла в универсальный фреймворк, позволяющий быстро...
Rate limiting с Congestion Control
В микросервисной архитектуре встречаются «лавинообразные» падения. Это, например, когда один сервис не вывозит нагрузку и начинает долго обрабатывать запрос, а его клиенты, вместо того, чтобы перестать нагружать сервис, начинают его ретраить, тем самым создавая еще большую нагрузку.
Проблему можно решать несколькими путями. Со стороны клиентов — реализуя классический Circuit Breaker, о котором не так давно был пост.
Со стороны самого запрашиваемого ресурса - это может быть Rate Limiting, или чуть более умный Rate Limiting, про него сегодня и поговорим.
Rate Limiting, как следует из названия — это ограничение количества обрабатываемых операций (единичных запросов, батчей или даже размеров данных за единицу времени). В микросервисах часто предполагается, что если сервису приходит за какое-то временное окно больше N запросов (далее для простоты RPS), то сервис просто «бесплатно» откидывает остальные запросы.
Основная сложность с тем, чтобы выбрать этот самый ограничивающий N.
* Можно провести нагрузочное тестирование и понять количество RPS, больше которых сервис уже не переваривает.
* Еще можно накинуть какой-то процент к пиковым нагрузкам и выбрать это за N.
* Можно даже просто как-то посчитать.
Усложняется все тем, что быстро меняющееся число, которое зависит от характеристик железа, от количества инстансов, на которые распределяется нагрузка, от бизнесс-логики, работающей в конкретный момент времени. Если у вас несколько микросервисов, поддерживать руками актуальный потолок количества запросов весьма затруднительно.
Один из вариантов, это своего рода эвристический механизм Congestion control.
Механизм отслеживает «загруженность» каждого конкретного инстанса каждого конкретного микросервиса. (это может быть CPU, у нас это загруженность «основного процессора задач» нашего веб-фреймворка). Если инстанс самодиагностирует, что он не справляется с нагрузкой (превышен порог задач в очереди), начинает срабатывать лимит RPS. Лимит уменьшается до тех пор, пока инстанс не начнет чувствовать себя лучше. Если инстанс справляется с нагрузкой, лимит постепенно увеличивается. Если долгое время не было перегруза, лимит RPS снимается.
Стоит также обратить внимание, что механизм плохо подходит, если:
- есть требования точного ограничения RPS. Эвристика сильно зависит от того, сколько и в каком режиме используется CPU в текущем контейнере.
- CPU не является ограничивающим ресурсом.
- Не требуется стабильное время отклика. Например, сервис обрабатывает события батчами, батчи могут приходить неравномерно. При этом пиково CPU может быть перегружен, но в среднем ресурсов хватает на обработку потока событий.
- Нагрузка на CPU в процессе обработки запроса продолжается десятки секунд. Механизм предполагает, что ручки отрабатывают быстро, и изменение лимита RPS очень быстро повлияет на загруженность CPU (секунды или доли секунды). Если endpoint отрабатывает длительное время, то обратная связь будет происходить медленно, и сходимость RPS к максимальному RPS не гарантируется.
#practices #highload #microservices #distributed #ru
В микросервисной архитектуре встречаются «лавинообразные» падения. Это, например, когда один сервис не вывозит нагрузку и начинает долго обрабатывать запрос, а его клиенты, вместо того, чтобы перестать нагружать сервис, начинают его ретраить, тем самым создавая еще большую нагрузку.
Проблему можно решать несколькими путями. Со стороны клиентов — реализуя классический Circuit Breaker, о котором не так давно был пост.
Со стороны самого запрашиваемого ресурса - это может быть Rate Limiting, или чуть более умный Rate Limiting, про него сегодня и поговорим.
Rate Limiting, как следует из названия — это ограничение количества обрабатываемых операций (единичных запросов, батчей или даже размеров данных за единицу времени). В микросервисах часто предполагается, что если сервису приходит за какое-то временное окно больше N запросов (далее для простоты RPS), то сервис просто «бесплатно» откидывает остальные запросы.
Основная сложность с тем, чтобы выбрать этот самый ограничивающий N.
* Можно провести нагрузочное тестирование и понять количество RPS, больше которых сервис уже не переваривает.
* Еще можно накинуть какой-то процент к пиковым нагрузкам и выбрать это за N.
* Можно даже просто как-то посчитать.
Усложняется все тем, что быстро меняющееся число, которое зависит от характеристик железа, от количества инстансов, на которые распределяется нагрузка, от бизнесс-логики, работающей в конкретный момент времени. Если у вас несколько микросервисов, поддерживать руками актуальный потолок количества запросов весьма затруднительно.
Один из вариантов, это своего рода эвристический механизм Congestion control.
Механизм отслеживает «загруженность» каждого конкретного инстанса каждого конкретного микросервиса. (это может быть CPU, у нас это загруженность «основного процессора задач» нашего веб-фреймворка). Если инстанс самодиагностирует, что он не справляется с нагрузкой (превышен порог задач в очереди), начинает срабатывать лимит RPS. Лимит уменьшается до тех пор, пока инстанс не начнет чувствовать себя лучше. Если инстанс справляется с нагрузкой, лимит постепенно увеличивается. Если долгое время не было перегруза, лимит RPS снимается.
Стоит также обратить внимание, что механизм плохо подходит, если:
- есть требования точного ограничения RPS. Эвристика сильно зависит от того, сколько и в каком режиме используется CPU в текущем контейнере.
- CPU не является ограничивающим ресурсом.
- Не требуется стабильное время отклика. Например, сервис обрабатывает события батчами, батчи могут приходить неравномерно. При этом пиково CPU может быть перегружен, но в среднем ресурсов хватает на обработку потока событий.
- Нагрузка на CPU в процессе обработки запроса продолжается десятки секунд. Механизм предполагает, что ручки отрабатывают быстро, и изменение лимита RPS очень быстро повлияет на загруженность CPU (секунды или доли секунды). Если endpoint отрабатывает длительное время, то обратная связь будет происходить медленно, и сходимость RPS к максимальному RPS не гарантируется.
#practices #highload #microservices #distributed #ru
Docs
Rate Limiting pattern - Azure Architecture Center
You can use a rate limiting pattern to help you avoid or minimize throttling errors.
👍1
409 Conflict в API
The request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. https://httpstatuses.com/409
Часто при дизайне API забывают о 409. Если в описании интерфейса пропущен этот код ошибки, то это очень сильный сигнал к тому, что в API есть гонки.
Упрощенный пример с гонкой:
Обновления состояния какого-то объекта
POST update_something?new_value=
Пример почему так делать может быть плохо:
Есть endpoint, который управляет скидками в сервисе: флаг включения скидки и размер самой скидки
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]
2 человека, которые видят в веб-интерфейсе одно и то же начальное значение: {enable=false, value=0}.
Один из них хочет изменить {enable=true}, понимания, что новое значение не поменяет поведения, потому что размер скидки установлен 0.
Вызывает POST update_discount?enable=true
Другой хочет установить value=30 и только через какое-то время включить саму скидку.
Вызывает POST update_discount?value=30
Оба не хотели делать так, чтобы скидка включалась сейчас, однако, последовательность действий привела к обратному.
В хорошем интерфейсе клиент должен понимать, что конкретно он меняет и на что.
Одним из хороших вариантов тут — иметь версию изменяемого объекта. Если версия по каким-то причинам изменилась на бэкенде, то самое время вспомнить про 409 ошибку.
Как может выглядеть интерфейс:
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]&version=[REQUIRED]
Клиент явно передает номер версии объекта, который он меняет. Если версия на бэкенде почему-то отличается от той, что присылает клиент, то нужно вернуть 409, чтобы клиент обновил более актуальную версию. В каких-то веб-интерфейсах пользователи часто видят «Версия документа устарела, обновить».
#practices #api #distributed #microservices
The request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. https://httpstatuses.com/409
Часто при дизайне API забывают о 409. Если в описании интерфейса пропущен этот код ошибки, то это очень сильный сигнал к тому, что в API есть гонки.
Упрощенный пример с гонкой:
Обновления состояния какого-то объекта
POST update_something?new_value=
Пример почему так делать может быть плохо:
Есть endpoint, который управляет скидками в сервисе: флаг включения скидки и размер самой скидки
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]
2 человека, которые видят в веб-интерфейсе одно и то же начальное значение: {enable=false, value=0}.
Один из них хочет изменить {enable=true}, понимания, что новое значение не поменяет поведения, потому что размер скидки установлен 0.
Вызывает POST update_discount?enable=true
Другой хочет установить value=30 и только через какое-то время включить саму скидку.
Вызывает POST update_discount?value=30
Оба не хотели делать так, чтобы скидка включалась сейчас, однако, последовательность действий привела к обратному.
В хорошем интерфейсе клиент должен понимать, что конкретно он меняет и на что.
Одним из хороших вариантов тут — иметь версию изменяемого объекта. Если версия по каким-то причинам изменилась на бэкенде, то самое время вспомнить про 409 ошибку.
Как может выглядеть интерфейс:
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]&version=[REQUIRED]
Клиент явно передает номер версии объекта, который он меняет. Если версия на бэкенде почему-то отличается от той, что присылает клиент, то нужно вернуть 409, чтобы клиент обновил более актуальную версию. В каких-то веб-интерфейсах пользователи часто видят «Версия документа устарела, обновить».
#practices #api #distributed #microservices
WebFX
What Is a 409 Status Code?
Don't know what a 409 status code means? View our HTTP Status Code glossary to review the details of this conflict code!
Привет, у нас тут с вами даже собралось небольшое комьюнити и я хочу спросить. А какие ресурсы вы читаете/смотрите для того, чтобы развиваться в плане архитектуры систем? Разные практики, мнения, новости? Давайте попробуем собрать какие-то ссылки в комментариях к этому сообщению.
#ссылки #practices
#ссылки #practices
Как работает цикл заказа такси в Яндекс Go. История вопроса
Мой коллега Илья написал отличную статью про то, как в Яндекс Go работает цикл заказа такси: как любой заказ проходит все состояния, почему не ломается и как мы к этому пришли от крон-тасок.
tldr: фреймворк для реализации машины состояний и обработки очередей сообщений на распределенной системе.
https://habr.com/en/company/yandex/blog/596681/
#habr #ru #practices #distributed #microservices #highload
Мой коллега Илья написал отличную статью про то, как в Яндекс Go работает цикл заказа такси: как любой заказ проходит все состояния, почему не ломается и как мы к этому пришли от крон-тасок.
tldr: фреймворк для реализации машины состояний и обработки очередей сообщений на распределенной системе.
https://habr.com/en/company/yandex/blog/596681/
#habr #ru #practices #distributed #microservices #highload
Habr
Как работает цикл заказа такси в Яндекс Go. История вопроса
Меня зовут Илья, я отвечаю за инфраструктуру пользовательских продуктов в Яндекс Go. Мы строим цикл заказа такси — процессы, происходящие под капотом после того, как пользователь нажимает «Заказать»....
Спроектировать систему - аналог Apple AirTag.
Пытаемся на регулярной основе проводить командные “брейнштормы”. Берем одну задачу — чаще всего спроектировать какую-то систему и начинаем накидывать идеи ее технической реализации. Такие кейсы круто прокачивают экспертизу в команде. В конце рождается командное решение (или не рождается). Следующая задача — одна из таких задач.
Дано:
1. AirTag - девайс, умный маяк, имеет ID, умеет считать время, что-то простенько хэшировать, броадкастить данные по bluetooth, издавать звук. Не умеет — интернет и геопозиционирование.
2. Основное устройство владельца маяка (например, телефон).
3. Все остальные телефоны мира.
4. Централизованный бэкенд.
Нужно построить решения для такой функциональности:
1. Найти положение своего AirTag через приложение на телефоне.
2. Прислать уведомление владельцу в приложение на телефоне, если за вами следят (например, в сумку подбросили чужой airtag).
Отдельное внимание нужно уделить безопасности. Т.к. предполагается, что бэкенд будет получать данные об AirTag через телефоны других людей, способных принять сигнал. Нужно обеспечить гарантии того, что за вами не смогут следить, не смогут произвести атаку повторного воспроизведение и прочие.
Если есть идеи решения, можно накидывать в комментарии.
#case #task #architecture #device
Пытаемся на регулярной основе проводить командные “брейнштормы”. Берем одну задачу — чаще всего спроектировать какую-то систему и начинаем накидывать идеи ее технической реализации. Такие кейсы круто прокачивают экспертизу в команде. В конце рождается командное решение (или не рождается). Следующая задача — одна из таких задач.
Дано:
1. AirTag - девайс, умный маяк, имеет ID, умеет считать время, что-то простенько хэшировать, броадкастить данные по bluetooth, издавать звук. Не умеет — интернет и геопозиционирование.
2. Основное устройство владельца маяка (например, телефон).
3. Все остальные телефоны мира.
4. Централизованный бэкенд.
Нужно построить решения для такой функциональности:
1. Найти положение своего AirTag через приложение на телефоне.
2. Прислать уведомление владельцу в приложение на телефоне, если за вами следят (например, в сумку подбросили чужой airtag).
Отдельное внимание нужно уделить безопасности. Т.к. предполагается, что бэкенд будет получать данные об AirTag через телефоны других людей, способных принять сигнал. Нужно обеспечить гарантии того, что за вами не смогут следить, не смогут произвести атаку повторного воспроизведение и прочие.
Если есть идеи решения, можно накидывать в комментарии.
#case #task #architecture #device
👍2
Решение. Найти положение своего AirTag через приложение на телефоне.
линк — основная картинка
https://arxiv.org/pdf/2103.02282.pdf — очень рекомендую почитать оригинальную спецификацию
https://habr.com/ru/news/t/554226 — интересное описание на русском
Apple AirTag имеет начальную инициализацию маячка с “основным устройством пользователя”. На ней создается мастер ключ (приватный+публичный, они никогда не передаются через bluetooth).
Маяк броадкастит данные, включая специальный меняющийся со временем Rolling encryption ключ. Так сильно тяжело телефонам вокруг единожды идентифицировать устройство.
Все телефоны вокруг “слушают” пространство и если обнаруживается маяк, читают отправляемую им информацию, добавляют информацию о местоположении, еще раз шифруют (ключом, который содержится в самом сообщении, его может расшифровать владелец маяка, но не может сервер) и отправляют на бэкенд.
Основное устройство пользователя может запрашивать эти данные у бэкенда по открытому ключу. Чуть подробнее и с большим математическим погружением в криптографию можно изучить вопрос в пункте 6.1 спецификации.
Немного интересных фактов из спецификации работы AirTag:
— Apple в теории не знает ничего про местонахождение маячков, нашедший маячок телефон шифрует позицию с помощью публичного ключа с маячка, который потом может расшифровать только владелец устройства с помощью приватного ключа.
— Каждый телефон копит батчи с маячков вокруг и отправляет их на сервер балково с медианой 26 минут.
— Apple хранит зашифрованные репорты о координатах 7 дней.
— Каждый маяк меняет bluetooth адрес каждые 15 минут.
— Apple гипотетически может понять что несколько разных пользователей могут находиться рядом друг с другом по тому о каких девайсах они отправляют репорты в бэкенд Apple. Законодательство каких-то стран позволит деанонимизировать пользователей даже если какие-то из девайсов находятся в “режиме в самолете”.
#case #task #architecture #device
линк — основная картинка
https://arxiv.org/pdf/2103.02282.pdf — очень рекомендую почитать оригинальную спецификацию
https://habr.com/ru/news/t/554226 — интересное описание на русском
Apple AirTag имеет начальную инициализацию маячка с “основным устройством пользователя”. На ней создается мастер ключ (приватный+публичный, они никогда не передаются через bluetooth).
Маяк броадкастит данные, включая специальный меняющийся со временем Rolling encryption ключ. Так сильно тяжело телефонам вокруг единожды идентифицировать устройство.
Все телефоны вокруг “слушают” пространство и если обнаруживается маяк, читают отправляемую им информацию, добавляют информацию о местоположении, еще раз шифруют (ключом, который содержится в самом сообщении, его может расшифровать владелец маяка, но не может сервер) и отправляют на бэкенд.
Основное устройство пользователя может запрашивать эти данные у бэкенда по открытому ключу. Чуть подробнее и с большим математическим погружением в криптографию можно изучить вопрос в пункте 6.1 спецификации.
Немного интересных фактов из спецификации работы AirTag:
— Apple в теории не знает ничего про местонахождение маячков, нашедший маячок телефон шифрует позицию с помощью публичного ключа с маячка, который потом может расшифровать только владелец устройства с помощью приватного ключа.
— Каждый телефон копит батчи с маячков вокруг и отправляет их на сервер балково с медианой 26 минут.
— Apple хранит зашифрованные репорты о координатах 7 дней.
— Каждый маяк меняет bluetooth адрес каждые 15 минут.
— Apple гипотетически может понять что несколько разных пользователей могут находиться рядом друг с другом по тому о каких девайсах они отправляют репорты в бэкенд Apple. Законодательство каких-то стран позволит деанонимизировать пользователей даже если какие-то из девайсов находятся в “режиме в самолете”.
#case #task #architecture #device
👍4
Библиотка VS Сервис VS Сайдкар.
Library vs Service vs Sidecar.
https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad
Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен, где-то в скобках прокомментировал, но аргументы хорошие.
Библиотека — переиспользуемый код распространяется как часть приложения. Код библиотеки работает в том же процессе и контейнере, что и код приложения.
Плюсы:
+ Сетевая задержка: код запускается в одном процессе с приложением, никаких расходов.
+ Доступность: общая доступность высока, т.к. нет сетевого взаимодействия (CAP-теорема)
+ Простота использования: библиотеку просто подключить (спорно: если у вас зоопарк языков, то чтобы подключить библиотеку, например, к C++, можно потратить много времени).
+ Тот же контекст окружения: память, процессор итд доступны для библиотеки как части того же контейнера (спорно: не очень ясно почему это преимущество, т.к. это ресурсы, за которые код библиотеки будет конкурировать с основным приложением)
Минусы:
- Ресурсы: за память, процессор итд библиотека будет конкурировать с приложением, что может вызывать разные проблемы.
- Технологии: может потребоваться несколько реализаций библиотеки (или для нее коннекторов), если у вас используются разные, например, языки программирования.
- Поддерживаемость: любые багфиксы в библиотеке требуют тестирования и перевыкатки всех использующих ее приложений.
Сервис — переиспользуемый код выносится в отдельный сервис/инстанс/контейнер, в который приложение ходит по сети, используя request/response механизм.
Плюсы:
+ Ресурсы: основное приложение и сервис задеплоены по-отдельности так, чтобы процессор, память итд не шарились между ними. Ресурсы могут оптимизироваться и управляться для обоих по-отдельности.
+ Поддерживаемость: сервис может выкатываться отдельно от основного приложения, так что релизы всех используемых приложения не требуются.
+ Технологии: сервис может быть написан с использованием любых необходимых технологий, главное, чтобы сетевой протокол с основным приложением был поддержан.
Минусы:
- Простота использования: сервисы менее просты по сравнению с библиотекой (спорно: для сервиса можно сделать удобный клиент, а библиотеку можно так обновить, что потребуется переписать половину приложения).
- Сетевая задержка: добавляются задержки при сетевых хождениях в сервис.
- Тот же контекст окружения: память, процессор итд основного приложения недоступны сервису, т.к. запущены чаще всего в разных инстансах. (спорно: не очень понятно, почему это минус).
- Доступность: общая доступность ниже по сравнению с библиотекой из-за хождений по сети.
Library vs Service vs Sidecar.
https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad
Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен, где-то в скобках прокомментировал, но аргументы хорошие.
Библиотека — переиспользуемый код распространяется как часть приложения. Код библиотеки работает в том же процессе и контейнере, что и код приложения.
Плюсы:
+ Сетевая задержка: код запускается в одном процессе с приложением, никаких расходов.
+ Доступность: общая доступность высока, т.к. нет сетевого взаимодействия (CAP-теорема)
+ Простота использования: библиотеку просто подключить (спорно: если у вас зоопарк языков, то чтобы подключить библиотеку, например, к C++, можно потратить много времени).
+ Тот же контекст окружения: память, процессор итд доступны для библиотеки как части того же контейнера (спорно: не очень ясно почему это преимущество, т.к. это ресурсы, за которые код библиотеки будет конкурировать с основным приложением)
Минусы:
- Ресурсы: за память, процессор итд библиотека будет конкурировать с приложением, что может вызывать разные проблемы.
- Технологии: может потребоваться несколько реализаций библиотеки (или для нее коннекторов), если у вас используются разные, например, языки программирования.
- Поддерживаемость: любые багфиксы в библиотеке требуют тестирования и перевыкатки всех использующих ее приложений.
Сервис — переиспользуемый код выносится в отдельный сервис/инстанс/контейнер, в который приложение ходит по сети, используя request/response механизм.
Плюсы:
+ Ресурсы: основное приложение и сервис задеплоены по-отдельности так, чтобы процессор, память итд не шарились между ними. Ресурсы могут оптимизироваться и управляться для обоих по-отдельности.
+ Поддерживаемость: сервис может выкатываться отдельно от основного приложения, так что релизы всех используемых приложения не требуются.
+ Технологии: сервис может быть написан с использованием любых необходимых технологий, главное, чтобы сетевой протокол с основным приложением был поддержан.
Минусы:
- Простота использования: сервисы менее просты по сравнению с библиотекой (спорно: для сервиса можно сделать удобный клиент, а библиотеку можно так обновить, что потребуется переписать половину приложения).
- Сетевая задержка: добавляются задержки при сетевых хождениях в сервис.
- Тот же контекст окружения: память, процессор итд основного приложения недоступны сервису, т.к. запущены чаще всего в разных инстансах. (спорно: не очень понятно, почему это минус).
- Доступность: общая доступность ниже по сравнению с библиотекой из-за хождений по сети.
Medium
Library vs Service vs Sidecar
All software applications are composed of re-usable elements. The objective and functionality of these reusable elements vary from infra…
👍8
Архитектура Стартапа - Anton Skogorev Engineering & AI
Библиотка VS Сервис VS Сайдкар. Library vs Service vs Sidecar. https://atul-agrawal.medium.com/library-vs-service-vs-sidecar-ff5a20b50cad Подвернулась интересная статья со сравнением подходов к разработке переиспользуемой функциональности. Не со всем согласен…
...продолжение
Сайдкар — паттерн, при котором переиспользуемый код живет как отдельный процесс в том же контейнере, что и приложение. (например, envoy).
Поддерживаемость: сайдкар может релизиться независимо от основного приложения (спорно: например, не так-то просто организовать, чтобы обновлялась какая-то часть докер-контейнера).
Технологии: сайдкар может быть написан на любой подходящей технологии.
Задержка: меньше, чем у сервиса, но выше, чем у библиотеки. Есть антипаттерн - если много компонентов сделаны на сайдкарах, то можно получить огромную просадку по производительности.
Ресурсы: приложение и сайдкар релизятся совместно, так что ресурсы у них общие. Однако, лимит на использование ресурсов можно может быть установлен по-отдельности на приложение и сайдкар. (спорно: на деле может быть не так просто реализовать, не знаю готовых решений для этого). Если все компоненты реализованы как сайдкары, то можно получить очень сильный оверхед на менеджмент ресурсов.
Простота использования: сайдкар менее прост в использовании в сравнении с библиотекой и может быть сильно проще сервиса, если CI/CD поддерживает это из коробки. (спорно: сильно зависит от ваших технологий. Подключить сайдкар может быть проще, чем библиотеку).
Тот же контекст окружения: память, процессор итд основного приложения доступны для сайдкара. Это позволяет сайдкару делать, например, мониторинг основного приложения.
Доступность: может быть выше в сравнении с сервисом т.к. нет “настоящих” походов по сети. В действительности, доступность будет сильно зависеть от протокола между основным приложением и сайдкаром.
#pattern #microservices #sidecar #medium #en
Сайдкар — паттерн, при котором переиспользуемый код живет как отдельный процесс в том же контейнере, что и приложение. (например, envoy).
Поддерживаемость: сайдкар может релизиться независимо от основного приложения (спорно: например, не так-то просто организовать, чтобы обновлялась какая-то часть докер-контейнера).
Технологии: сайдкар может быть написан на любой подходящей технологии.
Задержка: меньше, чем у сервиса, но выше, чем у библиотеки. Есть антипаттерн - если много компонентов сделаны на сайдкарах, то можно получить огромную просадку по производительности.
Ресурсы: приложение и сайдкар релизятся совместно, так что ресурсы у них общие. Однако, лимит на использование ресурсов можно может быть установлен по-отдельности на приложение и сайдкар. (спорно: на деле может быть не так просто реализовать, не знаю готовых решений для этого). Если все компоненты реализованы как сайдкары, то можно получить очень сильный оверхед на менеджмент ресурсов.
Простота использования: сайдкар менее прост в использовании в сравнении с библиотекой и может быть сильно проще сервиса, если CI/CD поддерживает это из коробки. (спорно: сильно зависит от ваших технологий. Подключить сайдкар может быть проще, чем библиотеку).
Тот же контекст окружения: память, процессор итд основного приложения доступны для сайдкара. Это позволяет сайдкару делать, например, мониторинг основного приложения.
Доступность: может быть выше в сравнении с сервисом т.к. нет “настоящих” походов по сети. В действительности, доступность будет сильно зависеть от протокола между основным приложением и сайдкаром.
#pattern #microservices #sidecar #medium #en
O’Reilly Online Learning
Designing Distributed Systems
Chapter 2. The Sidecar Pattern The first single-node pattern is the sidecar pattern. The sidecar pattern is a single-node pattern made up of two containers. The first is the... - Selection from Designing Distributed Systems [Book]
👍10
Highload++ 2022
На прошлой неделе прошла конференция Highload++. Сразу дисклеймер — все мысли исключительно мои личные и субъективные. Мне довелось побывать, наверное, на 4-5 хайлоадах (и даже выступить), это был единственный раз, я не мог найти по программе, куда можно сходить и что послушать.
Сама конференция несколько раз переносилась по понятным причинам, и это, конечно, тоже повлияло на качество контента. Был интересный случай, когда я пришел на заявленный доклад, вышел спикер, сказал, что не подготовил доклад, но будет другой доклад. Я встал и вышел.
Много рекламы, за которой тяжело рассмотреть контент. Я сужу по рекламе в телеграм-канале, предназначенном для объявлений, которым было невозможно пользоваться из-за постоянного спама, это и доклады, которые направлены больше на порекламировать продукт или компанию, чем на то, чтобы поделиться своим опытом. Я пошел на пафосно звучащий доклад об 1С и их low-code платформе (т.к. мы тоже делаем low-code платформу). Доклад начался с того, что у компании всегда был low-code платформа, а сам термин просто такой хайповый стал последнее время и рассказ до середины (того момента, до которого я смог досидеть, дальше не знаю), был простым обзором продукта 1С. От коллег слышал похожий фидбек и по другим докладам.
Если вы меня спросите — пошел бы я еще, я бы ответил — да. Были и очень хорошие доклады. В сжатых выжимках в следующих постах попробую поделиться тем, что я вынес с конференции.
Если у вас похожее или в корне отличное мнение, поделитесь в комментариях. Вы были на хайлоаде? Какой доклад вам понравился?
На прошлой неделе прошла конференция Highload++. Сразу дисклеймер — все мысли исключительно мои личные и субъективные. Мне довелось побывать, наверное, на 4-5 хайлоадах (и даже выступить), это был единственный раз, я не мог найти по программе, куда можно сходить и что послушать.
Сама конференция несколько раз переносилась по понятным причинам, и это, конечно, тоже повлияло на качество контента. Был интересный случай, когда я пришел на заявленный доклад, вышел спикер, сказал, что не подготовил доклад, но будет другой доклад. Я встал и вышел.
Много рекламы, за которой тяжело рассмотреть контент. Я сужу по рекламе в телеграм-канале, предназначенном для объявлений, которым было невозможно пользоваться из-за постоянного спама, это и доклады, которые направлены больше на порекламировать продукт или компанию, чем на то, чтобы поделиться своим опытом. Я пошел на пафосно звучащий доклад об 1С и их low-code платформе (т.к. мы тоже делаем low-code платформу). Доклад начался с того, что у компании всегда был low-code платформа, а сам термин просто такой хайповый стал последнее время и рассказ до середины (того момента, до которого я смог досидеть, дальше не знаю), был простым обзором продукта 1С. От коллег слышал похожий фидбек и по другим докладам.
Если вы меня спросите — пошел бы я еще, я бы ответил — да. Были и очень хорошие доклады. В сжатых выжимках в следующих постах попробую поделиться тем, что я вынес с конференции.
Если у вас похожее или в корне отличное мнение, поделитесь в комментариях. Вы были на хайлоаде? Какой доклад вам понравился?
👍2😢2
Санкционная модель OSI
Алексей Учакин из EdgeCenter на HighLoad++ 2022 посмотрел на классическую семиуровневую модель OSI (которая описывает архитектуру и принципы работы передачи данных от физического уровня до прикладного программного уровня) с учетом тех реалий, в которых мы все с вами оказались. Ниже мой небольшой конспект.
Сравнивать Россию с Ираном и КНДР по введенным санкциям уже поздно, но можно попробовать построить краткосрочный прогноз того, что стоит ожидать на каждом из уровней и перенять какие-то практики.
Уровень 1. Физический уровень.
Проблемы:
— Отсутсвие железа на складах
— Уход вендоров с рынка, закрытие офисов
— Бан у вендоров из-за санкций
Уровень 2-3. Связанность.
Проблемы:
— Блокировка сервисов и пользователей по геолокации
— DDos-атаки
— Уход провайдеров (магистральных)
Уровень 4-7. Сервисы.
Проблемы:
— Отзыв TLS сертификатов
— Проблемы с продлением или трансфером доменов
— Проблемы с облачными сервисами
Обходные пути:
— Оплата через другие юрисдикции
— Использование российских сервисов и облаков
— Параллельный импорт
Что можно попробовать спрогнозировать:
— Вероятные проблемы с банковским обслуживанием
— Цифровой суверенитет и железный занавес
— Если очень хочется — работать можно
— Использование сервис-провайдеров для обслуживания железа
— Ослабление санкций
— Появление новых логистических коридоров
Еще раз перечитал свой конспект — получилось весьма сухо. За каждым пунктом скрываются много комментариев и трейдофов, поэтому я рекомендую посмотреть полную версию доклада, когда она будет доступна.
https://highload.ru/foundation/2022/abstracts/8968
#highload #osi #sanctions
Алексей Учакин из EdgeCenter на HighLoad++ 2022 посмотрел на классическую семиуровневую модель OSI (которая описывает архитектуру и принципы работы передачи данных от физического уровня до прикладного программного уровня) с учетом тех реалий, в которых мы все с вами оказались. Ниже мой небольшой конспект.
Сравнивать Россию с Ираном и КНДР по введенным санкциям уже поздно, но можно попробовать построить краткосрочный прогноз того, что стоит ожидать на каждом из уровней и перенять какие-то практики.
Уровень 1. Физический уровень.
Проблемы:
— Отсутсвие железа на складах
— Уход вендоров с рынка, закрытие офисов
— Бан у вендоров из-за санкций
Уровень 2-3. Связанность.
Проблемы:
— Блокировка сервисов и пользователей по геолокации
— DDos-атаки
— Уход провайдеров (магистральных)
Уровень 4-7. Сервисы.
Проблемы:
— Отзыв TLS сертификатов
— Проблемы с продлением или трансфером доменов
— Проблемы с облачными сервисами
Обходные пути:
— Оплата через другие юрисдикции
— Использование российских сервисов и облаков
— Параллельный импорт
Что можно попробовать спрогнозировать:
— Вероятные проблемы с банковским обслуживанием
— Цифровой суверенитет и железный занавес
— Если очень хочется — работать можно
— Использование сервис-провайдеров для обслуживания железа
— Ослабление санкций
— Появление новых логистических коридоров
Еще раз перечитал свой конспект — получилось весьма сухо. За каждым пунктом скрываются много комментариев и трейдофов, поэтому я рекомендую посмотреть полную версию доклада, когда она будет доступна.
https://highload.ru/foundation/2022/abstracts/8968
#highload #osi #sanctions
Академия Selectel
Модель OSI. 7 уровней сетевой модели OSI с примерами
В статье рассказываем, как устроена модель OSI (Open Systems Interconnection model) и какова ее роль при построении сетей.
👍7
Симптомы распределенного монолита.
Распределенный монолит возникает, когда структура организации и код разъезжаются, но все еще тесно связаны. Это становится проблемой, если масштаб системы продолжает увеличиваться, а всеми ее частями все еще нужно управлять вместе — это замедляет и увеличивает риск любых изменений.
Симптомы распределенного монолита:
— Когда новая функциональность затрагивает параллельную разработку во многих сервисах
— Когда у сервисов есть общие базы данных или очереди
— Когда количество передаваемых параметров между сервисами быстро растет
- Когда сервисы и компоненты шарят общий бойлерплейтный код
— Когда версионность эндпоинтов сервисов важна
— Когда сервисы циклично зависят друг от друга
Одна из приведенных статей говорит, что есть только два выхода: жить с этим или “перекомпоновать” бизнес-логику, что не стоит себя обманывать и небольшими итеративными изменениями тут не обойтись, вы согласны?
https://medium.com/codex/6-symptoms-of-a-distributed-monolith-78a097320ebb
https://www.techtarget.com/searchapparchitecture/tip/The-distributed-monolith-What-it-is-and-how-to-escape-it
#monolith #distibuted #macroservices #microservices #medium #en
Распределенный монолит возникает, когда структура организации и код разъезжаются, но все еще тесно связаны. Это становится проблемой, если масштаб системы продолжает увеличиваться, а всеми ее частями все еще нужно управлять вместе — это замедляет и увеличивает риск любых изменений.
Симптомы распределенного монолита:
— Когда новая функциональность затрагивает параллельную разработку во многих сервисах
— Когда у сервисов есть общие базы данных или очереди
— Когда количество передаваемых параметров между сервисами быстро растет
- Когда сервисы и компоненты шарят общий бойлерплейтный код
— Когда версионность эндпоинтов сервисов важна
— Когда сервисы циклично зависят друг от друга
Одна из приведенных статей говорит, что есть только два выхода: жить с этим или “перекомпоновать” бизнес-логику, что не стоит себя обманывать и небольшими итеративными изменениями тут не обойтись, вы согласны?
https://medium.com/codex/6-symptoms-of-a-distributed-monolith-78a097320ebb
https://www.techtarget.com/searchapparchitecture/tip/The-distributed-monolith-What-it-is-and-how-to-escape-it
#monolith #distibuted #macroservices #microservices #medium #en
Medium
6 Symptoms of a Distributed Monolith
Distributed monoliths occur when the structure of an organisation and its code is split up whilst still being tightly coupled. This becomes…
👍5
Метрики инцидентоного менеджмета.
MTBF, MTTR, MTTA, and MTTF.
https://www.atlassian.com/incident-management/kpis/common-metrics
Ранее мы немного касались практик инцидентного менджмента, давайте поговорим немного подробнее про метрики, на которые можно и нужно смотреть.
Зачем они нужны? Недостаточно просто считать как часто мы падаем, важно понимать — на что конкретно мы тратим время при починке и как сделать так, чтобы свести это время к минимуму.
Самая, наверное, показательная статья по этому поводу у atlassian, ее и берем за основу.
Каждое падение сервиса и время на его починку — это сгоревшие заказы, потерянные подписки, недовольные клиенты, другими словами — деньги. Поэтому очень важно как быстро вы восстанавливаетесь после выхода из строя. Для этого существует куча достаточно популярных метрик измерения эффективности вашего инцидентного менеджмента:
MTBF (Mean time between failures) — среднее время между факапами. Очевидно, что чем больше значение этой метрики, тем более надежная ваша система.
MTTR (mean time to repair) — среднее время на починку. Считается от начала работ на починку до того момента, когда сервис снова стал доступен. Как считать: берем время, которое сервис был недоступен и делим на количество падений за тот же период.
MTTR (mean time to recovery) — среднее время на восстановление. Считается от момента поломки до полного восстановления сервиса. Как считать: берем время, сколько лежали за определенные период и делим на количество инцидентов за тот же период.
MTTR (Mean time to resolve) — среднее время на решение причины проблемы. Включает не только время от возникновения проблемы до починки, но и время на то, чтобы добиться, что такая проблема больше не воспроизводилась.
MTTR (Mean time to respond) — среднее время реакции на проблему. Тут все просто — это среднее время от момента, как мы получили алерт до момента, когда восстановились.
MTTA (Mean time to acknowledge) — а это время от алерта до начала работ по ее починке, другими словами - как долго мы понимали, что сломалось и как чинить.
MTTF (Mean time to failure) — среднее время между неповторяющимися (из-за одной причины) проблемами.
Что хочется добавить: нормальная практика адаптировать метрики под свои нужды. Если что-то удобнее и показательнее считать иначе - стоит делать так, как удобно для вас. У вас есть метрики о том, как быстро вы восстанавливаетесь после падения?
https://www.atlassian.com/incident-management/kpis/common-metrics
#practices #managment #incidents #metrics
MTBF, MTTR, MTTA, and MTTF.
https://www.atlassian.com/incident-management/kpis/common-metrics
Ранее мы немного касались практик инцидентного менджмента, давайте поговорим немного подробнее про метрики, на которые можно и нужно смотреть.
Зачем они нужны? Недостаточно просто считать как часто мы падаем, важно понимать — на что конкретно мы тратим время при починке и как сделать так, чтобы свести это время к минимуму.
Самая, наверное, показательная статья по этому поводу у atlassian, ее и берем за основу.
Каждое падение сервиса и время на его починку — это сгоревшие заказы, потерянные подписки, недовольные клиенты, другими словами — деньги. Поэтому очень важно как быстро вы восстанавливаетесь после выхода из строя. Для этого существует куча достаточно популярных метрик измерения эффективности вашего инцидентного менеджмента:
MTBF (Mean time between failures) — среднее время между факапами. Очевидно, что чем больше значение этой метрики, тем более надежная ваша система.
MTTR (mean time to repair) — среднее время на починку. Считается от начала работ на починку до того момента, когда сервис снова стал доступен. Как считать: берем время, которое сервис был недоступен и делим на количество падений за тот же период.
MTTR (mean time to recovery) — среднее время на восстановление. Считается от момента поломки до полного восстановления сервиса. Как считать: берем время, сколько лежали за определенные период и делим на количество инцидентов за тот же период.
MTTR (Mean time to resolve) — среднее время на решение причины проблемы. Включает не только время от возникновения проблемы до починки, но и время на то, чтобы добиться, что такая проблема больше не воспроизводилась.
MTTR (Mean time to respond) — среднее время реакции на проблему. Тут все просто — это среднее время от момента, как мы получили алерт до момента, когда восстановились.
MTTA (Mean time to acknowledge) — а это время от алерта до начала работ по ее починке, другими словами - как долго мы понимали, что сломалось и как чинить.
MTTF (Mean time to failure) — среднее время между неповторяющимися (из-за одной причины) проблемами.
Что хочется добавить: нормальная практика адаптировать метрики под свои нужды. Если что-то удобнее и показательнее считать иначе - стоит делать так, как удобно для вас. У вас есть метрики о том, как быстро вы восстанавливаетесь после падения?
https://www.atlassian.com/incident-management/kpis/common-metrics
#practices #managment #incidents #metrics
Atlassian
Common Incident Management Metrics | Atlassian
Explore key incident management metrics to evaluate and improve your team's performance in handling and resolving issues.
👍11
Цифры latency, которые должен знать каждый программист.
Наткнулся в очередной раз на ссылку с цифрами времен задержек ответов от разных ресурсов.
Из интересного:
— 0.5нс — ответ от кэша первого уровня (L1)
— 7нс — ответ от кэша второго уровня (L2)
— 25нс — взять мьютекс
— 100нс — ответ от оперативной памяти
— 500,000нс (0.5мс) — round trip в том же датацентре
— 150,000,000нс (150мс) — отправить пакет CA->Netherlands->CA
Прочитать 1мб:
— 0.4мс — с оперативной памяти
— 1мс — с SSD
— 20мс — с HDD
https://gist.github.com/jboner/2841832
Наткнулся в очередной раз на ссылку с цифрами времен задержек ответов от разных ресурсов.
Из интересного:
— 0.5нс — ответ от кэша первого уровня (L1)
— 7нс — ответ от кэша второго уровня (L2)
— 25нс — взять мьютекс
— 100нс — ответ от оперативной памяти
— 500,000нс (0.5мс) — round trip в том же датацентре
— 150,000,000нс (150мс) — отправить пакет CA->Netherlands->CA
Прочитать 1мб:
— 0.4мс — с оперативной памяти
— 1мс — с SSD
— 20мс — с HDD
https://gist.github.com/jboner/2841832
Gist
Latency Numbers Every Programmer Should Know
Latency Numbers Every Programmer Should Know. GitHub Gist: instantly share code, notes, and snippets.
👍19🔥4
Архитектура распределенных систем или как пройти System Design интервью.
Недавно выступал с лекцией в МГУ "Архитектура распределенных систем на примере задачи о назначении в такси". Была цель объяснить базовые принципы и заодно дать какой-то понятный план того, что интервьюер ждет от кандидата на архитектурной секции. Получилась вполне самодостаточная подсказка.
Недавно выступал с лекцией в МГУ "Архитектура распределенных систем на примере задачи о назначении в такси". Была цель объяснить базовые принципы и заодно дать какой-то понятный план того, что интервьюер ждет от кандидата на архитектурной секции. Получилась вполне самодостаточная подсказка.
👍27