Сообщения

Основы дизайна систем: логирование, мониторинг, предупреждения

Изображение
Логирование Со временем ваша система будет собирать много данных. Большая часть этих данных чрезвычайно полезна. Она может дать вам представление о состоянии вашей системы, ее производительности и проблемах. Это также может дать вам ценную информацию о том, кто использует вашу систему, как они ее используют, как часто, какие части используются более или менее и так далее. Эти данные важны для аналитики, оптимизации производительности и улучшения продукта. Это также чрезвычайно ценно для отладки, не только при входе в консоль во время разработки, но и для поиска ошибок в тестовой и производственной средах. Таким образом, журналы также помогают в отслеживании и аудите. Ключевой прием, который следует помнить при ведении журнала, - это рассматривать его как последовательность последовательных событий, что означает, что данные становятся данными временного ряда, а инструменты и базы данных, которые вы используете, должны быть специально разработаны для помощи в работе с такими данными. ...

Основы дизайна систем: обмен сообщениями и Pub-Sub

Изображение
Когда вы проектируете и строите крупномасштабные и распределенные системы, чтобы эта система работала согласованно и бесперебойно, важно обмениваться информацией между компонентами и службами, составляющими систему. Но системы, которые полагаются на сети, страдают той же слабостью, что и сами сети - они хрупки. Сети выходят из строя, и это не редкость. Когда сети выходят из строя, компоненты в системе не могут обмениваться данными и могут вывести систему из строя (в лучшем случае) или вызвать полный отказ системы (в худшем случае). Таким образом, распределенные системы нуждаются в надежных механизмах для обеспечения продолжения или восстановления связи с того места, где оно было прервано, даже если существует «произвольный раздел» (то есть сбой) между компонентами в системе. Представьте, например, что вы бронируете авиабилеты. Вы получаете хорошую цену, выбираете места, подтверждаете бронирование и даже платите кредитной картой. Теперь вы ждете, пока ваш PDF-файл с билетами не поступи...

Основы дизайна систем: защита выходных точек (Endpoint Protection)

Изображение
Когда вы строите крупномасштабные системы, становится важным защитить вашу систему от слишком большого количества операций, когда такие операции фактически не нужны для использования системы. Это звучит очень абстрактно. Но подумайте об этом - сколько раз вы яростно нажимали кнопку, думая, что это сделает систему более отзывчивой? Представьте, если бы каждое из этих нажатий кнопки отправляло пинг на сервер, и сервер пытался обработать их все! Если пропускная способность системы по какой-то причине низкая (скажем, сервер испытывал необычную нагрузку), то каждый из этих щелчков делал бы систему еще медленнее, потому что ей приходилось обрабатывать их все! Иногда дело даже не в защите системы. Иногда вы хотите ограничить операции, потому что это часть вашей службы. Например, вы могли использовать бесплатные уровни для сторонних служб API, где вам разрешено делать только 20 запросов за 30-минутный интервал. Если вы сделаете 21 или 300 запросов в 30-минутном интервале, после первых 20, это...

Основы дизайна систем: опрос, потоковая передача, сокеты

Изображение
В современную эпоху непрерывных обновлений, push-уведомлений, потокового контента и данных в реальном времени важно понимать основные принципы, лежащие в основе этих технологий. Чтобы данные в вашем приложении обновлялись регулярно или мгновенно, необходимо использовать один из двух следующих подходов. Опрос (Polling) Опрос - это просто проверка вашего клиента на сервере путем отправки ему сетевого запроса и запроса обновленных данных. Эти запросы обычно выполняются через регулярные интервалы, например 5 секунд, 15 секунд, 1 минуту или любой другой интервал, необходимый для вашего варианта использования. Опрос каждые несколько секунд все же не совсем то же самое, что и в реальном времени, и также имеет следующие недостатки, особенно если у вас более миллиона одновременных пользователей: почти постоянные сетевые запросы (не очень удобно для клиента) почти постоянные входящие запросы (не очень хорошо для серверных нагрузок - 1 млн + запросов в секунду!) Таким образом, быстрый опр...

Основы дизайна систем: выборы лидера

Изображение
Вернемся к серверам снова для более сложной темы. Мы уже понимаем принцип доступности и то, как избыточность является одним из способов повышения доступности. Мы также рассмотрели некоторые практические соображения при обработке маршрутизации запросов к кластерам избыточных серверов. Но иногда при такой настройке, когда несколько серверов делают примерно одно и то же, могут возникнуть ситуации, когда вам нужен только один сервер, чтобы взять на себя инициативу. Например, вы хотите убедиться, что только один сервер отвечает за обновление некоторого стороннего API, потому что несколько обновлений с разных серверов могут вызвать проблемы или увеличить расходы стороннего производителя. В этом случае вам нужно выбрать тот первичный сервер, которому вы хотите передать ответственность за это обновление. Этот процесс называется выборами лидера . Когда несколько серверов находятся в кластере для обеспечения избыточности, они могут быть сконфигурированы между собой так, чтобы иметь одного и ...

Основы дизайна систем: базы данных

Изображение
Существуют различные типы решений для хранения данных (баз данных), предназначенные для различных сценариев использования, и некоторые из них более специализированы для определенных задач, чем другие. Однако на очень высоком уровне базы данных можно разделить на два типа: реляционные и нереляционные. Реляционные базы данных Реляционная база данных - это база данных, в которой строго установлены отношения между вещами, хранящимися в базе данных. Эти отношения обычно становятся возможными благодаря требованию, чтобы база данных представляла каждую такую вещь (называемую «сущностью» (entity)) в виде структурированной таблицы - с нулем или несколькими строками («записи», «вхождения») ("records", "entries") и одним или несколькими столбцами («атрибуты», «поля») ("attributes", "fields"). Установив такую структуру в сущности, мы можем гарантировать, что каждый элемент/вхождение/запись имеет правильные данные, которые могут быть связаны с ней. Это...

Основы дизайна систем: последовательное хеширование

Изображение
Одна из немного более сложных концепций для понимания - хеширование в контексте балансировки нагрузки. Чтобы понять это, сначала необходимо понять, как работает хеширование на концептуальном уровне. Оно заключается в том, что хеширование преобразует ввод в значение фиксированного размера, часто целочисленное значение (хеш). Один из ключевых принципов хорошего алгоритма или функции хеширования заключается в том, что функция должна быть детерминированной - идентичные входные данные будут генерировать идентичные выходные данные при передаче в функцию. Итак, детерминированный означает - если я передаю строку «Код» (с учетом регистра), а функция генерирует хеш 11002, то каждый раз, когда я передаю «Код», она должна генерировать «11002» как целое число. И если я передам «код», он будет генерировать другое число (последовательно). Иногда хеш-функция может генерировать один и тот же хеш для нескольких входных данных - это еще не конец света, и есть способы с этим справиться. Фактически это ...