Если вы готовитесь к собеседованию по проектированию системы, эта статья даст вам очень быстрое представление о том, как был разработан серверный модуль Dropbox и как он постепенно развивался.

Важной частью проектирования системы является то, насколько эффективно вы можете распознавать объем улучшений по мере изменения требований, это то, что вы поймете в этой статье.

Скромное начало бэкэнда Dropbox выглядело примерно так, как на диаграмме ниже (первая версия) в середине 2007 года *.

На этот раз учредителями были только разработчики с ~ 0 пользователями. В системе все работало на одном сервере, например, БД, веб-серверы, хранилище и т. Д.

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

Итак, следующий вопрос: что может пойти не так с архитектурой слева (первая версия)?

  1. Надежность: система ненадежна, если сервер выходит из строя, системе нечего будет быстро выполнить резервное копирование.
  2. Пропускная способность: указанная выше система не может поддерживать большое количество пользователей.
  3. Пространство: это основная проблема, которую осознали основатели: на сервере закончилось место на диске для хранения дополнительных файлов.
  4. Перегрузка. Сервер быстро перегрузился.

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

Ниже (вторая версия) представлена ​​следующая улучшенная версия серверной архитектуры.

Теперь хранилище данных было перемещено на Amazon S3, а база данных MySQL находилась в другом ящике, управляемом локально Dropbox. Это решило проблему с пространством, так как теперь все файлы сохраняются в S3.

Вы можете догадаться, что сейчас могло пойти не так?

  1. Емкость. Сервер в конечном итоге вышел из строя, сервер по-прежнему выполняет все функции загрузки и веб-синхронизации. Если бы мы могли разделить функции, серверы могли бы работать лучше.
  2. Опрос: клиент все время опрашивает сервер для синхронизации изменений, что не очень хорошо. Мы могли бы решить эту проблему, установив интервал времени между опросами, можете ли вы придумать что-нибудь лучше, чем установка интервала времени?

Чтобы справиться с проблемой опроса, следующая архитектура добавила серверы уведомлений. Эти серверы будут отправлять клиенту уведомления с указанием «когда проводить опрос». Кроме того, чтобы справиться с этой емкостью, система была обновлена ​​и теперь имеет два сервера, один из которых размещен локально на управляемом хостинге, а другой - на Amazon S3. Усовершенствованная система выглядела так, как показано ниже

Благодаря указанной выше архитектуре Dropbox теперь может поддерживать около 50 тыс. Пользователей.

Теперь интересная часть системного дизайна: что пошло не так с вышеуказанной архитектурой?

  1. Горизонтальное масштабирование: у нас есть один мета-сервер и один блочный сервер, поэтому нам нужно добавить их больше. Стандартная операция.
  2. Задержка: серверы блоков выполняют прямые вызовы управляемой размещенной БД, серверы блоков находятся в Вирджинии, а БД в Техасе, поэтому эти двусторонние вызовы завершились как узкое место задержки. Для решения этой проблемы было несколько подходов, таких как хранимые процедуры, или сложные запросы к БД, или добавление дополнительной инфраструктуры кэширования. Но это потребовало большой работы. Ищу простое элегантное решение, которое может быть достигнуто с ограниченными ресурсами Dropbox, заключалось в том, чтобы заставить блочные серверы выполнять все RPC (удаленные вызовы процедур) на мета-сервере, а мета-серверы инкапсулировали всю логику для выполнения вызовов БД.
  3. База данных. Другая проблема заключается в том, что в этом контексте есть только одна БД, может быть много решений, таких как разбиение БД или сегментирование БД, но оказывается, что это проще добавить Memcached и легко кэшировать вещи.

Решив указанную выше проблему, инженеры Dropbox предложили следующее решение.

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

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

Благодаря указанной выше архитектуре Dropbox смог поддерживать более 50 миллионов пользователей.

Эта статья представляет собой суть видео * YouTube, цель написания этой статьи - дать вам общее представление за несколько минут.