Какой смысл масштабировать бизнес-логику? - PullRequest
0 голосов
/ 29 января 2019

Я копаюсь в микросервисах и пытаюсь понять, почему я должен масштабировать код, а не только базу данных, которая является фактическим узким местом.Ну, ладно, в мире высоких нагрузок я вижу смысл.Но в остальном, разве мы не должны просто научиться управлять несколькими БД и несколькими схемами?


UPD: я думаю, мой вопрос не был достаточно ясным, поэтому я получил несколько классных повторов, которые неуточнить тему.Прежде всего, я понимаю, почему архитектура с высокой нагрузкой требует масштабирования бизнес-логики.Здесь я спрашиваю о проектах среднего уровня: как заставить их реагировать как можно быстрее.Микросервисы могут быть ответом, но никто не предполагает, что масштабирование кода - это всего лишь один вариант, и у моего проекта не будет миллионов активных пользователей ежедневно, тогда я просто смогу применить этот подход только для уровня БД - разделить его на наименьшие возможные логические схемы.и напишите BL соответственно.Разве не намного проще разрабатывать и поддерживать, так как в сагах, MQ и прочем нет необходимости?

Ответы [ 2 ]

0 голосов
/ 31 января 2019

Ознакомьтесь с 10 принципами работы микросервисов.Сначала вы можете начать улучшать базу данных, основываясь на своем уровне комфорта, и если у вас будет достаточно нагрузки, вы начнете видеть проблемы на стороне клиента и начнете оптимизировать услуги.

Вы можете оптимизировать сервисы различными способами, включая балансировку нагрузки, кэширование, формат ответа, REST / gRPC, сжатие и т. Д.

0 голосов
/ 29 января 2019

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

  1. Масштабирование приложения по горизонтали, например, для более высокой нагрузки / большего количества пользователей.Я думаю, что это то, что вы имели в виду с вашим вопросом.Предполагая, что мы говорим о действительно большом приложении с миллионами пользователей, где эта проблема становится наиболее распространенной, узких мест много, и постоянство - только одно из них.Теория распределенных систем, микросервисов, прикладных уровней без сохранения состояния и многих современных технологий решают эту проблему.Для баз данных это рост кластеризованных баз данных, для бизнес-логики это развертывание служб без сохранения состояния, а для инфраструктуры - рост облачных и виртуализированных аппаратных кластеров.Что касается вашего вопроса о базах данных, я бы порекомендовал рассмотреть компромиссы для масштабируемых баз данных no-sql, а также cockroachdb для кластерного, транзакционного и реляционного выбора.Эти варианты позволят вам обойти ограничения старой базы данных для одного сервера, которые, как представляется, подразумеваются предложением организовать несколько БД.

  2. Масштабировать размер организации / разработки, чтобы иметь возможность разрабатыватьбыстрее и добавить больше функций за более короткое время.Это обычно требуется и для успешного применения с миллионами активных пользователей.Таким образом, вам придется организовать команды разработчиков с сотнями или тысячами разработчиков.Здесь узким местом является количество необходимых координационных усилий.И поскольку во многих традиционных крупных организациях менеджмент среднего звена заинтересован в том, чтобы собрать как можно большую команду, много раз случалось, что формировались большие, неэффективные команды разработчиков, которые проводят большую часть своего времени, выстраивая свою работу, чтобы произвести позорнодорогое приложение в стиле монолита.Эта проблема обобщена в Законе Конвея .Таким образом, способ борьбы с этим для (как правило, более молодых) компаний заключается в переходе к очень плоской иерархии и к небольшим, независимым командам.Независимость является ключевым фактором здесь.Команды могут разрабатывать свое собственное видение (управление продуктом), выполнять свою собственную разработку, а также выпускать собственный продукт (модуль, сервис, приложение и т. Д.).

Затем, наконец,Приходите к исходному вопросу:

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

С пунктом 1 мы понимаем, что, в зависимости от количества одновременно активных пользователей и требуемого расчетаИз-за сложности проблемы домена нам, возможно, придется масштабировать бизнес-уровень приложения до десятков или сотен распределенных компьютеров, чтобы учесть количество одновременных сетевых подключений и достичь рабочей нагрузки (например, подумайте, что Netflix должен сделать для запуска своего сервиса).).

И, исходя из пункта 2, мы понимаем, что мы не можем совместно использовать базы данных между командами / службами, поскольку это помешало бы созданию независимых циклов разработки для них и съело бы ценную производительность благодаря усилиям по координации.1024 * Дополнительная причинаГоризонтальное масштабирование уровня бизнес-логики заключается в том, чтобы включить бесперебойное обслуживание (например, при сбое узла, будет другой, который будет принимать запросы) и разрешить обработку сложности за счет автоматизации задач (подход devops ).

Для получения дополнительной информации по этому вопросу я рекомендую прочитать статьи Мартина Фаулера в качестве отправной точки.

...