Краткий обзор системного проектирования: узнайте основы системного проектирования

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

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

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

Мы рассмотрим следующее:

• Что такое проектирование системы?
• Шаг 1: Уточнение требований
• Шаг 2: Оценка важных частей
• Шаг 3: Поток данных
• Шаг 4: Высокоуровневое проектирование компонентов
• Шаг 5: Детальное проектирование
• Шаг 6: Выявление и устранение узких мест
• Следующие шаги для проектирования системы

Что такое проектирование систем?

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

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

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

Системное проектирование включает в себя следующие методы проектирования:

• Архитектурное проектирование: описывает представления, модели, поведение и инфраструктуру системы.
• Логическое проектирование: представляет поток данных и входы/выходы системы.
• Физическое проектирование: включает в себя то, как пользователи могут добавлять информацию, как система представляет информацию пользователям и как данные моделируются/хранятся.

Различные виды систем

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

Горизонтальное масштабирование

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

Вертикальное масштабирование

При вертикальном масштабировании используется одна огромная машина, которая обрабатывает все ваши запросы и улучшает время отклика и пропускную способность. Хотя оно обеспечивает более быстрые сетевые вызовы, согласованность данных и отсутствие балансировки нагрузки, у вас есть единая точка отказа и аппаратные ограничения.

Монолитные приложения

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

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

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

Шаг 1: Уточнение требований

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

Функциональные требования

Функциональные требования — это требования, которые должна выполнять система. Это основные цели системы. Функциональные требования включают такие вещи, как бизнес-правила, аутентификация, административные функции, уровни авторизации и т.д.

Нефункциональные требования

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

Возьмем Twitter, некоторые функциональные требования могут включать в себя:

• Пользователи должны иметь возможность публиковать новые твиты
• Пользователи должны иметь возможность следить за другими пользователями
• Пользователи должны иметь возможность отмечать твиты как избранные.

К нефункциональным требованиям можно отнести:

• Высокая доступность
• Согласованность
• Задержка около 200 мс для генерации временной шкалы.

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

Шаг 2: Оценка важных частей

Этот шаг касается масштаба вашей системы. То, как вы будете его оценивать, зависит от вашей системы. Вам нужно учитывать такие параметры, как количество запросов в секунду и данные, которые система должна будет обрабатывать.

Для Twitter нам нужно будет учитывать такие параметры, как объем хранилища, оценка пропускной способности, общее количество просмотров твитов и т.д. Допустим, у нас около 200 миллионов ежедневных активных пользователей, сто миллионов новых твитов, и каждый пользователь следит примерно за 200 людьми.

Хранение

Если предположить, что каждый твит содержит 140 символов, для хранения одного символа без сжатия требуется два байта, а для хранения метаданных — еще 30 байт, то общая потребность в хранилище составит примерно:

100x(280+30)= 30 ГБ в день.

Оценка пропускной способности

Ingress:

Если каждый пятый твит содержит фотографию размером 200 КБ, а каждый десятый — видео размером 2 МБ, то пропускная способность составит:

(100M/5 фотографий * 200KB) + (100M/10 видео * 2MB) = 24TB/день.

Выход:

У нас 28Б твитов в день, нам нужно показать каждую фотографию, но если предположить, что пользователь видит только каждое третье видео на своей временной шкале, поток будет следующим:

(28B * 280 байт) / 86400 секунд текста => 93MB/s

+(28B/5 * 200KB ) / 86400s фотографий => 13GB/S

+(28B/10/3 * 2MB ) / 86400s видео => 22GB/s

Итого =35GB/s

Общее количество просмотров твитов

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

200M DAU * ((2 + 5) * 20 твитов) => 28B/день.

Шаг 3: Поток данных

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

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

• Вы создаете первую версию своей системы и не совсем уверены в шаблонах доступа к данным.
• Вы хотите поддерживать нулевую избыточность данных.

2. Базы данных NoSQL: Это хороший вариант, если ваша модель данных не имеет фиксированной схемы.

3. Графовые базы данных: Графовые базы данных — хорошая идея, если у вас много отношений «многие-ко-многим».

Возможная схема базы данных для Twitter может быть следующей:

Шаг 4: Высокоуровневое проектирование компонентов

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

Исходя из наших оценок для Twitter, нам понадобится система, которая сможет справиться со всей этой нагрузкой и при этом эффективно храниться.

Шаг 5: Детальное проектирование

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

На этом этапе также важно провести анализ компромиссов. На этом этапе обычно рассматриваются такие соображения, как.

• Сколько данных нужно кэшировать, чтобы ускорить время отклика?
• Где нам нужно использовать балансировщик нагрузки?
• Нужно ли нам разделить данные, чтобы распределить их по нескольким базам данных?

6. Шаг 6: Выявление и устранение узких мест

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

Некоторые вопросы, которые следует рассмотреть на этом этапе, следующие:

• Есть ли в этой системе единая точка отказа? Как ее устранить?
• Достаточно ли у вас копий данных для обслуживания пользователей в случае потери нескольких серверов?
• Достаточно ли у нас копий наших сервисов, чтобы предотвратить остановку?

Следующие шаги по проектированию системы

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

Следующие темы рекомендуются в качестве следующего шага для понимания системного дизайна:

• Изучите реальные примеры проектирования систем
• Основы микросервисов
• Основы проектирования баз данных

Если вы хотите глубже изучить этот вопрос, обратите внимание на комплексный курс Grokking Modern System Design for Software Engineers & Managers от Educative. В этом курсе рассматриваются все важные концепции веб-приложений, микросервисов и архитектуры AWS, а также практические занятия по кодированию и многое другое.

Счастливого обучения!

Продолжить чтение о системном проектировании на Educative

• Полное руководство по системному проектированию в 2022 году
• Grokking Modern System Design for Software Engineers & Managers
• Микросервисы в Azure: введение
• Учебник по проектированию баз данных

Начать обсуждение

Какие особенности проектирования систем вы надеетесь изучить в следующий раз? Была ли эта статья полезной? Сообщите нам об этом в комментариях ниже!