Что следует учитывать при принятии решения о том, реплицировать или распространять для поддержки масштабируемости?

Question

При написании приложения для поддержки масштабируемости, как мне решить, поддерживать ли его с использованием таких технологий, как EJB, и распределять приложение по нескольким машинам или писать программное обеспечение без использования таких технологий и просто копировать его на нескольких машинах?

Есть ли хорошие источники (книги / статьи), объясняющие это?

Answer 1

Масштабируемость - это больше возможностей архитектуры. Технологии и инструменты просто реализуют эту возможность.

Если вы определяете свою архитектуру по своей природе масштабируемой, то вы можете модифицировать любые технологии для поддержки этой архитектуры. Вы можете найти примеры, которые очень хорошо масштабируются для большой пользовательской базы практически во всех технических стеках (будь то PHP, .NET, Java, COBOL, RoR и т. Д.).

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

Если говорить о конкретной технологии, о которой вы упомянули, EJB - это технология промежуточного программного обеспечения, которая поставляется с багажом - сервер приложений Java EE (или Tomcat с некоторой сантехникой). Дело в том, что решения EJB не являются легковесными и рекомендуются для конкретных случаев использования, таких как: удаленность, транзакции и т. Д. Кроме того, стоимость разработки решений на основе стандартов ниже, чем просто использование стека с открытым кодом.

С точки зрения масштабируемости, основанные на стандартах решения, т. Е. EJB, JPA и т. Д., Также поддерживают облачные вычисления и поддерживают масштабируемость облака, то есть репликацию и совместное использование. Проверьте эту ссылку .

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

Answer 2

Масштабируемость - это широкий термин, как правило, не зависит от технологии.

Если на этапе разработки вы решите, я знаю, что это приложение будет поддерживать 100 000 пользователей, но я бы хотел иметь возможность поддерживать до 1 миллиона пользователей без необходимости рефакторинга, тогда вы, как правило, хотите обратиться к IMHO. такого рода масштабирование через «аппаратный» подход. Если вы знаете, что ваш проект может нормально обрабатывать 100 тыс. Пользователей на 2 серверах в кластере, то при увеличении аппаратного обеспечения можно достичь 1 млн., ОБЕСПЕЧИВАЯ программное решение, обеспечивающее 100 тыс. Базовых возможностей.

Распределенные технологии интересны и хороши, но у них есть накладные расходы и проблемы, которые с ними связаны. Это не имеет большого значения, когда ваш кластер имеет только 2 узла, и вам нужен объект от другого узла, вы знаете, где находится этот узел, и можете обратиться за ним ... и это имеет цену, но обычно это не что-то возмутительное но когда вы масштабируете это, скажем, теперь у вашего кластера есть 25 или 50 серверов, получение этого объекта, даже если у вас есть хороший контейнер, играющий за него, может стать совершенно другой игрой в мяч.

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

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

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

Answer 3

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

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

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

Я не думаю, что это как-то связано с какой-то конкретной технологией.Вы можете использовать EJB, и вы все равно не сможете масштабировать по горизонтали.Это не так просто.Есть хорошая книга Кэла Хендерсона «Создание масштабируемых веб-сайтов».Для начала неплохо было бы прочитать.