#статья #microservices #practices #en
Эффективные Микросервисы: 10 Лучших Практик.
Effective Microservices: 10 Best Practices.
Отличная статья про принципы построения микросервисной архитектуры.
Правда, немного однобоко, например, в пункте "Microservice First" автор объясняет, что подход "начинать проект с построения монолита и последующее его разделение на микросевисы" потерпит фейл, аргументируя тем, что модули в построенном монолите будут сильно связаны друг с другом.
В моем же понимании, нужно выбирать такой путь, который на старте даст максимальную скорость в доставке фичей до пользователя.
https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2
Эффективные Микросервисы: 10 Лучших Практик.
Effective Microservices: 10 Best Practices.
Отличная статья про принципы построения микросервисной архитектуры.
Правда, немного однобоко, например, в пункте "Microservice First" автор объясняет, что подход "начинать проект с построения монолита и последующее его разделение на микросевисы" потерпит фейл, аргументируя тем, что модули в построенном монолите будут сильно связаны друг с другом.
В моем же понимании, нужно выбирать такой путь, который на старте даст максимальную скорость в доставке фичей до пользователя.
https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2
#статья #найм #ru
Краткая инструкция по найму нормальных людей в ИТ
Рано или поздно вы начинаете нанимать. Важно уметь понимать - какие люди вам нужны прямо сейчас и как правильно их интервьюить. В статье рассматриваются 3 качества, на которые нужно обращать пристальное внимание:
1. Мудрость (умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков)
2. Умение делать дела
3. Совместимость с командой
https://vc.ru/hr/73687-kratkaya-instrukciya-po-naymu-normalnyh-lyudey-v-it
Краткая инструкция по найму нормальных людей в ИТ
Рано или поздно вы начинаете нанимать. Важно уметь понимать - какие люди вам нужны прямо сейчас и как правильно их интервьюить. В статье рассматриваются 3 качества, на которые нужно обращать пристальное внимание:
1. Мудрость (умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков)
2. Умение делать дела
3. Совместимость с командой
https://vc.ru/hr/73687-kratkaya-instrukciya-po-naymu-normalnyh-lyudey-v-it
vc.ru
Краткая инструкция по найму нормальных людей в ИТ — Карьера на vc.ru
Материал автора блога о технологиях «Вастрик.Инсайд».
#статья #фидбек #habr #ru
Как давать и получать обратную связь, если ты воробушек-социофобушек
Почти всегда мы работаем в команде.
То, что нужно всегда и везде делать на регулярной основе, если ваша команда > 1 человека - это давать фидбек. Фидбек - самый мощный инструмент синхронизации культуры в компании. Как коллеге узнать о том, что он что-то делает не так, если ему об этом никто не скажет? Тут важно понимать - вам шашечки или ехать. Если вы хотите результат, вы будете пробовать и пробовать подступиться к человеку с разных сторон, если вас не услышат с первого раза. Если для вас результат не важен, стоит порефлексировать, возможно - вы токсичный.
Самое плохое, с чем тут можно столкнуться - это пассивная агрессия. Когда люди думают, что вы все делаете не так (какую бы роль вы в этой команде не играли), но не говорят об этом прямо. Работать с этим очень сложно.
Не видел лучше статьи про то, как давать фидбек, чем эта https://habr.com/en/company/yamoney/blog/441036/
Как давать и получать обратную связь, если ты воробушек-социофобушек
Почти всегда мы работаем в команде.
То, что нужно всегда и везде делать на регулярной основе, если ваша команда > 1 человека - это давать фидбек. Фидбек - самый мощный инструмент синхронизации культуры в компании. Как коллеге узнать о том, что он что-то делает не так, если ему об этом никто не скажет? Тут важно понимать - вам шашечки или ехать. Если вы хотите результат, вы будете пробовать и пробовать подступиться к человеку с разных сторон, если вас не услышат с первого раза. Если для вас результат не важен, стоит порефлексировать, возможно - вы токсичный.
Самое плохое, с чем тут можно столкнуться - это пассивная агрессия. Когда люди думают, что вы все делаете не так (какую бы роль вы в этой команде не играли), но не говорят об этом прямо. Работать с этим очень сложно.
Не видел лучше статьи про то, как давать фидбек, чем эта https://habr.com/en/company/yamoney/blog/441036/
Хабр
Как давать и получать обратную связь, если ты воробушек-социофобушек
Геннадий — middle-разработчик в большой IT-компании. Он интересуется джавой, кодит с 11 до 20, ездит на работу на самокате, ходит в бар с коллегами по пятницам...
#статья #practices #medium #en
Все, что вам нужно знать о кэшировании
Everything you need to know about Caching — System Design
Когда вы делаете прототип (MVP, эксперимент), важна скорость разработки. Вы реализовываете не самые эффективные алгоритмы, не самую надежную архитектуру.
В какой-то момент вы запускаете свою функциональность и, если с продуктовой точки зрения все хорошо, то у вас появляются пользователи, потом еще пользователи, потом еще.
Вы начинаете упираться в свои быстрорешения, которые вы принимали в самом начале пути. (PS: и это нормально). Но теперь приоритеты немного меняются, вам все также нужно сохранять скорость деливери, но при этом и выдерживать рост нагрузки.
На этом этапе появляется несколько вариантов, из которых нужно будет выбирать (а на самом деле комбинировать):
1) Начать переписывать (переосмысливать) части проекта (но может сильно затормозить деливери)
2) Начать заваливать деньгами - железом (но может оказаться сильно дорого)
3) Попытаться минимальными усилиями выжать из текущих решений максимум (добавит времени, но деливери со временем будет падать)
И, если первые два пункта, вроде бы, понятны, то вот с третьим нужно чуть больше конкретики.
Обычно, самое правильное и менее костыльное решение - это кэширование (PS: один из моих самых любимых вопросов на собеседовании - это реализовать LRU кэш).
С помощью кэширования можно существенно снизить нагрузку на базы данных или сторонние сервисы.
В статье рассматриваются основные методы и подходы для организации кэширования.
https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334
Все, что вам нужно знать о кэшировании
Everything you need to know about Caching — System Design
Когда вы делаете прототип (MVP, эксперимент), важна скорость разработки. Вы реализовываете не самые эффективные алгоритмы, не самую надежную архитектуру.
В какой-то момент вы запускаете свою функциональность и, если с продуктовой точки зрения все хорошо, то у вас появляются пользователи, потом еще пользователи, потом еще.
Вы начинаете упираться в свои быстрорешения, которые вы принимали в самом начале пути. (PS: и это нормально). Но теперь приоритеты немного меняются, вам все также нужно сохранять скорость деливери, но при этом и выдерживать рост нагрузки.
На этом этапе появляется несколько вариантов, из которых нужно будет выбирать (а на самом деле комбинировать):
1) Начать переписывать (переосмысливать) части проекта (но может сильно затормозить деливери)
2) Начать заваливать деньгами - железом (но может оказаться сильно дорого)
3) Попытаться минимальными усилиями выжать из текущих решений максимум (добавит времени, но деливери со временем будет падать)
И, если первые два пункта, вроде бы, понятны, то вот с третьим нужно чуть больше конкретики.
Обычно, самое правильное и менее костыльное решение - это кэширование (PS: один из моих самых любимых вопросов на собеседовании - это реализовать LRU кэш).
С помощью кэширования можно существенно снизить нагрузку на базы данных или сторонние сервисы.
В статье рассматриваются основные методы и подходы для организации кэширования.
https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334
Medium
Everything you need to know about Caching — System Design
Introduction, Use cases, Strategies & Policies to cache data
#статья #habr #taxi #experience #ru
Citymobil — пособие для стартапов по увеличению стабильности на фоне роста
Две статьи про опыт сервиса такси Citymobil и кейсы, с которыми столкнулась команда на стадии активного роста бизнеса.
https://habr.com/en/company/mailru/blog/444818/
В первой статье описывается путь, который прошла команда на этапе бурного роста:
1) Как считать потери от факапов
2) Выстраивание процесса разработки бекенда
3) Почему с налаженным процессом разработки появилась угроза стабильности
4) Цель - учиться на ошибках
https://habr.com/en/company/mailru/blog/445704/
Во второй статье рассматриваются самые распространенные виды аварий:
1) Плохой релиз, 500-ые ошибки
2) Плохой релиз, неоптимальный код, нагрузка на базу
3) Неудачное ручное вмешательство в работу системы
4) Пасхальное яйцо
5) Внешние причины
6) Плохой релиз, сломанная функциональность
Citymobil — пособие для стартапов по увеличению стабильности на фоне роста
Две статьи про опыт сервиса такси Citymobil и кейсы, с которыми столкнулась команда на стадии активного роста бизнеса.
https://habr.com/en/company/mailru/blog/444818/
В первой статье описывается путь, который прошла команда на этапе бурного роста:
1) Как считать потери от факапов
2) Выстраивание процесса разработки бекенда
3) Почему с налаженным процессом разработки появилась угроза стабильности
4) Цель - учиться на ошибках
https://habr.com/en/company/mailru/blog/445704/
Во второй статье рассматриваются самые распространенные виды аварий:
1) Плохой релиз, 500-ые ошибки
2) Плохой релиз, неоптимальный код, нагрузка на базу
3) Неудачное ручное вмешательство в работу системы
4) Пасхальное яйцо
5) Внешние причины
6) Плохой релиз, сломанная функциональность
Хабр
Citymobil — пособие для стартапов по увеличению стабильности на фоне роста. Часть 1
Этой статьей я открываю короткий цикл из двух статей, в которых подробно расскажу, как нам удалось за несколько месяцев в разы увеличить стабильность сервисов...
Anonymous Poll
23%
MongoDB
72%
PostgreSQL
5%
MySQL
Почему архитекторы терпят неудачу - и что с этим делать.
10 болезней, о которых вы должны знать.
Why software architects fail – and what to do about it
10 Diseases You Should Know About.
Выступление с конференции craft, которое озвучивает много проблем, которые я иногда обнаруживаю в себе (а на некоторые начну обращать внимание), но, к сожалению, дает не очень много ответов.
1. Over-Generalization Drive
Symptom: Seeing commonalities in everything and turning them into generic solutions
2. Domain Allergy
Symptom: Treating the domain as a negligible nuisance
3. Obsessive Specialization Disorder
Symptom: Believing every problem to be unique, even if it’s been solved 1,000 times
4. Unhealthy Complexity Attraction
Symptom: Being so smart you can’t be bothered by simple approaches.
5. Analysis Paralysis
Symptom: Taking longer to evaluate than to actually do it
6. Innovation Addiction
Symptom: Things become progressively less fun the closer you get to production
7. Severe Tunneling Fixation
Symptom: Enforcing an architectural apporach that clashes with the framework, libraries or tools you use.
8. Asset Addiction
Symptom: Becoming so attached to a particular tool / library / framework it becomes a fit for every problem.
9. Exaggerated Risk Aversion
Symptom: Sticking with horrible, horrible, HORRIBLE tools because they are there.
10. Impact Dissonance
Symptom: Becoming too detached from the actual system that is being delivered.
Видео
https://www.youtube.com/watch?v=AkYDsiRVqno&feature=youtu.be&t=272
вот тут есть краткая выжимка: https://retrosight.github.io/learning/why-architects-fail-tilkov.html
#видео #youtube #craft #en
10 болезней, о которых вы должны знать.
Why software architects fail – and what to do about it
10 Diseases You Should Know About.
Выступление с конференции craft, которое озвучивает много проблем, которые я иногда обнаруживаю в себе (а на некоторые начну обращать внимание), но, к сожалению, дает не очень много ответов.
1. Over-Generalization Drive
Symptom: Seeing commonalities in everything and turning them into generic solutions
2. Domain Allergy
Symptom: Treating the domain as a negligible nuisance
3. Obsessive Specialization Disorder
Symptom: Believing every problem to be unique, even if it’s been solved 1,000 times
4. Unhealthy Complexity Attraction
Symptom: Being so smart you can’t be bothered by simple approaches.
5. Analysis Paralysis
Symptom: Taking longer to evaluate than to actually do it
6. Innovation Addiction
Symptom: Things become progressively less fun the closer you get to production
7. Severe Tunneling Fixation
Symptom: Enforcing an architectural apporach that clashes with the framework, libraries or tools you use.
8. Asset Addiction
Symptom: Becoming so attached to a particular tool / library / framework it becomes a fit for every problem.
9. Exaggerated Risk Aversion
Symptom: Sticking with horrible, horrible, HORRIBLE tools because they are there.
10. Impact Dissonance
Symptom: Becoming too detached from the actual system that is being delivered.
Видео
https://www.youtube.com/watch?v=AkYDsiRVqno&feature=youtu.be&t=272
вот тут есть краткая выжимка: https://retrosight.github.io/learning/why-architects-fail-tilkov.html
#видео #youtube #craft #en
YouTube
Why software architects fail: and what to do about it - Stefan Tilkov | Craft 2019
We’ve all seen them: Ambitious projects, starting out with grand visions, ending up as costly lessons in what not to do, leaving behind the ruins of promising paradigms, technologies, tools, and careers. But why do architecture approaches sometimes hurt instead…
CQRS (Command and Query Responsibility Segregation) pattern
Сегодня про архитектурный паттерн CQRS, суть которого состоит в том, чтобы отделить операции изменения от операций чтения.
Плюсы:
— Независимое масштабирование читающей и пишущей моделей
— Оптимальные методы и схемы данных для записи и для чтения
— Безопасность (легко обеспечить, чтобы только разрешенные поставщики меняли данные).
— Разделение проблем читателей и писателей (бизнес-логика может остаться в модели изменения данных, при этом модель чтения окажется очень простой)
— Простые запросы.
Пример.
Функциональность "пользователь логинится в приложение, нужно отображать список активных пользователей" требует разные модели изменения состояния и чтения данных.
Следуя паттерну, такую функциональность легко разделить на команды (command): "пользователь активен" и запросы (query): "выбрать список активных пользователей".
Можно использовать event-log для хранения информации о времени активности пользователя и использовать ее как "источник правды".
В то же время, для запросов можно использовать более оптимизированное для чтение хранилище.
Таким образом, сохраняя команду "пользователь активен", мы синхронизируем ее с in-memory хранилищем активных пользователей c TTL, на который мы считаем пользователя активным. Читающие клиенты будут использовать ее для чтения.
По ссылке подробно про то, какие есть плюсы и минусы такого подхода, когда нужно и когда не нужно использовать этот паттерн, а также пример синхронизации моделей записи и чтения.
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
#pattern #microservices #practices #doc #en
Сегодня про архитектурный паттерн CQRS, суть которого состоит в том, чтобы отделить операции изменения от операций чтения.
Плюсы:
— Независимое масштабирование читающей и пишущей моделей
— Оптимальные методы и схемы данных для записи и для чтения
— Безопасность (легко обеспечить, чтобы только разрешенные поставщики меняли данные).
— Разделение проблем читателей и писателей (бизнес-логика может остаться в модели изменения данных, при этом модель чтения окажется очень простой)
— Простые запросы.
Пример.
Функциональность "пользователь логинится в приложение, нужно отображать список активных пользователей" требует разные модели изменения состояния и чтения данных.
Следуя паттерну, такую функциональность легко разделить на команды (command): "пользователь активен" и запросы (query): "выбрать список активных пользователей".
Можно использовать event-log для хранения информации о времени активности пользователя и использовать ее как "источник правды".
В то же время, для запросов можно использовать более оптимизированное для чтение хранилище.
Таким образом, сохраняя команду "пользователь активен", мы синхронизируем ее с in-memory хранилищем активных пользователей c TTL, на который мы считаем пользователя активным. Читающие клиенты будут использовать ее для чтения.
По ссылке подробно про то, какие есть плюсы и минусы такого подхода, когда нужно и когда не нужно использовать этот паттерн, а также пример синхронизации моделей записи и чтения.
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
#pattern #microservices #practices #doc #en
Docs
CQRS Pattern - Azure Architecture Center
Learn how to segregate operations that read data from operations that update data by using the Command Query Responsibility Segregation (CQRS) pattern.
RESTful API Patterns
Часто приходится изобретать одни и те же вещи при проектировании API.
В статье вместе с подробными примерами собраны концепции:
- пагинация
- фильтрация
- асинхронные операции
- версионирование
- агрегация
- локализация
https://levelup.gitconnected.com/restful-api-patterns-81930c43e494
#article #pattern #microservices #practices #en
Часто приходится изобретать одни и те же вещи при проектировании API.
В статье вместе с подробными примерами собраны концепции:
- пагинация
- фильтрация
- асинхронные операции
- версионирование
- агрегация
- локализация
https://levelup.gitconnected.com/restful-api-patterns-81930c43e494
#article #pattern #microservices #practices #en
Medium
RESTful API Patterns
There are so many ways to write an API that is REST architectural style compliant, I’ve grouped some of the solutions here.
Фильтр Блума
https://en.wikipedia.org/wiki/Bloom_filter
Задача - есть база данных, которая хранит пользовательские заказы. В интерфейсе пользователю нужно отображать его заказы.
Допустим, пользователей у нас такое количество, что база перестает справляться с таким потоком запросов. В одной из прошлых записей я описывал механизм кэширования, но давайте представим, что заказов у нас так много, что они перестают эффективно помещаться в этот кэш.
Можно воспользоваться Блум-фильтром.
Создадим в сервисе хэш-таблицу фиксированного размера и заполним ее ключами пользователей, у которых есть активные заказы. Будем для каждого пользователя перед походом в базу данных проверять - есть ли его идентификатор в этой хэш-таблице.
Но ведь будут коллизии, следовательно, ложные срабатывания? - спросите вы и будете правы. Однако, в данной задаче ложные срабатывания не приведут к проблемам.
Когда мы находим совпадение в хэш-таблице - мы все равно идем в базу данных за заказами. Если их там не окажется (по причине коллизии в хэштаблице), мы возвратим пользователю пустой список.
Однако, мы исключим большое количество пользователей, которых в этой таблице точно нет.
Размеры такой хэш-таблицы можно подобрать исходя из ваших требований и ограничений.
https://en.wikipedia.org/wiki/Bloom_filter
#algo #doc #wiki #practices #ru
https://en.wikipedia.org/wiki/Bloom_filter
Задача - есть база данных, которая хранит пользовательские заказы. В интерфейсе пользователю нужно отображать его заказы.
Допустим, пользователей у нас такое количество, что база перестает справляться с таким потоком запросов. В одной из прошлых записей я описывал механизм кэширования, но давайте представим, что заказов у нас так много, что они перестают эффективно помещаться в этот кэш.
Можно воспользоваться Блум-фильтром.
Создадим в сервисе хэш-таблицу фиксированного размера и заполним ее ключами пользователей, у которых есть активные заказы. Будем для каждого пользователя перед походом в базу данных проверять - есть ли его идентификатор в этой хэш-таблице.
Но ведь будут коллизии, следовательно, ложные срабатывания? - спросите вы и будете правы. Однако, в данной задаче ложные срабатывания не приведут к проблемам.
Когда мы находим совпадение в хэш-таблице - мы все равно идем в базу данных за заказами. Если их там не окажется (по причине коллизии в хэштаблице), мы возвратим пользователю пустой список.
Однако, мы исключим большое количество пользователей, которых в этой таблице точно нет.
Размеры такой хэш-таблицы можно подобрать исходя из ваших требований и ограничений.
https://en.wikipedia.org/wiki/Bloom_filter
#algo #doc #wiki #practices #ru
Вы проектируете Netflix с нуля. Нужно сделать сервис, который будет отдавать пользователю рекомендуемые фильмы на главной.
Начальный DAU — 1 000 000, через год — 100 000 000.
Какой запас прочности в rps вы обеспечите на старте для этого сервиса?
Начальный DAU — 1 000 000, через год — 100 000 000.
Какой запас прочности в rps вы обеспечите на старте для этого сервиса?
Anonymous Poll
5%
100 rps
14%
500 rps
25%
1000 rps
12%
2000 rps
10%
5000 rps
21%
10000 rps
1%
15000 rps
4%
20000 rps
3%
30000 rps
5%
50000 rps
Стратегия обработки ошибок Circuit Breaker pattern.
https://medium.com/@kirill.sereda/стратегии-обработки-ошибок-circuit-breaker-pattern-650232944e37
В архитектуре, в которой есть межсервсисное взаимодействие, стоит иметь в виду, что какие-то запросы будут заканчиваться неудачей (проблемы с сетью, сегфолты, баги, итд).
На помощь обычно приходит классическое решение - ретраи, т.е. перезапросы к недоступному ресурсу в надежде с какой-то попытки добиться ответа (есть еще вариант с параллельной отправкой запросов в надежде дождаться ответа хоть одного, но он обычно дороже).
У ретраев есть одна проблема - при недоступности сервиса можно собрать лавину накопившихся запросов, которые сервис не будет в состоянии переварить при поднятии, они будут обрываться клиентом по таймауту и все повторяться по-новой, не давай возможности начать работать.
Одним из способов решения этой проблемы служит имплементация circuit breaker. Паттерн подразумевает "умное" управление перезапросами. Вместо того, чтобы каждый раз делать запрос в недоступный сервис, подсчитывается общая статистика отказов в скользящем окне, из которой можно будет понять - а стоит ли пытаться делать запрос (или перезапрос) в этот сервис, или в этот раз стоит деградировать эту функциональность.
Одна из самых известных имплементаций этого паттерна, которую можно изучить - это реализация компании Netflix Hystrix (btw: которую компания перестала разрабатывать).
https://medium.com/@kirill.sereda/стратегии-обработки-ошибок-circuit-breaker-pattern-650232944e37
#algo #doc #medium #pattern #practices #ru
https://medium.com/@kirill.sereda/стратегии-обработки-ошибок-circuit-breaker-pattern-650232944e37
В архитектуре, в которой есть межсервсисное взаимодействие, стоит иметь в виду, что какие-то запросы будут заканчиваться неудачей (проблемы с сетью, сегфолты, баги, итд).
На помощь обычно приходит классическое решение - ретраи, т.е. перезапросы к недоступному ресурсу в надежде с какой-то попытки добиться ответа (есть еще вариант с параллельной отправкой запросов в надежде дождаться ответа хоть одного, но он обычно дороже).
У ретраев есть одна проблема - при недоступности сервиса можно собрать лавину накопившихся запросов, которые сервис не будет в состоянии переварить при поднятии, они будут обрываться клиентом по таймауту и все повторяться по-новой, не давай возможности начать работать.
Одним из способов решения этой проблемы служит имплементация circuit breaker. Паттерн подразумевает "умное" управление перезапросами. Вместо того, чтобы каждый раз делать запрос в недоступный сервис, подсчитывается общая статистика отказов в скользящем окне, из которой можно будет понять - а стоит ли пытаться делать запрос (или перезапрос) в этот сервис, или в этот раз стоит деградировать эту функциональность.
Одна из самых известных имплементаций этого паттерна, которую можно изучить - это реализация компании Netflix Hystrix (btw: которую компания перестала разрабатывать).
https://medium.com/@kirill.sereda/стратегии-обработки-ошибок-circuit-breaker-pattern-650232944e37
#algo #doc #medium #pattern #practices #ru
Medium
Стратегии обработки ошибок: Circuit Breaker pattern
Сегодня хочу рассмотреть такие понятия, как микросервисы, возможные стратегии обработки и остановиться на паттерне Circuit Breaker.
Микросервисная архитектура хедж-фонда с нуля
Architecting Hedge Fund Microservices From Scratch
https://medium.com/@robertmaidla/designing-hedge-fund-microservices-from-scratch-c370e2fda4c8
#article #medium #microservices #practices #en
Architecting Hedge Fund Microservices From Scratch
https://medium.com/@robertmaidla/designing-hedge-fund-microservices-from-scratch-c370e2fda4c8
#article #medium #microservices #practices #en
Medium
Architecting Hedge Fund Microservices From Scratch
Part 1 — a journey from an idea to production
Materialized View Pattern
Давайте возьмем за пример такую задачу - в мобильном приложении нужно отображать топ-100 пользователей за последние 24 часа по количеству какой-то активности.
Пользователи хранятся в одной базе, активность хранится в другой базе (отсортированные в последовательности их создания).
Решение в лоб - на запрос топ-100 пользователей сделать запрос а базу за всей активностью за 24 часа, построить топ, сходить в базу данных пользователей (чтобы достать ники пользователей), закэшировать этот ответ и отдавать его, в том числе, другим пользователям какое-то время.
Какие есть проблемы:
- запросы в активность мимо кэша могут быть очень тяжелые - пользователи будут ждать
- когда кэш пустой у вас могут быть много одновременно пользователей, попавших мимо кэша и пытающихся одновременно построить топ и нагружать базы
Materialized View pattern подразумевает создание "виртуального" представления данных, которе будет эффективно работать для получение нужной информации:
Можем каждые несколько минут (по какому-нибудь крону) строить топ-100 пользователей за последние 24 часа, будем также получать всю нужную информацию о пользователях и из всего этого создавать новую View, например, в in-memory базе данных. Это и будет наш materialized view. На запросы пользователей на топ-100 мы просто будем быстро отдавать уже подготовленные данные.
https://docs.microsoft.com/ru-ru/azure/architecture/patterns/materialized-view
http://www.jeisystems.co.uk/tech-blog/programming-blog/materialized-view-pattern/
#pattern #practices #doc #ru #en
Давайте возьмем за пример такую задачу - в мобильном приложении нужно отображать топ-100 пользователей за последние 24 часа по количеству какой-то активности.
Пользователи хранятся в одной базе, активность хранится в другой базе (отсортированные в последовательности их создания).
Решение в лоб - на запрос топ-100 пользователей сделать запрос а базу за всей активностью за 24 часа, построить топ, сходить в базу данных пользователей (чтобы достать ники пользователей), закэшировать этот ответ и отдавать его, в том числе, другим пользователям какое-то время.
Какие есть проблемы:
- запросы в активность мимо кэша могут быть очень тяжелые - пользователи будут ждать
- когда кэш пустой у вас могут быть много одновременно пользователей, попавших мимо кэша и пытающихся одновременно построить топ и нагружать базы
Materialized View pattern подразумевает создание "виртуального" представления данных, которе будет эффективно работать для получение нужной информации:
Можем каждые несколько минут (по какому-нибудь крону) строить топ-100 пользователей за последние 24 часа, будем также получать всю нужную информацию о пользователях и из всего этого создавать новую View, например, в in-memory базе данных. Это и будет наш materialized view. На запросы пользователей на топ-100 мы просто будем быстро отдавать уже подготовленные данные.
https://docs.microsoft.com/ru-ru/azure/architecture/patterns/materialized-view
http://www.jeisystems.co.uk/tech-blog/programming-blog/materialized-view-pattern/
#pattern #practices #doc #ru #en
Docs
Шаблон материализованного представления - Azure Architecture Center
Создание предварительно заполненных представлений на основе данных из одного или нескольких хранилищ данных, когда данные не отформатированы для требуемых операций запросов.
Учения
Обычно написание кода подразумевает обработку ошибок. Тут запрос вернул 500, и мы подставили дефолтное значение; там ошибка при попытке записать на диск, и мы показали пользователю сообщение итд.
Код обработки ошибок, как и любой другой код, имеет свойство ломаться и устаревать, если он не работает. Я часто встречаюсь с тем, что код, который должен был спокойно обрабатывать ошибку приводит к каким-нибудь сегфолтам. При каких-то минорных неполадках в системе, которые должны легко парироваться, может прилечь весь бизнес.
Конечно, отличным решением может быть покрытие тестами вроде: если сервис А отвечает Б, то должно происходить В. Но если ресурсов на имплементацию таких вещей нет, то можно обойтись минимумом - учения.
Учения в этом случае - ручные тесткейсы интеграционного тестирования, которые можно провести прям на продакшн сервисе с целью понять, что ваша обработка ошибок работает так, как должна.
Что можно сделать и что проверяем:
— Гасить отдельные сервисы
проверяем: что пользователи этих сервисов умеют работать без них (graceful degradation)
— Гасить часть машин, отдельные ДЦ
проверяем: что сервис продолжает жить при таких вещах, как выход из строя оборудования (например, пожар), что остальные машины справляются с возросшей нагрузкой
— Отключать функциональность
проверяем: что функциональность, которая должна быть отключаемой - остается отключаемой.
#reliability #practices #ru
Обычно написание кода подразумевает обработку ошибок. Тут запрос вернул 500, и мы подставили дефолтное значение; там ошибка при попытке записать на диск, и мы показали пользователю сообщение итд.
Код обработки ошибок, как и любой другой код, имеет свойство ломаться и устаревать, если он не работает. Я часто встречаюсь с тем, что код, который должен был спокойно обрабатывать ошибку приводит к каким-нибудь сегфолтам. При каких-то минорных неполадках в системе, которые должны легко парироваться, может прилечь весь бизнес.
Конечно, отличным решением может быть покрытие тестами вроде: если сервис А отвечает Б, то должно происходить В. Но если ресурсов на имплементацию таких вещей нет, то можно обойтись минимумом - учения.
Учения в этом случае - ручные тесткейсы интеграционного тестирования, которые можно провести прям на продакшн сервисе с целью понять, что ваша обработка ошибок работает так, как должна.
Что можно сделать и что проверяем:
— Гасить отдельные сервисы
проверяем: что пользователи этих сервисов умеют работать без них (graceful degradation)
— Гасить часть машин, отдельные ДЦ
проверяем: что сервис продолжает жить при таких вещах, как выход из строя оборудования (например, пожар), что остальные машины справляются с возросшей нагрузкой
— Отключать функциональность
проверяем: что функциональность, которая должна быть отключаемой - остается отключаемой.
#reliability #practices #ru