Куб масштабирования — это технологическая модель, которая указывает три метода (или подхода), с помощью которых технологические платформы могут масштабироваться для удовлетворения растущих уровней спроса на рассматриваемую систему. Три подхода, определяемые моделью, включают масштабирование посредством репликации или клонирования («ось X»), масштабирование посредством сегментации по границам сервисов или разнородным компонентам («ось Y») и сегментацию или разбиение по схожим компонентам («ось Z»). [1] [2] [3] [4] [5] [6]
Модель была впервые опубликована в книге в первом издании The Art of Scalability . [7] Авторы заявляют, что первая публикация модели в Интернете состоялась в 2007 году в блоге их компании. [6] Последующие версии модели были опубликованы в первом издании Scalability Rules в 2011 году, [8] во втором издании The Art of Scalability в 2015 году [1] [4] и во втором издании Scalability Rules в 2016 году. [9]
Ось X модели описывает масштабирование технологического решения посредством нескольких экземпляров одного и того же компонента посредством клонирования сервиса или репликации набора данных. Веб-серверы и серверы приложений, выполняющие одну и ту же функцию, могут существовать за балансировщиком нагрузки для масштабирования решения. Системы сохранения данных, такие как база данных, могут быть реплицированы для более высокой пропускной способности транзакций. [1] Ось Y модели описывает масштабирование технологического решения путем разделения монолитного приложения на сервисы с использованием слов действия (глаголов) или разделения «разнородных» вещей. Данные могут быть разделены существительными. Сервисы должны иметь данные, на основе которых они действуют, отделенными и изолированными от этого сервиса. [1] [10] Ось Z куба описывает масштабирование технологического решения путем разделения компонентов по «похожим» границам. Такое разделение может быть сделано на географической основе, по номерам идентификаторов клиентов и т. д. [1] [11]
Масштабирование по оси X является наиболее часто используемым подходом и, как правило, самым простым в реализации. Хотя это потенциально затратно, скорость, с которой его можно реализовать и начать устранять проблемы, как правило, компенсирует стоимость. Ось X, как правило, является простой копией сервиса, которая затем балансируется по нагрузке, чтобы либо помочь с пиками трафика, либо сбоями сервера. Расходы могут начать становиться непомерными, особенно при работе с уровнем устойчивости. [6]
Масштабирование по оси Y начинает откалывать куски монолитных кодовых баз и создавать отдельные сервисы или иногда микросервисы. [12] Это разделение создает четко определенные полосы не только для ответственности и подотчетности, но и для изоляции сбоев. Если один сервис выходит из строя, он должен вывести из строя только себя, а не другие сервисы. [6] [13]
Масштабирование оси Z обычно рассматривает схожие варианты использования данных. Будь то география по своей природе или то, как клиенты используют ваш веб-сайт, или даже просто случайный модуль вашего набора данных клиентов. Ось Z разбивает клиентов на изолированные разделы, чтобы выиграть время отклика и помочь устранить проблемы, если определенный регион или раздел должен выйти из строя. [6] [14]