16 концепций дизайна систем, которые нужно изучить до собеседования

Чтобы преуспеть в проектировании систем, одним из наиболее важных аспектов является развитие глубокого понимания фундаментальных концепций проектирования систем, таких как балансировка нагрузки (load balancing), кэширование (caching), секционирование (partitioning), репликация (replication), базы данных (database) и прокси-серверы (proxy). 16 ключевых понятий, описанные в этой статье, могут существенно повлиять на вашу способность решать проблемы проектирования систем. Эти концепции варьируются от понимания тонкостей шлюза API и освоения методов балансировки нагрузки до понимания важности CDN и оценки роли кэширования в современных распределенных системах. К концу этой статьи у вас будет полное представление об этих основных идеях и уверенность в том, что вы сможете применить их на следующем собеседовании. Собеседования по проектированию систем по своей природе не структурированы. Во время собеседования сложно уследить за вещами и быть уверенным, что вы затронули все существенные аспекты дизайна. В этой статье мы обсудим 16 основных концепций проектирования систем. Вот их краткое описание:

1. Система доменных имен (DNS)
2. Балансировщик нагрузки
3. Шлюз API (API Gateway)
4. CDN
5. Прямой прокси против обратного прокси
6. Кэширование
7. Секционирование данных
8. Репликация базы данных
9. Распределенные системы обмена сообщениями
10. Микросервисы
11. Базы данных NoSQL
12. Индекс базы данных
13. Распределенные файловые системы
14. Система уведомлений
15. Полнотекстовый поиск
16. Распределенные сервисы координации

1. Система доменных имен (DNS)

Система доменных имен (DNS) является фундаментальным компонентом интернет-инфраструктуры, который преобразует удобные для человека доменные имена в соответствующие IP-адреса. Он функционирует как телефонная книга для Интернета, позволяя пользователям получать доступ к веб-сайтам и службам, вводя легко запоминающиеся доменные имена, такие как www.example.com, а не числовые IP-адреса, такие как 192.0.2.1, которые компьютеры используют для идентификации друг друга. Когда вы вводите доменное имя в свой веб-браузер, DNS отвечает за поиск соответствующего IP-адреса и направление вашего запроса на правильный сервер. Процесс начинается с того, что ваш компьютер отправляет запрос рекурсивному преобразователю, который затем выполняет поиск на ряде DNS-серверов, начиная с корневого сервера, затем на сервере домена верхнего уровня (TLD) и, наконец, на авторитетном сервере имен. Как только IP-адрес найден, рекурсивный преобразователь возвращает его на ваш компьютер, позволяя вашему браузеру установить соединение с целевым сервером и получить доступ к нужному контенту.

2. Балансировщик нагрузки

Подсистема балансировки нагрузки — это сетевое устройство или программное обеспечение, которое распределяет входящий сетевой трафик между несколькими серверами для обеспечения оптимального использования ресурсов, уменьшения задержки и поддержания высокой доступности. Он играет жизненно важную роль в масштабировании приложений и эффективном управлении рабочими нагрузками серверов, особенно в ситуациях, когда происходит внезапный всплеск трафика или неравномерное распределение запросов между серверами. Подсистемы балансировки нагрузки используют различные алгоритмы для определения того, как распределять входящий трафик. К распространенным алгоритмам относятся:

• Round Robin: Запросы распределяются последовательно и равномерно по всем доступным серверам циклически.
• Наименьшее количество подключений: Подсистема балансировки нагрузки назначает запросы серверу с наименьшим количеством активных подключений, отдавая приоритет менее загруженным серверам.
• Хеш IP-адреса: IP-адрес клиента хешируется, и полученное значение используется для определения того, на какой сервер должен быть направлен запрос. Этот метод гарантирует, что запросы конкретного клиента всегда направляются на один и тот же сервер, помогая поддерживать постоянство сеанса.

3. Шлюз API (API Gateway)

Шлюз API — это сервер или служба, которая выступает в качестве посредника между внешними клиентами и внутренними микросервисами или серверными службами приложения на основе API. Это важнейший компонент в современных архитектурах, особенно в системах на основе микросервисов, где он упрощает процесс связи и обеспечивает единую точку входа для клиентов для доступа к различным службам. Основные функции API-шлюза включают в себя:

