Масштабный куб — это технологическая модель, которая указывает три метода (или подхода), с помощью которых технологические платформы могут быть масштабированы для удовлетворения растущих уровней спроса на рассматриваемую систему. Три подхода, определенные моделью, включают масштабирование посредством репликации или клонирования («ось 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, как правило, представляет собой простую копию службы, которая затем балансируется по нагрузке, чтобы помочь справиться с всплесками трафика или сбоями в работе сервера. Затраты могут стать непосильными, особенно при работе с уровнем персистентности. [6]
Масштабирование по оси Y начинает отделять куски монолитной базы кода и создавать отдельные сервисы, а иногда и микросервисы. [12] Такое разделение создает четко определенные полосы не только для ответственности и подотчетности, но и для выявления неисправностей. Если одна служба выходит из строя, она должна отключить только себя, а не другие службы. [6] [13]
Масштабирование по оси Z обычно учитывает схожие варианты использования данных. Будь то географический характер или то, как клиенты используют ваш веб-сайт, или даже просто случайный модуль вашего набора данных о клиентах. Ось Z разбивает клиентов на изолированные разделы, чтобы сократить время отклика и помочь устранить проблемы в случае выхода из строя определенного региона или раздела. [6] [14]