Плюсы / минусы шардинга с использованием «узлов app + db» по сравнению с раздельным шардингом дб и балансировкой нагрузки серверов приложений - PullRequest
Новая
       30

Плюсы / минусы шардинга с использованием «узлов app + db» по сравнению с раздельным шардингом дб и балансировкой нагрузки серверов приложений

2 голосов
/ 08 июля 2011

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

  • «оголили приложение»серверы », размещая код сервера приложений и базу данных на каждом физическом сервере, так что сервер приложений подключается только к своему собственному шарду;
  • серверы приложений общаются друг с другом, когда им требуется доступ к другим шардам (вместо прямого обращения к БД другого шарда;
  • пусть клиент API выбирает сам шард приложения (на стороне клиента, основываясь на некотором стабильном хеше) и напрямую обращается к нему.

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

(стек - это PHP + Node.js наMySQL, хотя на этом этапе также рассматривается переход на MongoDB.)

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

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

1 Ответ

2 голосов
/ 08 июля 2011

Это просто плохо по многим причинам.

  • Клиент API не должен знать, с каким шардом приложения следует обращаться.Это ограничит вас такими способами, которые вы, вероятно, не можете предвидеть сейчас, но могут / станут проблемой в будущем.Клиент API должен вести себя глупо, чтобы вы могли соответствующим образом направлять запросы, если сервер приложений умирает, изменяется, снова подвергается разбиению и т.д.(Не оба одновременно, только один).Теперь у вас есть осколок БД, замедляющий осколок приложения.
  • В ваших осколках БД + приложения должны храниться и код приложения + память и код дБ + память в оперативной памяти.Это означает, что процессоры будут тратить больше времени на обмен кода и памяти для выполнения обоих наборов задач.
  • Мне трудно выразить словами, но этот тип архитектуры кричит «плохая связь» и «отсутствие разделения интересов» (вероятно, не правильная терминология, но я надеюсь, вы понимаете, что я имею в виду),Вы помещаете два совершенно разных типа приложений (сервер приложений и базу данных) в один ящик.Управляющий кошмар их обновления и маршрутизации вокруг сбойных экземпляров будет очень трудным.

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

...