• Маршрутизация запроса: Он направляет входящие запросы API от клиентов в соответствующий бэкэнд или микросервис на основе предопределенных правил и конфигураций.
• Аутентификация и авторизация: Шлюз API может обрабатывать аутентификацию и авторизацию пользователей, гарантируя, что только авторизованные клиенты могут получить доступ к сервисам. Он может проверять ключи API, токены или другие учетные данные перед маршрутизацией запросов к серверным службам.
• Ограничение скорости и throttling: Чтобы защитить серверные службы от чрезмерной нагрузки или злоупотреблений, шлюз API может применять ограничения скорости или регулировать запросы от клиентов на основе предопределенных политик.
• Кэширование: чтобы уменьшить задержку и нагрузку на серверную часть, шлюз API может кэшировать часто используемые ответы, предоставляя их непосредственно клиентам без необходимости запрашивать бэкэнд сервисы.
• Преобразование запросов и ответов: Шлюз API может изменять запросы и ответы, такие как преобразование форматов данных, добавление или удаление заголовков или изменение параметров запроса, чтобы обеспечить совместимость между клиентами и службами.

4. CDN

Сеть доставки контента (CDN) — это распределенная сеть серверов, которые хранят и доставляют контент, такой как изображения, видео, CSS и скрипты, пользователям из географически более близких мест. CDN предназначены для повышения производительности, скорости и надежности доставки контента конечным пользователям, независимо от их местоположения относительно исходного сервера. Вот как работает CDN:

1. Когда пользователь запрашивает контент с веб-сайта или приложения, запрос направляется на ближайший сервер CDN, также известный как пограничный сервер (edge server).
2. Если на пограничном сервере запрошенное содержимое закэшировано, он напрямую передает его пользователю. Это уменьшает задержку и улучшает взаимодействие с пользователем, поскольку контент перемещается на меньшее расстояние.
3. Если контент не кэшируется на пограничном сервере, CDN извлекает его с исходного сервера или другого ближайшего сервера CDN. После получения содержимого оно кэшируется на пограничном сервере и передается пользователю.
4. Чтобы убедиться, что контент остается актуальным, CDN периодически проверяет исходный сервер на наличие изменений и соответствующим образом обновляет свой кэш.

5. Прямой прокси против обратного прокси

Прямой прокси (forward proxy), также известный как «прокси-сервер» или просто «прокси», представляет собой сервер, который находится перед одной или несколькими клиентскими машинами и выступает в качестве посредника между клиентами и Интернетом. Когда клиентский компьютер делает запрос к ресурсу в Интернете, запрос сначала отправляется на прокси-сервер. Затем прокси-сервер пересылки пересылает запрос в Интернет от имени клиентского компьютера и возвращает ответ клиентскому компьютеру. Обратный прокси (reverse proxy) — это сервер, который находится перед одним или несколькими веб-серверами и выступает в качестве посредника между веб-серверами и Интернетом. Когда клиент делает запрос к ресурсу в Интернете, запрос сначала отправляется на обратный прокси-сервер. Затем обратный прокси-сервер перенаправляет запрос на один из веб-серверов, который возвращает ответ обратному прокси-серверу. Затем обратный прокси-сервер возвращает ответ клиенту.

6. Кэширование

Кэш — это высокоскоростной уровень хранения, который находится между приложением и исходным источником данных, таким как база данных, файловая система или удаленная веб-служба. Когда данные запрашиваются приложением, они сначала проверяются в кэше. Если данные найдены в кэше, они возвращаются в приложение. Если данные не найдены в кэше, они извлекаются из исходного источника, сохраняются в кэше для использования в будущем и возвращаются в приложение. В распределенной системе кэширование может выполняться в нескольких местах, например, в клиенте, DNS, CDN, балансировщике нагрузки, шлюзе API, сервере, базе данных и т. д.

7. Секционирование данных

В базе данных горизонтальное секционирование, также известное как шардирование (sharding), включает в себя разделение строк таблицы на более мелкие таблицы и хранение их на разных серверах или экземплярах базы данных. Это делается для распределения нагрузки базы данных между несколькими серверами и повышения производительности. С другой стороны, вертикальное секционирование включает в себя разделение столбцов таблицы на отдельные таблицы. Это сделано для уменьшения количества столбцов в таблице и повышения производительности запросов, которые обращаются только к небольшому количеству столбцов.

8. Репликация базы данных

Репликация базы данных — это метод, используемый для хранения нескольких копий одной и той же базы данных на разных серверах или в разных расположениях. Основной целью репликации баз данных является повышение доступности, избыточности и отказоустойчивости данных, гарантируя, что система продолжит функционировать даже в случае сбоев оборудования или других проблем. В реплицированной базе данных один сервер выступает в качестве основной (или главной) базы данных, в то время как другие функционируют как реплики (или ведомые). Процесс включает в себя синхронизацию данных между базой данных-источником и репликами, чтобы все они имели одинаковую актуальную информацию. Репликация базы данных имеет несколько преимуществ, в том числе:

