Для сложных систем вы действительно хотите иметь возможность масштабирования в нескольких измерениях, все из которых зависят от вашего архитектурного выбора.Прежде чем я отвечу на ваш вопрос, вот несколько мыслей о самых важных из них:
Масштабирование приложения по горизонтали, например, для более высокой нагрузки / большего количества пользователей.Я думаю, что это то, что вы имели в виду с вашим вопросом.Предполагая, что мы говорим о действительно большом приложении с миллионами пользователей, где эта проблема становится наиболее распространенной, узких мест много, и постоянство - только одно из них.Теория распределенных систем, микросервисов, прикладных уровней без сохранения состояния и многих современных технологий решают эту проблему.Для баз данных это рост кластеризованных баз данных, для бизнес-логики это развертывание служб без сохранения состояния, а для инфраструктуры - рост облачных и виртуализированных аппаратных кластеров.Что касается вашего вопроса о базах данных, я бы порекомендовал рассмотреть компромиссы для масштабируемых баз данных no-sql, а также cockroachdb для кластерного, транзакционного и реляционного выбора.Эти варианты позволят вам обойти ограничения старой базы данных для одного сервера, которые, как представляется, подразумеваются предложением организовать несколько БД.
Масштабировать размер организации / разработки, чтобы иметь возможность разрабатыватьбыстрее и добавить больше функций за более короткое время.Это обычно требуется и для успешного применения с миллионами активных пользователей.Таким образом, вам придется организовать команды разработчиков с сотнями или тысячами разработчиков.Здесь узким местом является количество необходимых координационных усилий.И поскольку во многих традиционных крупных организациях менеджмент среднего звена заинтересован в том, чтобы собрать как можно большую команду, много раз случалось, что формировались большие, неэффективные команды разработчиков, которые проводят большую часть своего времени, выстраивая свою работу, чтобы произвести позорнодорогое приложение в стиле монолита.Эта проблема обобщена в Законе Конвея .Таким образом, способ борьбы с этим для (как правило, более молодых) компаний заключается в переходе к очень плоской иерархии и к небольшим, независимым командам.Независимость является ключевым фактором здесь.Команды могут разрабатывать свое собственное видение (управление продуктом), выполнять свою собственную разработку, а также выпускать собственный продукт (модуль, сервис, приложение и т. Д.).
Затем, наконец,Приходите к исходному вопросу:
почему я должен масштабировать код
С пунктом 1 мы понимаем, что, в зависимости от количества одновременно активных пользователей и требуемого расчетаИз-за сложности проблемы домена нам, возможно, придется масштабировать бизнес-уровень приложения до десятков или сотен распределенных компьютеров, чтобы учесть количество одновременных сетевых подключений и достичь рабочей нагрузки (например, подумайте, что Netflix должен сделать для запуска своего сервиса).).
И, исходя из пункта 2, мы понимаем, что мы не можем совместно использовать базы данных между командами / службами, поскольку это помешало бы созданию независимых циклов разработки для них и съело бы ценную производительность благодаря усилиям по координации.1024 * Дополнительная причинаГоризонтальное масштабирование уровня бизнес-логики заключается в том, чтобы включить бесперебойное обслуживание (например, при сбое узла, будет другой, который будет принимать запросы) и разрешить обработку сложности за счет автоматизации задач (подход devops ).
Для получения дополнительной информации по этому вопросу я рекомендую прочитать статьи Мартина Фаулера в качестве отправной точки.