Как сделать мое приложение Java масштабируемым и отказоустойчивым?
в упрощенном виде мое приложение Java можно описать следующим образом:
Это веб-приложение, работающее на сервере Tomcat с интерфейсом SOAP. Приложение использует JPA / Hibernate для хранения данных в базе данных MySQL. Хранящиеся данные состоят из списка пользователей, списка хостов и списка URI, указывающих на огромные файлы (10 ГБ) в файловой системе. Вся система состоит из центрального сервера, на котором работает мое приложение, и группы рабочих хостов. Пользователь может подключитесь к интерфейсу SOAP и попросите систему скопировать принадлежащие ему файлы на конкретный рабочий Хост, где он сможет каким-то образом проанализировать данные (мы не можем использовать NFS, нам нужно скопировать данные на локальное дисковое хранилище рабочего хоста). Затем база данных сохраняет для каждого пользователя, на котором хранятся файлы рабочего узла.
на данный момент система работает с одним центральным сервером с приложением Tomcat и базой данных MySQL и 10 рабочими хостами и около 30 пользователями которые имеют размер 100 файлов (в среднем 10GB), хранящихся на рабочих хостах.
но в будущем я должен масштабировать систему в 100-1000 раз. Поэтому мне, возможно, придется иметь дело с 10000 пользователями, 100000 файлами и 10000 хостами. И система также должна стать отказоустойчивой, так что у меня нет ни одного центрального сервера (который сейчас является единственной точкой отказа в системе), но, возможно, несколько. Кроме того, если один из рабочих хостов терпит неудачу, система должна быть уведомлена, поэтому он не пытается копировать файлы на этом сервере.
теперь мой вопрос: Какие технологии Java я мог бы использовать, чтобы сделать мое приложение масштабируемым и отказоустойчивым? Какую архитектуру вы бы порекомендовали? Должна ли у меня все еще быть огромная база данных, хранящая всю информацию обо всех файлах, хостах и пользователях в системе в одном месте, или мне лучше распространять свою базу данных на нескольких хостах и синхронизировать их каким-то образом?
1 ответов
необходимая вам технология называется архитектурой.
независимо от того, какую технологию вы используете, вам нужна хорошо продуманная система масштабируемости и резервирования. Составьте схему всей архитектуры системы в том виде, в каком она работает в настоящее время. Отметьте каждый компонент с его ограничениями для пользователей, заданий, полосы пропускания, места на жестком диске, памяти или любых других частей, ограничивающих ваше приложение. Это даст вам базовый дизайн.
теперь ничья та же схема, что и должна была бы соответствовать вашим требованиям масштабируемости и избыточности. Возможно, вам придется разбивать куски, чтобы заставить его работать, или разрабатывать совершенно новые куски. На этой диаграмме будет очень ясно, что вам нужно.
одна конкретная вещь, к которой я хочу обратиться, - это база данных. Если вы можете разделить базу данных по логистическим линиям так, чтобы не соединять запросы друг с другом, то у вас должны быть отдельные базы данных. Помимо этого, лучшая конфигурация для база данных должна иметь каждую базу данных на одной быстрой машине с большим количеством хранилища и очень быстрым временем доступа. Если вы это сделаете, единственное, что замедлит вашу базу данных,-это плохие запросы или плохо индексированные таблицы. По моему опыту, синхронизации баз данных следует избегать, если у вас нет одной основной базы данных с доступом на запись и она реплицируется в другие базы данных, доступные только для чтения. Несмотря на это, это может быть последним шагом после профилирования всех ваших запросов, и вам буквально нужно дополнительное оборудование.