• Улучшенная производительность: Распределяя запросы на чтение между несколькими репликами, можно снизить нагрузку на базу данных-источник и сократить время отклика на запросы.
• Высокая доступность: В случае сбоя или простоя базы данных-источника реплики могут продолжать обслуживать данные, обеспечивая бесперебойный доступ к приложению.
• Улучшенная защита данных: Наличие нескольких копий базы данных в разных расположениях помогает защититься от потери данных из-за сбоев оборудования или других аварий.
• Балансировка нагрузки: Реплики могут обрабатывать запросы на чтение, что позволяет лучше распределять нагрузку и снижает общую нагрузку на базу данных-источник.

9. Распределенные системы обмена сообщениями

Распределенные системы обмена сообщениями позволяют обмениваться сообщениями между несколькими потенциально географически рассредоточенными приложениями, службами или компонентами надежным, масштабируемым и отказоустойчивым образом. Они облегчают связь, разделяя компоненты отправителя и получателя, позволяя им развиваться и работать независимо. Распределенные системы обмена сообщениями особенно полезны в крупномасштабных или сложных системах, таких как системы микросервисов или распределенные вычислительные среды. Примерами таких систем являются Apache Kafka и RabbitMQ.

10. Микросервисы

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

• Единая ответственность: Каждый микросервис фокусируется на определенной функциональности или предметной области, придерживаясь принципа единой ответственности. Это упрощает понимание, разработку и обслуживание сервисов.
• Независимость: Микросервисы можно разрабатывать, развертывать и масштабировать независимо друг от друга. Это обеспечивает повышенную гибкость и оперативность процесса разработки, поскольку команды могут одновременно работать над различными сервисами, не влияя на всю систему.
• Децентрализованность: Микросервисы, как правило, децентрализованы, и каждый сервис владеет своими данными и бизнес-логикой. Это способствует разделению обязанностей и позволяет командам принимать решения и выбирать технологии, которые наилучшим образом соответствуют их конкретным требованиям.
• Коммуникация: Микросервисы взаимодействуют друг с другом с помощью облегченных протоколов, таких как HTTP/REST, gRPC или очередей сообщений. Это способствует функциональной совместимости и упрощает интеграцию новых сервисов или замену существующих.
• Отказоустойчивость: Поскольку микросервисы независимы, сбой в одной службе не обязательно приводит к сбою всей системы. Это может помочь повысить общую устойчивость приложения.

11. Базы данных NoSQL

Базы данных NoSQL, или базы данных «не только SQL», представляют собой нереляционные базы данных, предназначенные для хранения, управления и извлечения неструктурированных или частично структурированных данных. Они предлагают альтернативу традиционным реляционным базам данных, которые полагаются на структурированные данные и предопределенные схемы. Базы данных NoSQL стали популярными благодаря своей гибкости, масштабируемости и способности обрабатывать большие объемы данных, что делает их хорошо подходящими для современных приложений, обработки больших данных и аналитики в реальном времени. Базы данных NoSQL можно разделить на четыре основных типа:

• Документные: Эти базы данных хранят данные в структурах, похожих на документы, таких как JSON или BSON. Каждый документ является автономным и может иметь свою уникальную структуру, что делает их пригодными для работы с разнородными данными. Примерами баз данных NoSQL на основе документов являются MongoDB и Couchbase.
• Ключ-значение: Эти базы данных хранят данные в виде пар "ключ-значение", где ключ выступает в качестве уникального идентификатора, а значение содержит связанные данные. Базы данных "ключ-значение" очень эффективны для простых операций чтения и записи, и их можно легко секционировать и масштабировать по горизонтали. Примерами баз данных NoSQL типа "ключ-значение" являются Redis и Amazon DynamoDB.
• Колончатые: Эти базы данных хранят данные в семействах столбцов, которые представляют собой группы связанных столбцов. Они предназначены для обработки рабочих нагрузок с большим количеством операций записи и очень эффективны для запроса данных с известными ключами строк и столбцов. Примерами баз данных NoSQL семейства столбцов являются Apache, Cassandra и HBase.
• Графовые: Эти базы данных предназначены для хранения и запроса данных, которые имеют сложные отношения и взаимосвязанные структуры, такие как социальные сети или рекомендательные системы. Графовые базы данных используют узлы, ребра и свойства для представления и хранения данных, что упрощает выполнение сложных обходов и запросов на основе связей. Примерами графовых баз данных NoSQL являются Neo4j и Amazon Neptune.

12. Индекс базы данных

