Что является хорошей отправной точкой для проектирования архитектуры с учетом масштабируемости?

Question

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

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

Я думаю о PostgreSQL для хранения данных, потому что я уже использовал его, и мне это нравится (также, если NoSQL будет хорошим выбором - так как не все данные должны иметь отношение - мне нравится Postgres поддержка и сообщество, и я чувствую себя лучше, зная, что есть большое сообщество, которое может мне помочь), MySQL (innodb) также является хорошим выбором, хотя у меня нет реальной причины выбирать его среди PostgreSQL и наоборот (возможно, MySQL проще создавать осколки?).

Я знаю несколько языков программирования, но мои сильные стороны - это Python, C / C ++, Javascript.

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

Я уже разработал еще один крупномасштабный проект, который научил меня многим вещам, связанным с параллелизмом, но там каждый выбор зависел от (всей остальной части команды, но в основном от) навыков сисадмина, поэтому мы имеем использованный питон (django) + uwsgi + nginx.

Для этого проекта (так как он полностью отличается от другого - это была электронная коммерция, это такой SaaS), я также рассматривал возможность использования node.js, это была бы хорошая возможность попробовать его в серьезном проекте. Самая тяжелая обработка данных будет выполняться пост-процессами, поэтому весь интерфейс (веб-сайт пользователя) будет в основном вводом-выводом (+1 для использования асинхронной среды).

Что бы вы предложили?

пс. Я также должен помнить, что в первую очередь проект должен начаться, поэтому я не могу думать только о каждом возможном проекте, но я должен начать писать код как можно скорее: -)

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

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

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

Если вам нужна дополнительная информация, пожалуйста, дайте мне знать, и я постараюсь дать вам ответ. Спасибо.

Answer 1

Хороший ресурс для всего этого - http://highscalability.com/. Множество интересных примеров использования больших веб-загрузок.

Вы не упомянули об этом, но вы можете подумать о размещении его в облаке (Azure, Amazon и т. Д.). Делает масштабирование оборудования немного проще, и это особенно приятно, если ваш спрос колеблется.

Answer 2

Вот несколько основных рекомендаций:

1. Используйте как можно больше асинхронных процессов.Или, по крайней мере, спроектируйте его так, чтобы он мог быть преобразован в асинхронный.
2. Процессы проектирования так, чтобы их можно было разделить на разных серверах.Это также идет к выше.Скажем, у вас есть веб-приложение, которое имеет несколько интенсивных процессов.Если этот процесс асинхронный;тогда основной веб-сервер может поставить задачу в очередь и завершить работу.Затем отдельный сервер может выбрать задание и обработать его.Таким образом, ваши основные веб-серверы не будут затронуты.Но если вы ограничены в ресурсах, вы все равно можете запустить фоновый процесс на том же сервере (пока у вас не будет достаточно клиентов, а затем вы сможете запустить его на другом сервере)
3. Дизайн для распределения нагрузки.Поэтому, если ваше приложение использует сеансы, вы должны учитывать, как вы будете реплицировать сеансы или нет.Вам не нужно - вы можете отправить пользователя в diff.сервер, а затем перенаправить все последующие запросы на этот сервер.Но вы все равно должны разрабатывать его.
4. Возможность маршрутизации загрузки на разные серверы на основе некоторых предварительно определенных критериев.Например, поскольку ваше приложение является приложением SAAS, вы можете решить, что определенные клиенты перейдут в Environment1, а некоторые другие клиенты - в Environment2.Многие игроки SAAS делают это.Например, Salesforce.Вам не обязательно делать это с самого начала, но наличие этой способности будет иметь большое значение для масштабирования вашего приложения, когда придет время.

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

Взгляните на книгу Искусство масштабируемости Эта книга была написана парнями, которые работали с eBay & Paypal.

Answer 3

Расскажите о этой превосходной презентации о шаблонах и подходах масштабируемости.