Масштабный куб
Масштабный куб — это технологическая модель, которая указывает три метода (или подхода), с помощью которых технологические платформы могут быть масштабированы для удовлетворения растущих уровней спроса на рассматриваемую систему. Три подхода, определенные моделью, включают масштабирование посредством репликации или клонирования («ось X»), масштабирование посредством сегментации по границам услуг или разнородным компонентам («ось Y») и сегментацию или разделение по схожим компонентам («ось Z» ). [1] [2] [3] [4] [5] [6]
История
[ редактировать ]Модель впервые была опубликована в книге в первом издании The Art of Scalability . [7] Авторы утверждают, что впервые опубликовали модель в Интернете в 2007 году в блоге своей компании. [6] Последующие версии модели были опубликованы в первом издании « Правил масштабируемости» в 2011 году. [8] второе издание «Искусства масштабируемости» в 2015 году. [1] [4] и второе издание Правил масштабируемости в 2016 году. [9]
Обзор модели
[ редактировать ]Ось X модели описывает масштабирование технологического решения за счет нескольких экземпляров одного и того же компонента посредством клонирования сервиса или репликации набора данных. Веб-серверы и серверы приложений, выполняющие одну и ту же функцию, могут существовать за балансировщиком нагрузки для масштабирования решения. Системы сохранения данных, такие как базы данных, могут быть реплицированы для повышения пропускной способности транзакций. [1] Ось Y модели описывает масштабирование технологического решения путем разделения монолитного приложения на сервисы с помощью слов действия (глаголов) или разделения «непохожих» вещей. Данные могут быть разделены существительными. Службы должны иметь данные, с которыми они работают, отделенные и изолированные от этой службы. [1] [10] Ось Z куба описывает масштабирование технологического решения путем разделения компонентов по «похожим» границам. Такое разделение может осуществляться по географическому признаку, по идентификационным номерам клиентов и т. д. [1] [11]
ось X
[ редактировать ]Масштабирование по оси X является наиболее часто используемым подходом, и его, как правило, проще всего реализовать. Хотя это потенциально дорого, скорость, с которой это может быть реализовано и начать решать проблемы, как правило, компенсирует затраты. Ось X, как правило, представляет собой простую копию службы, которая затем балансируется по нагрузке, чтобы помочь справиться с всплесками трафика или сбоями в работе сервера. Затраты могут стать непосильными, особенно при работе с уровнем персистентности. [6]
Плюсы масштабирования по оси X
[ редактировать ]- Интеллектуально легко
- Хорошо масштабирует транзакции
- Быстрая реализация
Минусы масштабирования по оси X
[ редактировать ]- Стоимость (несколько копий базы данных)
- Не затрагивает кэширование
- Не учитывает организационный масштаб
ось Y
[ редактировать ]Масштабирование по оси Y начинает отделять куски монолитной кодовой базы и создавать отдельные сервисы, а иногда и микросервисы. [12] Такое разделение создает четко определенные полосы не только для ответственности и подотчетности, но и для локализации неисправностей. Если одна служба выходит из строя, она должна отключить только себя, а не другие службы. [6] [13]
Плюсы масштабирования по оси Y
[ редактировать ]- Позволяет масштабировать организацию
- Хорошо масштабирует транзакции
- Локализация отказов
- Увеличивает скорость попадания в кэш
Минусы масштабирования по оси Y
[ редактировать ]- Интеллектуально сложно
- Требуется время для реализации
ось Z
[ редактировать ]Масштабирование по оси Z обычно учитывает схожие варианты использования данных. Будь то географический характер или то, как клиенты используют ваш веб-сайт, или даже просто случайный модуль вашего набора данных о клиентах. Ось Z разбивает клиентов на изолированные разделы, чтобы сократить время отклика и помочь устранить проблемы в случае выхода из строя определенного региона или раздела. [6] [14]
Плюсы масштабирования по оси Z
[ редактировать ]- Интеллектуально легко
- Хорошо масштабирует транзакции
- Может обеспечить изоляцию неисправностей
- Может улучшить время отклика
Минусы масштабирования по оси Z
[ редактировать ]- Требуется время для реализации
- Не учитывает организационный масштаб
- Требуется повышенная автоматизация для снижения накладных расходов на системы.
Ссылки
[ редактировать ]- ^ Jump up to: а б с д и Эбботт, Мартин; Фишер, Майкл (13 июня 2015 г.). Искусство масштабируемости: масштабируемая веб-архитектура, процессы и организации для современного предприятия (второе изд.). Аддисон-Уэсли. п. 2. ISBN 978-0134032801 .
- ^ «Приложения для масштабирования: масштабный куб» . Компьютерщик-рассказчик .
- ^ «Архитектурный куб» . Фокус на выгоде .
- ^ Jump up to: а б «Масштабный куб» . Линда .
- ^ «Масштабный куб» . AgileDev .
- ^ Jump up to: а б с д и «Масштабный куб» . Партнеры АКФ .
- ^ Эбботт, Мартин; Фишер, Майкл (15 декабря 2009 г.). Искусство масштабируемости: масштабируемая веб-архитектура, процессы и организации для современного предприятия (первое издание). Аддисон-Уэсли. ISBN 978-0137030422 . 15 декабря 2009 г.
- ^ Эбботт, Мартин; Фишер, Майкл (4 мая 2011 г.). Правила масштабируемости: принципы масштабирования веб-сайтов (первое издание). Аддисон-Уэсли. ISBN 978-0321753885 .
- ^ Эбботт, Мартин; Фишер, Майкл (9 сентября 2016 г.). Правила масштабируемости: принципы масштабирования веб-сайтов (второе изд.). Раздел признательности: Аддисон-Уэсли. ISBN 978-0134431604 .
- ^ «От монолитов к микросервисам: архитектурная стратегия» . Новый стек . 4 февраля 2016 г.
- ^ «Масштабирование по оси Z» . Шекхар Гулати . 9 января 2019 г.
- ^ «Что такое микросервисы?» . Партнеры АКФ .
- ^ «Архитектурные принципы: изоляция разломов и дорожки для плавания» . Партнеры АКФ .
- ^ «Масштабный куб AKF: корпус Ze для оси Z» . Партнеры АКФ .