Индексы базы данных — это структуры данных, которые повышают скорость и эффективность операций запросов в базе данных. Они работают аналогично индексу в книге, позволяя системе управления базами данных (СУБД) быстро находить данные, связанные с определенным значением или набором значений, без необходимости поиска в каждой строке таблицы. Предоставляя более прямой путь к нужным данным, индексы могут значительно сократить время, необходимое для извлечения информации из базы данных. Индексы обычно строятся на основе одного или нескольких столбцов таблицы базы данных. Наиболее распространенным типом индекса является индекс B-дерева, который организует данные в иерархическую древовидную структуру, что позволяет быстро выполнять операции поиска, вставки и удаления. Существуют и другие типы индексов, такие как растровые индексы и хэш-индексы, каждый из которых имеет свои конкретные варианты использования и преимущества. Хотя индексы могут значительно повысить производительность запросов, у них также есть некоторые компромиссы:

• Место для хранения: Индексы занимают дополнительное пространство для хранения, так как они создают и поддерживают отдельные структуры данных наряду с исходными табличными данными.
• Производительность записи: При вставке, обновлении или удалении данных в таблице необходимо также обновить связанные индексы, что может замедлить операции записи.

13. Распределенные файловые системы

Распределенные файловые системы — это решения для хранения данных, предназначенные для управления и предоставления доступа к файлам и каталогам на нескольких серверах, узлах или машинах, часто распределенных по сети. Они позволяют пользователям и приложениям получать доступ к файлам и управлять ими, как если бы они хранились в локальной файловой системе, даже если фактические файлы могут физически храниться на нескольких удаленных серверах. Распределенные файловые системы часто используются в крупномасштабных или распределенных вычислительных средах для обеспечения отказоустойчивости, высокой доступности и повышения производительности.

14. Система уведомлений

Они используются для отправки уведомлений или предупреждений пользователям, таких как электронные письма, push-уведомления или текстовые сообщения.

15. Полнотекстовый поиск

Полнотекстовый поиск позволяет пользователям искать определенные слова или фразы в приложении или на веб-сайте. Когда пользователь запрашивает, приложение или веб-сайт возвращает наиболее релевантные результаты. Чтобы сделать это быстро и эффективно, полнотекстовый поиск использует инвертированный индекс, который представляет собой структуру данных, которая сопоставляет слова или фразы с документами, в которых они появляются. Примером таких систем является Elastic Search.

16. Распределенный сервис координации

Распределенный сервис координации — это системы, предназначенные для управления и координации деятельности распределенных приложений, служб или узлов надежным, эффективным и отказоустойчивым образом. Они помогают поддерживать согласованность, обрабатывать распределенную синхронизацию и управлять конфигурацией и состоянием различных компонентов в распределенной среде. Распределенные координационные службы особенно полезны в крупномасштабных или сложных системах, таких как микросервисные архитектуры, распределенные вычислительные среды или кластерные базы данных. Примерами таких сервисов являются Apache ZooKeeper, etcd, Consul.

Итоги

Увеличьте свои шансы на успешное прохождение собеседований по проектированию систем, используя вышеупомянутые концепции проектирования системы. Ниже приведен список распространенных вопросов на собеседовании по проектированию систем:

• Разработка файлообменного сервиса, такого как Google Drive или Dropbox.
• Проектирование платформы потокового видео
• Проектирование службы сокращения URL-адресов
• Проектирование поискового робота
• Проектирование Uber
• Разработка мессенджера
• Проектирование поиска в Твиттере

В ранние времена (конце 80-х и начале 90-х) разработка программного обеспечения в основном заключалась в программном обеспечении, которое работало локально на вашем компьютере или на мейнфреймах со значительно большей вычислительной мощностью, если у вас был к нему доступ. Сегодня большая часть разрабатываемого программного обеспечения либо работает в облаке, либо работает на устройстве, требующем доступа к облаку, либо поддерживает другое программное обеспечение, которое также работает в облаке. Очень редко случается работать над программной системой, которая работает в ограниченном пространстве (например, встроенные программные системы), которые не имеют доступа к более мощной вычислительной платформе в другом месте. Системы бухгалтерского учета теперь обрабатывают кучи данных, размещенных на собственном железе либо в хранилище данных. В системах продаж теперь отношения с клиентами управляются третьей стороной с помощью плагинов, разработанных еще большим количеством сторонних или собственных разработчиков.

Но как эти программные системы создаются сегодня, чтобы обслуживать сотни миллионов пользователей, сохраняя при этом производительность и отзывчивость, которые мы привыкли ожидать от программного обеспечения? В этой статье поговорим о системном проектировании, о том, как оно стал важной частью современной практики разработки программного обеспечения и как оно станет одной из ключевых областей, в которых инженеры-программисты все еще могут приносить пользу в краткосрочной и среднесрочной перспективе.

