Свежий взгляд на HighLoad 🚀
Как правило, никто не называет систему высоконагруженной до тех пор, пока она стабильно работает . #Хайлоад – это ситуация недостатка в ресурсах, возникающая при росте нагрузки. На примере любой системы, испытывающей высокую нагрузку, подразумевается, что она работает на пределе своих возможностей. И вероятность отказа в обслуживании высока.
Основные советы при проектировании высоконагруженных приложений:
1. Микросервисы предпочтительнее монолита.
2. Горизонтальное масштабирование предпочтительнее вертикального.
3. Асинхронное взаимодействие удобно для конвееров обработки, синхронное – для систем с гарантированным уровнем задержки.
4. Разделяйте систему по уровням (tiers) и стремитесь к избыточности (redundancy) в каждом из уровней.
5. На уровнях обработки бизнес-логики стремитесь к stateless-архитектуре. Состояния выносите в отдельное персистентное хранилище.
6. Кешируйте запросы и статику, но помните о консистентности данных.
7. Масштабируйте data tier (базы данных) посредством шардирования и/или репликации.
8. Обеспечивайте поддержку нескольких независимых дата-центров.
9. Используйте инструменты логирования, мониторинга и автоматизации (CI/CD).
Увлекательный лонгрид про HighLoad 🙂
Как правило, никто не называет систему высоконагруженной до тех пор, пока она стабильно работает . #Хайлоад – это ситуация недостатка в ресурсах, возникающая при росте нагрузки. На примере любой системы, испытывающей высокую нагрузку, подразумевается, что она работает на пределе своих возможностей. И вероятность отказа в обслуживании высока.
Основные советы при проектировании высоконагруженных приложений:
1. Микросервисы предпочтительнее монолита.
2. Горизонтальное масштабирование предпочтительнее вертикального.
3. Асинхронное взаимодействие удобно для конвееров обработки, синхронное – для систем с гарантированным уровнем задержки.
4. Разделяйте систему по уровням (tiers) и стремитесь к избыточности (redundancy) в каждом из уровней.
5. На уровнях обработки бизнес-логики стремитесь к stateless-архитектуре. Состояния выносите в отдельное персистентное хранилище.
6. Кешируйте запросы и статику, но помните о консистентности данных.
7. Масштабируйте data tier (базы данных) посредством шардирования и/или репликации.
8. Обеспечивайте поддержку нескольких независимых дата-центров.
9. Используйте инструменты логирования, мониторинга и автоматизации (CI/CD).
Увлекательный лонгрид про HighLoad 🙂
vc.ru
Свежий взгляд на HighLoad — Сервисы на vc.ru
Итак, поехали. О происхождении термина HighLoad, как и о его значении, известно мало. Впервые он появился в российском сегменте Интернета. И остается наиболее популярным в русскоязычном комьюнити. В англоговорящей среде вас не поймут, если вы спросите про…
👍8
Как построить успешную информационную систему: подходы и практики
Существует множество факторов, влияющих на конструкцию информационной системы, включая навыки и опыт вовлеченных в проектирование специалистов, унаследованные системные зависимости, сроки сдачи, степень приемлемости разных видов риска для вашей компании, законодательные ограничения и т. д. Эти факторы зависят от конкретной ситуации.
Мы рассмотрим три определяющих вопроса к построению большинства систем:
1. Надежность. Система должна выполнять заложенный в нее функционал на требуемом уровне производительности. Даже в случае неблагоприятных обстоятельств: аппаратные и программные сбои, ошибки пользователя.
2. Масштабируемость. При росте системы (объемы данных, трафика, сложности вычислений) должны быть предусмотрены разумные способы решения проблем.
3. Удобство сопровождения. Разработчикам и специалистам технической поддержки должна быть обеспечена возможность эффективной работы с системой.
Надежность означает обеспечение правильной работы системы даже в случае сбоев. Они могут происходить в аппаратном обеспечении (обычно случайные и невзаимосвязанные), ПО (ошибки обычно носят системный характер и слабо контролируемы) и привноситься администраторами системы (неминуемо допускающими ошибки время от времени). Методы обеспечения устойчивости к сбоям позволяют скрывать некоторые виды сбоев от конечного пользователя.
Масштабируемость означает наличие стратегий поддержания хорошей производительности даже в случае роста нагрузки. Для обсуждения масштабируемости необходимы прежде всего способы количественного описания нагрузки и производительности. В масштабируемой системе есть возможность добавлять вычислительные мощности в целях сохранения надежной работы системы под высокой нагрузкой.
Удобство сопровождения многолико. Но, по существу, подразумевается облегчение жизни командам разработчиков и операторов, работающим с системой. Помочь снизить сложность и упростить модификацию системы и ее адаптацию к новым сценариям использования могут хорошие абстракции. Удобство эксплуатации означает хороший мониторинг состояния системы и эффективные способы управления им.
Увлекательный лонгрид здесь 🙂
Существует множество факторов, влияющих на конструкцию информационной системы, включая навыки и опыт вовлеченных в проектирование специалистов, унаследованные системные зависимости, сроки сдачи, степень приемлемости разных видов риска для вашей компании, законодательные ограничения и т. д. Эти факторы зависят от конкретной ситуации.
Мы рассмотрим три определяющих вопроса к построению большинства систем:
1. Надежность. Система должна выполнять заложенный в нее функционал на требуемом уровне производительности. Даже в случае неблагоприятных обстоятельств: аппаратные и программные сбои, ошибки пользователя.
2. Масштабируемость. При росте системы (объемы данных, трафика, сложности вычислений) должны быть предусмотрены разумные способы решения проблем.
3. Удобство сопровождения. Разработчикам и специалистам технической поддержки должна быть обеспечена возможность эффективной работы с системой.
Надежность означает обеспечение правильной работы системы даже в случае сбоев. Они могут происходить в аппаратном обеспечении (обычно случайные и невзаимосвязанные), ПО (ошибки обычно носят системный характер и слабо контролируемы) и привноситься администраторами системы (неминуемо допускающими ошибки время от времени). Методы обеспечения устойчивости к сбоям позволяют скрывать некоторые виды сбоев от конечного пользователя.
Масштабируемость означает наличие стратегий поддержания хорошей производительности даже в случае роста нагрузки. Для обсуждения масштабируемости необходимы прежде всего способы количественного описания нагрузки и производительности. В масштабируемой системе есть возможность добавлять вычислительные мощности в целях сохранения надежной работы системы под высокой нагрузкой.
Удобство сопровождения многолико. Но, по существу, подразумевается облегчение жизни командам разработчиков и операторов, работающим с системой. Помочь снизить сложность и упростить модификацию системы и ее адаптацию к новым сценариям использования могут хорошие абстракции. Удобство эксплуатации означает хороший мониторинг состояния системы и эффективные способы управления им.
Увлекательный лонгрид здесь 🙂
vc.ru
Как построить успешную информационную систему: подходы и практики — Сервисы на vc.ru
Приветствую вас, дорогие друзья! Меня зовут Алексей Солонков, я с 2006 года занимаюсь разработкой высоконагруженных систем. Подписывайтесь на мой телеграм-канал Go HypeLoad, чтобы ничего не пропустить. Сегодня мы поговорим об основных подходах к проектированию…
👍5
Future retrospective 😱
Возникало у вас ощущение после выполнения задачи, что можно было сделать лучше? А часть и вовсе пропустить, сделав ход конем? Что-то затормозило или ускорило процесс? Если да - добро пожаловать под кат!
Вам понадобится: тишина, спокойствие, и 20 минут времени. Итак:
1. Устройтесь в кресле или на диване. Можно лечь, расслабиться и закрыть глаза.
2. Представьте задачу и срок выполнения.
3. Набросайте небольшой план реализации, 3-4 пункта.
4. Теперь, что обозначенный срок вышел и задача выполнена. Вы радуетесь, коллеги жмут руку, а начальник выписывает премию :)
5. Далее, вы рассказываете более опытному коллеге о том, как вы делали эту задачу. Вспоминайте максимально подробно. Коллега будет задавать уточняющие вопросы и спрашивать нюансы.
6. Во время рассказа и свершится магия. Начнет всплывать все незапланированное.
Приведу пример.
Задача: реализовать перенос значений JSON в базу данных (БД). Срок – неделя.
1. Садимся, расслабляемся и представляем.
2. Есть задача, есть срок. Это будет отдельный сервис, принимающий JSON.
3. Примерный план: пишем сервис, содержащий веб-сервер с эндпоинтом, авторизацией и валидацией JSON. Ему понадобится библиотека для коннекта к БД.
4. Прошла неделя. Сервис готов и все довольны. Ура!
5. Пятничный вечер. Сидим в баре и рассказываем коллеге:
a. В понедельник начал писать сервис с авторизацией.
b. Во вторник сделал адаптер к БД.
c. В среду начал нагрузочное тестирование. Потребовалось делать кастомный десериализатор (des) JSON для скорости. Плюсом узнал, что кол-во коннектов к БД ограничено. Нужен пул соединений.
d. В четверг оптимизировал код. Делал des и пул соединений.
e. В пятницу поставил задачу на девопсов на деплой. Но, один девопс в отпуске, а у другого завал. В итоге, писал деплой сам. Но успел.
В ходе ретро мы выяснили, что задачу на деплой стоило ставить в понедельник. И сразу реализовывать быстрый des и пул коннектов к БД.
Чтобы данный подход заработал, потренируйтесь на нескольких реальных задачах.
С вами был Иван Дьяченко. Успехов!
Возникало у вас ощущение после выполнения задачи, что можно было сделать лучше? А часть и вовсе пропустить, сделав ход конем? Что-то затормозило или ускорило процесс? Если да - добро пожаловать под кат!
Вам понадобится: тишина, спокойствие, и 20 минут времени. Итак:
1. Устройтесь в кресле или на диване. Можно лечь, расслабиться и закрыть глаза.
2. Представьте задачу и срок выполнения.
3. Набросайте небольшой план реализации, 3-4 пункта.
4. Теперь, что обозначенный срок вышел и задача выполнена. Вы радуетесь, коллеги жмут руку, а начальник выписывает премию :)
5. Далее, вы рассказываете более опытному коллеге о том, как вы делали эту задачу. Вспоминайте максимально подробно. Коллега будет задавать уточняющие вопросы и спрашивать нюансы.
6. Во время рассказа и свершится магия. Начнет всплывать все незапланированное.
Приведу пример.
Задача: реализовать перенос значений JSON в базу данных (БД). Срок – неделя.
1. Садимся, расслабляемся и представляем.
2. Есть задача, есть срок. Это будет отдельный сервис, принимающий JSON.
3. Примерный план: пишем сервис, содержащий веб-сервер с эндпоинтом, авторизацией и валидацией JSON. Ему понадобится библиотека для коннекта к БД.
4. Прошла неделя. Сервис готов и все довольны. Ура!
5. Пятничный вечер. Сидим в баре и рассказываем коллеге:
a. В понедельник начал писать сервис с авторизацией.
b. Во вторник сделал адаптер к БД.
c. В среду начал нагрузочное тестирование. Потребовалось делать кастомный десериализатор (des) JSON для скорости. Плюсом узнал, что кол-во коннектов к БД ограничено. Нужен пул соединений.
d. В четверг оптимизировал код. Делал des и пул соединений.
e. В пятницу поставил задачу на девопсов на деплой. Но, один девопс в отпуске, а у другого завал. В итоге, писал деплой сам. Но успел.
В ходе ретро мы выяснили, что задачу на деплой стоило ставить в понедельник. И сразу реализовывать быстрый des и пул коннектов к БД.
Чтобы данный подход заработал, потренируйтесь на нескольких реальных задачах.
С вами был Иван Дьяченко. Успехов!
👍4😁4👎1🔥1
Свежий взгляд на HighLoad
Видео-версия статьи: https://youtu.be/3CIxRvpBIbk
https://rutube.ru/video/ed808e41cd3b95f2132a4a2df3fab90d/
Текстовая версия статьи: https://vc.ru/services/697479-svezhiy-vzglyad-na-highload
Видео-версия статьи: https://youtu.be/3CIxRvpBIbk
https://rutube.ru/video/ed808e41cd3b95f2132a4a2df3fab90d/
Текстовая версия статьи: https://vc.ru/services/697479-svezhiy-vzglyad-na-highload
YouTube
Свежий взгляд на HighLoad
Нюансы построения высоконагруженных систем. Подписывайтесь на мой телеграм-канал Go HypeLoad, чтобы не пропустить свежий контент!
👍8
Stateful vs. Stateless: выбираем архитектуру осознанно
Stateful и stateless относятся к способу управления состоянием в архитектуре ПО.
Stateful (с сохранением состояния) архитектура подразумевает, что система сохраняет информацию о предыдущих состояниях или взаимодействиях с клиентами. То есть, она сохраняет состояние между запросами или сеансами. Примером stateful архитектуры может быть классическое веб-приложение, которое хранит информацию о сеансе пользователя и состоянии его сессии на сервере.
➕ Преимущества Stateful:
1. Сохранение состояния между запросами, что может быть полезно для сложных приложений с длительными сеансами.
2. Упрощение программной логики, так как состояние может быть сохранено и использовано в разных частях системы.
3. Более простая обработка и восстановление после ошибок или сбоев.
➖ Недостатки Stateful:
1. Требуется сохранение состояния на сервере, что может приводить к высокой нагрузке на ресурсы и ограничивать масштабируемость системы.
2. Изменение состояния может быть сложным и приводить к ошибкам.
3. Ограниченная отказоустойчивость, так как сбой в состоянии может повлиять на работу системы.
Stateless (без сохранения состояния) архитектура не сохраняет информацию о предыдущих состояниях или сеансах. Каждый запрос рассматривается как отдельное, изолированное взаимодействие. RESTful веб-сервисы являются примером stateless архитектуры.
➕ Преимущества Stateless:
1. Лучшая масштабируемость, поскольку каждый запрос обрабатывается независимо и не требуется хранить состояние.
2. Упрощенная разработка и тестирование, так как каждый запрос самодостаточен и не зависит от предыдущих.
3. Более высокая отказоустойчивость, так как отказ в одном компоненте не повлияет на остальные.
➖ Недостатки Stateless:
1. Отсутствие сохранения состояния может усложнить реализацию некоторых функций, особенно при работе с сеансами или сложными взаимодействиями.
2. Дополнительная нагрузка может возникнуть при повторяющихся запросах, так как каждый запрос требует передачи полной информации.
Stateful и stateless относятся к способу управления состоянием в архитектуре ПО.
Stateful (с сохранением состояния) архитектура подразумевает, что система сохраняет информацию о предыдущих состояниях или взаимодействиях с клиентами. То есть, она сохраняет состояние между запросами или сеансами. Примером stateful архитектуры может быть классическое веб-приложение, которое хранит информацию о сеансе пользователя и состоянии его сессии на сервере.
1. Сохранение состояния между запросами, что может быть полезно для сложных приложений с длительными сеансами.
2. Упрощение программной логики, так как состояние может быть сохранено и использовано в разных частях системы.
3. Более простая обработка и восстановление после ошибок или сбоев.
1. Требуется сохранение состояния на сервере, что может приводить к высокой нагрузке на ресурсы и ограничивать масштабируемость системы.
2. Изменение состояния может быть сложным и приводить к ошибкам.
3. Ограниченная отказоустойчивость, так как сбой в состоянии может повлиять на работу системы.
Stateless (без сохранения состояния) архитектура не сохраняет информацию о предыдущих состояниях или сеансах. Каждый запрос рассматривается как отдельное, изолированное взаимодействие. RESTful веб-сервисы являются примером stateless архитектуры.
1. Лучшая масштабируемость, поскольку каждый запрос обрабатывается независимо и не требуется хранить состояние.
2. Упрощенная разработка и тестирование, так как каждый запрос самодостаточен и не зависит от предыдущих.
3. Более высокая отказоустойчивость, так как отказ в одном компоненте не повлияет на остальные.
1. Отсутствие сохранения состояния может усложнить реализацию некоторых функций, особенно при работе с сеансами или сложными взаимодействиями.
2. Дополнительная нагрузка может возникнуть при повторяющихся запросах, так как каждый запрос требует передачи полной информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥1
Инвестиции в ИТ: почему экономия может обернуться убытками
Если вы являетесь крупным или средним бизнесом, то в эпоху цифровой трансформации экономия на специалистах при разработке ИТ-продукта может привести к огромным расходам при его сопровождении по нескольким причинам:
1. Качество кода: Если в процессе разработки не уделяется должного внимания качеству кода и его архитектуре, то в будущем возникнут проблемы, которые потребуют времени и ресурсов для исправления. Код, написанный с плохими практиками, может быть трудным для понимания и модификации другими разработчиками, что затруднит сопровождение продукта.
2. Недостаточное тестирование: Отсутствие должного тестирования и контроля качества в процессе разработки может привести к появлению ошибок и непредвиденному поведению продукта. Решение таких проблем может требовать значительного времени и усилий в процессе сопровождения.
3. Отсутствие масштабируемости: Если при разработке не учитывается потребность в масштабировании продукта в будущем, то при его росте возникнут трудности и необходимость в серьезных изменениях в архитектуре и функционале. Такие изменения могут быть сложными и затратными.
4. Недостаток документации: Недостаточное ведение документации в процессе разработки усложняет понимание кода и логики продукта другими разработчиками. Это затрудняет внесение изменений и требует дополнительного времени для изучения и разбора существующего кода.
В целом, экономия на разработчиках может сократить затраты в краткосрочной перспективе, но в долгосрочной перспективе это может привести к серьезным проблемам и значительным расходам при сопровождении и развитии продукта. Учитывайте потенциальные риски и выбирайте оптимальную стратегию для вашего бизнеса.
Расширенная версия статьи с рекомендациями https://vc.ru/706738
Если вы являетесь крупным или средним бизнесом, то в эпоху цифровой трансформации экономия на специалистах при разработке ИТ-продукта может привести к огромным расходам при его сопровождении по нескольким причинам:
1. Качество кода: Если в процессе разработки не уделяется должного внимания качеству кода и его архитектуре, то в будущем возникнут проблемы, которые потребуют времени и ресурсов для исправления. Код, написанный с плохими практиками, может быть трудным для понимания и модификации другими разработчиками, что затруднит сопровождение продукта.
2. Недостаточное тестирование: Отсутствие должного тестирования и контроля качества в процессе разработки может привести к появлению ошибок и непредвиденному поведению продукта. Решение таких проблем может требовать значительного времени и усилий в процессе сопровождения.
3. Отсутствие масштабируемости: Если при разработке не учитывается потребность в масштабировании продукта в будущем, то при его росте возникнут трудности и необходимость в серьезных изменениях в архитектуре и функционале. Такие изменения могут быть сложными и затратными.
4. Недостаток документации: Недостаточное ведение документации в процессе разработки усложняет понимание кода и логики продукта другими разработчиками. Это затрудняет внесение изменений и требует дополнительного времени для изучения и разбора существующего кода.
В целом, экономия на разработчиках может сократить затраты в краткосрочной перспективе, но в долгосрочной перспективе это может привести к серьезным проблемам и значительным расходам при сопровождении и развитии продукта. Учитывайте потенциальные риски и выбирайте оптимальную стратегию для вашего бизнеса.
Расширенная версия статьи с рекомендациями https://vc.ru/706738
👍9
Эмоциональное выгорание: личный опыт борьбы
Я выделил три направления, связанных с эмоциональным выгоранием. И приемы борьбы с ними.
Внутренний ребенок
Он любит капризничать и требовать жалости к себе.
1. Выясните, что он хочет и попробуйте с ним договориться. Он не мешает вам делать текущие дела, а вы ему даете чуть позже то, о чем он просит.
2. Задайте ему вопрос: хочешь ли ты оставить все как есть, или хочешь хотя бы попытаться изменить ситуацию к лучшему? Если в ответ вы услышите, что он не хочет оставлять все как есть, ответьте ему - вставай и делай!
Это должно сработать.
Сферы влияния
1. Очертите свою сферу влияния.
2. Научитесь управлять приоритетами. Выставляйте приоритеты по значимости для вас лично, последствиям невыполнения, а также кратко- и долгосрочности профита.
Когнитивные искажения
1. Убирайте из фокуса внимания неважное, мысленно уменьшая его образ до смешных размеров.
2. Нерешенные вопросы логически воспроизводите в голове до логического завершения.
3. Не переоценивайте масштаб негативных мыслей других людей о вас.
Развернутую статью читайте здесь
Я выделил три направления, связанных с эмоциональным выгоранием. И приемы борьбы с ними.
Внутренний ребенок
Он любит капризничать и требовать жалости к себе.
1. Выясните, что он хочет и попробуйте с ним договориться. Он не мешает вам делать текущие дела, а вы ему даете чуть позже то, о чем он просит.
2. Задайте ему вопрос: хочешь ли ты оставить все как есть, или хочешь хотя бы попытаться изменить ситуацию к лучшему? Если в ответ вы услышите, что он не хочет оставлять все как есть, ответьте ему - вставай и делай!
Это должно сработать.
Сферы влияния
1. Очертите свою сферу влияния.
2. Научитесь управлять приоритетами. Выставляйте приоритеты по значимости для вас лично, последствиям невыполнения, а также кратко- и долгосрочности профита.
Когнитивные искажения
1. Убирайте из фокуса внимания неважное, мысленно уменьшая его образ до смешных размеров.
2. Нерешенные вопросы логически воспроизводите в голове до логического завершения.
3. Не переоценивайте масштаб негативных мыслей других людей о вас.
Развернутую статью читайте здесь
🔥4👏2