Важность проектирования систем

Проектирование системы включает в себя понимание ограничений, при которых система должна выполнять свою функцию, каковы требуемые функции и какие свойства системы важно сохранить по отношению ко всем другим свойствам. После того, как вы определили их, вы можете приступить к проектированию системы, отвечающей требованиям, и систематически планировать доставку решения.

Компоненты проектирования системы

Когда мы говорим о проектировании системы, обычно это влечет за собой несколько компонентов:

• Архитектура — как выглядит решение в целом? Включает ли он в себя несколько подсистем? Есть ли отдельные компоненты, составляющие единое целое? Как они взаимодействуют и как они связаны друг с другом?
• Топология — есть ли в решении многоуровневая структура? Если это распределенная система, то где службы компонентов расположены физически или логически по отношению друг к другу?
• Низкоуровневое проектирование — Какие интерфейсы вы определили, через которые взаимодействуют различные части систем? Существуют ли конкретные алгоритмы, которые вы используете для решения ключевых аспектов решения (производительность, эффективность, пропускная способность, устойчивость и т. д.)?

Это помогает понять в первую очередь такие вещи, как: является ли система самодостаточной (т.е. не будет иметь доступа к внешним ресурсам) или она распределена? Будет ли у него пользовательский интерфейс или он будет неинтерактивным (например, генерирует ли он распечатанный отчет или потребует участия человека или другой системы во время его работы)? Нужно ли обрабатывать много трафика? Предназначен ли он для использования только десятью людьми в любой момент времени, или 10 миллионов пользователей будут использовать его в любой момент времени? Как только вы получите ответы на некоторые из этих вопросов, принятие решений на основе принципов проектирования системы станет проще.

Принципы проектирования системы

Современные системы нуждаются в масштабировании — от однопользовательской системы до системы, которая должна быть в состоянии обрабатывать тысячи и даже миллионы пользователей одновременно. Поэтому появились несколько ключевых принципов проектирования программных систем. Вот некоторые из них, которые мы рассмотрим в этой статье:

• Масштабируемость
• Надёжность
• Поддерживаемость
• Доступность
• Безопасность

Масштабируемость

Система является масштабируемой, если она может быть развернута для обработки роста нагрузки при пропорциональном росте ресурсов. Коэффициент масштабирования системы определяется как рост количества ресурсов, необходимых для обслуживания, рост нагрузки на систему. Мы сталкиваемся с двумя типичными случаями масштабирования с программными системами: вертикальное масштабирование и горизонтальное масштабирование. Вертикальное масштабирование относится к предоставлению программной системе большего запаса или ресурсов одного компьютера для обработки растущих требований. Рассмотрим случай сетевого устройства хранения данных. Чем больше места для хранения вы предоставляете с помощью устройства, тем больше данных оно может хранить. Если он необходим для обработки большего количества одновременных подключений и операций ввода-вывода (IOPS), обычно требуется добавить больше вычислительной мощности и сетевых интерфейсов, чтобы справиться с возросшей нагрузкой. Горизонтальное масштабирование относится к репликации системы или нескольких компьютеров с копиями программного обеспечения для обработки растущих требований. Рассмотрим случай сервера статического веб-содержимого, скрытого за подсистемой балансировки нагрузки. Добавление дополнительных серверов позволяет большему количеству клиентов подключаться и загружать контент с веб-серверов, а когда нагрузка спадает, количество веб-серверов может быть уменьшено до нужного размера для текущего спроса. Некоторые системы могут обрабатывать гибридное или диагональное масштабирование. Например, некоторые архитектуры распределенных баз данных позволяют разделять вычислительные узлы и узлы хранения, чтобы рабочие нагрузки с большими вычислительными ресурсами могли использовать узлы с большим количеством вычислительных ресурсов. В отличие от этого, тяжелые рабочие нагрузки операций ввода-вывода в секунду могут выполняться на узлах хранилища + вычислений. Например, приложения потоковой обработки могут разделять рабочие нагрузки, требующие больше памяти и вычислительных ресурсов (например, рабочие нагрузки поиска событий или аналитики), и масштабировать их соответствующим образом и независимо от тяжелых рабочих нагрузок операций ввода-вывода в секунду (например, сжатие и архивирование).

Надёжность

Система надежна, когда она может выдержать частичный отказ и восстановление без серьезного ухудшения качества обслуживания. Часть надежности системы включает в себя предсказуемость ее операций с точки зрения задержки, пропускной способности и соблюдения согласованного диапазона операций. Обычные подходы к обеспечению надежности системы включают следующее:

• Настройка резервирования системы для поддержки прозрачного или минимального аварийного переключения.
• Создание отказоустойчивости в случае внутренних ошибок или сбоев, вызванных вводом.
• Четкое определение контрактов и целевых показателей задержки, пропускной способности и доступности.
• Создание достаточных резервных мощностей для удовлетворения всплесков и органического роста нагрузки.
• Гарантии качества обслуживания для обеспечения соблюдения ограничений скорости и изоляции клиентов/операций.
• Реализация корректной деградации службы в сценариях перегрузки или катастрофического сбоя.

Ключевая вещь, которую следует помнить для создания надежных систем, — это обрабатывать потенциальные сбои четко определенным образом, на который зависимые системы могут реагировать. Точно так же, если система зависит от другой системы, которая может быть ненадежной, то она должна справляться с ненадежностью с помощью стратегий обеспечения надежности.

Поддерживаемость

Система пригодна для обслуживания, если она изменяется с соразмерными усилиями и развертывается с минимальным вмешательством пользователя. Для этого необходимо внедрить систему таким образом, чтобы предположить, что требования будут меняться, и что она достаточно гибкая, чтобы справляться с предсказуемыми изменениями. Это также означает обеспечение того, чтобы код был читабельным, чтобы следующий набор сопровождающих (которые могут быть той же командой, но смотрят на это новыми глазами в будущем) мог поддерживать программное обеспечение и развивать его для удовлетворения будущих потребностей. Никто не хочет застрять на обслуживании программного обеспечения, которое является жестким, трудно изменяемым, плохо организованным, плохо документированным, плохо спроектированным, непроверенным и бессистемно собранным. Обеспечение высокого качества кода является частью инженерного совершенства, отражающего профессионализм и превосходное мастерство. Это не только хорошо, но и, как известно, позволяет высокофункциональным и высокопроизводительным инженерным командам поставлять программное обеспечение, которое можно изменять и расширять, чтобы постоянно приносить пользу.

Доступность

Если служба недоступна, возможно, она не существует. При проектировании систем следует учитывать, как система должна оставаться доступной, чтобы оставаться актуальной для клиентов и пользователей системы. Это означает:

• Введение избыточности для обработки сбоев базовой системы.
• Наличие сценариев резервного копирования и восстановления, а также руководств по эксплуатации для восстановления системы после жестких сбоев.
• Удалите как можно больше единичных точек сбоев из системы.
• Наряду с горизонтальной масштабируемостью используйте региональные реплики и настройте сети доставки контента (при необходимости), чтобы сделать ваши данные доступными.
• Отслеживайте доступность вашей системы с точки зрения ваших клиентов, чтобы лучше понять, как ваша система обслуживает клиентов.

Безопасность

При проектировании систем безопасность должна рассматриваться как ключевой аспект, особенно в эпоху систем, подключенных к Интернету, когда угрозы безопасности и уязвимости могут нанести реальный вред нашим клиентам и пользователям систем. Цель создания безопасного программного обеспечения состоит не в том, чтобы достичь совершенства, а в том, чтобы понять риски, связанные с нарушениями и атаками. Наличие надлежащей модели угроз безопасности и системного подхода к пониманию того, в чем заключаются риски и какие виды угроз заслуживают приоритизации и разработки мер по их устранению, является началом безопасного проектирования и инженерной практики. Сегодня безопасность является обязательной, поскольку наши программные системы становятся частью критически важных услуг для большего числа слоев современного общества. Серьезное отношение к безопасности в системах, которые мы разрабатываем с самого начала, приближает нас к тому, чтобы лучше полагаться на программное обеспечение, которое мы создаем и развертываем для удовлетворения потребностей наших пользователей. Завоевать доверие наших клиентов достаточно сложно, и достаточно одного нарушения, чтобы потерять значительную его часть.

Современные шаблоны проектирования систем

Учитывая вышеизложенные аспекты, появились некоторые закономерности для современных распределенных систем, которые по-разному решают ряд этих аспектов. Давайте рассмотрим некоторые из наиболее популярных шаблонов проектирования, которые мы видим сегодня в отношении пяти аспектов проектирования системы.

Микросервисы

С появлением распределенных систем, которые сосредоточены на повышении надежности и масштабирования за счет резервирования, эффективности и производительности за счет горизонтального масштабирования, а также отказоустойчивости за счет разделения частей системы как независимо работающих сервисов, термин «микросервисы» приобрел популярность благодаря достижению следующего:

• Привязка разработки, развертывания, эксплуатации и обслуживания независимых сервисов к командам, владеющим этими службами в рамках более крупной бизнес-операции. Мы можем сделать это, обслуживая внешних клиентов напрямую или косвенно через внутренних клиентов через API.
• Позволяет микросервису независимо масштабироваться в соответствии с потребностями.
• Предоставление услуг на основе четко определенного контракта позволяет реализации развиваться, чтобы оставаться автономной услугой или системой услуг.

Глядя на наши аспекты, микросервисы обладают привлекательными свойствами, что делает их хорошим образцом для подражания, если он применим к варианту использования:

• Масштабируемость: микросервисы без состояния, как правило, предназначены для горизонтального масштабирования, а также могут извлечь выгоду из вертикального масштабирования. В случае микросервисов, развернутых в контейнерной среде оркестровки (например, кластерах Kubernetes), микросервисы могут даже работать на одних и тех же узлах, что обеспечивает более эффективное использование существующего оборудования и масштабирование в соответствии с требованиями доступной емкости. Одним из недостатков является сложность развертывания по мере увеличения масштаба и критичности микросервисов.
• Надежность: микросервисы без состояния обычно размещаются за подсистемой балансировки нагрузки и географически распределены, чтобы избежать региональных сбоев, забирающих всю емкость системы. Одним из недостатков повышения надежности с помощью микросервисов без состояния является то, что система хранения данных, как правило, должна быть такой же или более надежной, чем реализация или развертывание микросервиса. Микросервисы с состоянием страдают от худшего из обоих подходов, где затраты на надежность обычно выражаются в виде избыточного выделения ресурсов для обработки потенциальных сбоев.
• Удобство сопровождения: микросервисы, реализующие четко определенный и стабильный контракт, обслуживаемый через API, позволяют клиентам программировать на основе этого API, а реализация развивается независимо. Однако координация изменений в API включает в себя потенциально дорогостоящую миграцию клиентов и координацию между командами, что приводит к периоду, когда микросервис имеет несколько активно поддерживаемых версий до тех пор, пока последние клиенты не перейдут из старой реализации. Ситуация только ухудшается по мере того, как все больше клиентов начинают взаимодействовать с микросервисом.

• Доступность: микросервисы обычно полагаются на среду развертывания и внешнюю инфраструктуру для удовлетворения требований клиентов к доступности. Недостатком этого является зависимость от конкретной инфраструктуры, на которой развертывается микросервис, для предоставления решения высокой доступности. Такие системы, как сервисные сетки и программные балансировщики нагрузки, становятся критически важными частями инфраструктуры, которые больше не контролируются реализацией. Это может быть хорошо, но также может быть постоянным источником обслуживания, поскольку эти системы также имеют циклы обновления и эксплуатационные расходы.
• Безопасность: аутентификация, авторизация, управление идентификацией и управление учетными данными могут быть делегированы промежуточному ПО или с помощью внешних механизмов (например, удостоверений рабочей нагрузки в Kubernetes), где реализация микросервисов может быть сосредоточена на интеграции соответствующей бизнес-логики. Недостатком, как и доступность, является то, что эти внешние части решения становятся критически важными частями инфраструктуры, которые приносят свои собственные эксплуатационные расходы поверх реализации микросервиса.

Микросервисы — это отличный способ разбить большое приложение, где можно определить логические разделы, требующие собственных доменов масштабирования и надежности. Однако, когда вы начинаете с нуля, не лучше проектировать микросервисы с самого начала из-за риска разбить службы на слишком мелкие части. Затраты на обмен данными между микросервисами (как правило, в виде запросов HTTP или gRPC) значительны и должны быть понесены только в случае необходимости. Хороший способ определить, подходит ли функциональность для службы, — следовать таким практикам, как проектирование на основе предметной области или функциональная декомпозиция.

Бессерверные технологии

Как и в решениях на основе микросервисов, использование бессерверных реализаций дополнительно делегирует ключевые элементы функциональности обслуживания запросов базовой инфраструктуре. Если в микросервисах служба обслуживается постоянным процессом, бессерверные решения обычно реализуют только точку входа для обработки запроса к конечной точке (обычно URI через HTTP или gRPC). В бессерверных развертываниях фактические серверы не настраиваются, а среда развертывания запускает ресурсы по мере необходимости для обработки запросов по мере их поступления. Иногда эти ресурсы остаются в силе в течение некоторого времени, чтобы амортизировать затраты на их создание, но это должно быть деталью реализации. Давайте рассмотрим аспекты проектирования системы, чтобы увидеть, как складываются бессерверные решения:

• Масштабируемость: Бессерверные решения так же горизонтально масштабируемы, как и микросервисы, если не больше, потому что они спроектированы так, чтобы иметь правильный размер по требованию. Недостатком этого подхода является необходимость большего контроля и полного делегирования функций масштабирования базовой бессерверной инфраструктуре.
• Надежность: Надежность бессерверных технологий зависит от емкости горизонтального масштабирования и маршрутизации сетевого трафика. Это имеет те же недостатки, что и решение Microservices.
• Удобство сопровождения: Бессерверные реализации более удобны в обслуживании, чем микросервисы, из-за акцента на бизнес-логике обработки запросов с минимальным шаблоном. Это имеет те же проблемы с эволюцией API, что и микросервисы.
• Доступность: бессерверные системы доступны так же, как и среда, в которой они развернуты. Это имеет те же проблемы, когда базовая инфраструктура становится более важной, чем само решение.
• Безопасность: Бессерверные реализации полностью зависят от конфигурации безопасности базовой инфраструктуры. Это имеет те же проблемы, когда базовая инфраструктура становится более важной, чем само решение.

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

Событийно-ориентированные системы (Event-Driven)

Тем не менее, есть некоторые проблемные области, где обработка онлайн-транзакций не требуется, а микросервисы и бессерверные реализации не совсем соответствуют всем требованиям. Рассмотрим случаи, когда обработка транзакций может выполняться в фоновом режиме или при наличии ресурсов. Другой случай касается фоновой обработки, когда результаты не обязательно являются интерактивными. Системы, управляемые событиями, следуют схеме наличия источника событий и приемников событий, откуда происходят и отправляются события (сообщения) соответственно. Обработка происходит от подписчиков и издателей к этим источникам и приемникам соответственно. Примером событийно-управляемой системы является чат-бот, который может участвовать во многих беседах (источники событий и приемники) и обрабатывать сообщения по мере их поступления. Распределенные системы, управляемые событиями, могут иметь несколько параллельных обработчиков сообщений, ожидающих в одних и тех же источниках, что может привести к публикации слишком большого количества приемников, которые выступают в качестве источников для других обработчиков сообщений. Этот шаблон объединения процессоров через приемники и источники называется конвейером событий. Как правило, существует единая реализация приемников и источников, которая предоставляет интерфейс очереди сообщений и масштабируется в соответствии со спросом на сообщения, поступающие через систему. Многие системы управления распределенными очередями также могут эффективно использовать диагональное масштабирование, например Apache Kafka, RabbitMQ и т. д. Давайте рассмотрим распределенные системы, управляемые событиями, с точки зрения наших пяти аспектов:

• Масштабируемость: как реализация брокера сообщений/событий, так и обработчики сообщений могут масштабироваться независимо друг от друга. Некоторые недостатки возникают, когда обрабатывается слишком много сообщений/событий, и спрос на брокера событий растет далеко за пределы пропускной способности, доступной в системе.
• Надежность: Хорошие реализации брокера сообщений обеспечивают высокий уровень надежности, и рекомендуется не создавать собственную реализацию брокера сообщений. Недостатком является зависимость от решения, которое отвечает требованиям надежности решения (например, обработка финансовых транзакций сильно отличается от обработки маршрутизации обмена мгновенными сообщениями в чатах).
• Удобство сопровождения: Если вы используете гибкий формат обмена сообщениями, такой как буферы протоколов, вполне вероятно развивать авторов и читателей сообщений, используя один и тот же язык описания данных. Это по-прежнему требует координации, но не такой обременительной, как развивающиеся контракты API в системах обработки транзакций в реальном времени (как в микросервисах и бессерверных реализациях).

• Доступность: cистемы, управляемые событиями, обычно легче сделать доступными, тем более что они, как правило, не являются интерактивными приложениями. Стоимость доступности может быть связана с устаревшими сообщениями и неограниченными задержками обработки очередей.
• Безопасность: системы, управляемые событиями, должны управлять доступностью данных независимо от учетных данных. Обеспечение того, чтобы только определенные службы или обработчики сообщений могли получить доступ к определенным очередям сообщений или журналам, становится постоянной работой, поскольку через систему проходят более разнообразные данные.

Итоги

Современная разработка программного обеспечения влечет за собой проектирование масштабируемых, надежных, обслуживаемых, доступных и безопасных систем. Проектирование распределенных систем требует значительной строгости, поскольку реалии сложности современных систем растут вместе с потребностями общества в более качественных программных услугах. Мы рассмотрели три современных шаблона проектирования для распределенных систем и проработали пять аспектов хорошо спроектированных систем. Как инженеры-программисты, мы несем ответственность за разработку систем, которые решают ключевые проблемы распределенных систем в современную эпоху.