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

Одним из подходов, который обещает решить эти проблемы, является Space-Based архитектура, или SBA. Эта модель, также известная как «tuple space» или «shared nothing» архитектура, предлагает уникальный способ организации и управления данными и обработкой, который может масштабироваться практически без ограничений.

Определение Space-Based архитектуры


SBA — это подход к проектированию систем, который позволяет масштабироваться путем разделения данных и обработки на множество независимых единиц, которые можно распространять и обрабатывать параллельно. Этот подход также известен под названиями «tuple space» и «shared nothing» архитектура.

Корень идеи SBA уходит в 1980-е годы и связан с работой Дэвида Гелера, который предложил понятие «пространства кортежей» в своей диссертации. Основная идея состоит в том, что вместо того чтобы централизованно управлять данными и обработкой, мы распределяем их по «пространству», где каждая единица данных или обработки может независимо взаимодействовать с другими единицами.

Представьте, что у вас есть огромная толпа людей, которым нужно сделать какую-то работу. Вместо того чтобы ставить их всех в одну длинную очередь и обрабатывать по очереди, вы разбрасываете задачи по всей толпе, и каждый начинает работать над своей частью. Это и есть суть SBA — разделение работы на множество независимых частей и параллельная обработка этих частей.

Ключевые компоненты Space-Based архитектуры


Все мы знаем, что любая сложная система — это не что иное, как совокупность ее частей. И чтобы понять, как работает Space-Based архитектура, нужно разобраться в ее ключевых компонентах.

1. Процессинговые единицы


Процессинговые единицы — это сердце любой SBA системы. Они представляют собой независимые модули или «рабочие», которые могут выполнять определенные задачи обработки данных. Каждая процессинговая единица может работать независимо от других, что позволяет системе легко масштабироваться — просто добавьте больше процессинговых единиц, чтобы обрабатывать больше данных.

Процессинговые единицы могут быть распределены по различным физическим или виртуальным серверам, что позволяет SBA использовать ресурсы более эффективно и обеспечивает отказоустойчивость — если одна процессинговая единица выходит из строя, другие продолжают работать.

2. Пространства данных и виртуальные рабочие пространства


Пространства данных в SBA — это места, где хранятся данные для обработки. Они представляют собой распределенные хранилища, которые могут быть расположены на разных серверах и содержать разные части данных. Это обеспечивает высокую доступность данных и позволяет процессинговым единицам работать параллельно над различными данными.

Виртуальные рабочие пространства — это места, где процессинговые единицы обрабатывают данные. Они представляют собой независимые «рабочие станции», где каждая процессинговая единица может обрабатывать данные без взаимодействия с другими. Это обеспечивает изоляцию и параллелизм обработки.

3. Роутеры и управление транзакциями


Роутеры в SBA играют ключевую роль в управлении потоком данных. Они определяют, какие данные должны быть отправлены в какую процессинговую единицу для обработки и затем возвращают обработанные данные обратно в пространства данных. Роутеры также могут обрабатывать ошибки и обеспечивать перенаправление данных в случае отказа процессинговой единицы.

Управление транзакциями в SBA гарантирует, что все обработка данных происходит в согласованном и надежном порядке. Это важно для обеспечения целостности данных, особенно в системах, где данные обрабатываются параллельно и независимо друг от друга. Управление транзакциями в SBA может включать механизмы для контроля состояния транзакций, обработки ошибок и восстановления после сбоев.

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

Принципы работы Space-Based архитектуры


1. Освобождение от «узких мест»


Суть любой задачи разработки — как можно эффективнее использовать имеющиеся ресурсы. В традиционных архитектурах часто возникают «узкие места», которые замедляют обработку данных. Например, если у вас есть центральный сервер, который обрабатывает все запросы, он может стать «узким местом», поскольку все запросы должны проходить через него.

SBA решает эту проблему за счет использования процессинговых единиц — отдельных модулей, способных работать параллельно. Это можно сравнить с работой в крупной компании: вместо того, чтобы все задачи выполнялись одним сотрудником, они распределяются между многими сотрудниками, что позволяет работать более эффективно.

2. Распределенная обработка данных


В SBA данные хранятся в так называемых «пространствах данных», которые распределены по всей системе. Это означает, что данные не связаны с конкретной процессинговой единицей, и даже если одна или несколько единиц выйдут из строя, данные останутся доступными.

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

3. Масштабирование в SBA


Масштабирование в SBA осуществляется за счет добавления новых процессинговых единиц. Это как если бы вы нанимали больше сотрудников в свою компанию, когда объем работы увеличивается.

Допустим, у вас есть веб-сервис, который становится все более популярным. Когда количество пользователей увеличивается, вы можете просто добавить больше процессинговых единиц, чтобы справиться с увеличивающейся нагрузкой. И это не только теоретический пример — так работают многие крупные интернет-компании, такие как Amazon и Google.

4. Параллелизм и распределенная обработка


SBA полагается на принципы параллелизма и распределенной обработки. Каждая процессинговая единица работает независимо и параллельно, обрабатывая свои данные. Это как если бы в вашей компании каждый отдел работал над своей задачей одновременно с другими отделами, вместо того, чтобы вместо того, чтобы все задачи выполнялись последовательно.

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

Преимущества и недостатки


Однако, как и любая другая архитектура, она имеет свои преимущества и недостатки. Давайте рассмотрим их подробнее.

Преимущества Space-Based архитектуры:

1. Масштабируемость.

Одним из главных преимуществ SBA является ее способность масштабироваться. Вместо того чтобы полагаться на один большой сервер для обработки всех запросов, SBA распределяет нагрузку по множеству независимых единиц обработки (называемых «пространствами»). Это означает, что когда количество пользователей или объем данных увеличивается, можно просто добавить больше пространств для обработки новых запросов, что позволяет системе легко масштабироваться.

2. Отказоустойчивость.

Второе важное преимущество SBA — это ее отказоустойчивость. Если одна из единиц обработки выходит из строя, запросы, которые она обрабатывала, могут быть перенаправлены на другие единицы. Это обеспечивает бесперебойную работу системы даже в случае отказа одной или нескольких ее частей.

3. Гибкость.

SBA также обладает высокой гибкостью, так как позволяет легко вносить изменения в систему. Можно добавлять, удалять или модифицировать отдельные пространства без необходимости перезагружать всю систему, что делает SBA идеальным выбором для динамично меняющихся технологических сред.

Недостатки Space-Based архитектуры:

1. Сложность реализации.

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

2. Трудности с согласованностью данных.

Еще одним недостатком являются трудности с согласованностью данных. В распределенной системе, какой является SBA, обеспечение согласованности данных между различными единицами обработки может быть сложной задачей. Это может привести к появлению конфликтов в данных и заставить разработчиков тратить дополнительное время на разрешение этих проблем.

Пример использования


Давайте рассмотрим простой пример кода, который демонстрирует принципы SBA. В этом примере мы создадим простую систему обработки изображений, которая состоит из трех частей: загрузчика изображений, обработчика изображений и сохраняющего изображения.

import multiprocessing as mp
import cv2  # OpenCV для обработки изображений
import os

def image_loader(queue):
    for filename in os.listdir('images'):
        image = cv2.imread(os.path.join('images', filename))
        queue.put((filename, image))

def image_processor(input_queue, output_queue):
    while True:
        filename, image = input_queue.get()
        if image is None:
            break
        # Простой пример обработки - преобразование в оттенки серого
        gray_image = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
        output_queue.put((filename, gray_image))

def image_saver(queue):
    while True:
        filename, image = queue.get()
        if image is None:
            break
        cv2.imwrite(os.path.join('processed_images', filename), image)

if __name__ == '__main__':
    loader_queue = mp.Queue()
    saver_queue = mp.Queue()
    
    loader = mp.Process(target=image_loader, args=(loader_queue,))
    processor = mp.Process(target=image_processor, args=(loader_queue, saver_queue,))
    saver = mp.Process(target=image_saver, args=(saver_queue,))
    
    loader.start()
    processor.start()
    saver.start()
    
    loader.join()
    processor.join()
    saver.join()

В этом коде каждая функция выполняется в отдельном процессе и общается с другими процессами через очереди. Это позволяет упростить обработку данных, поскольку каждый процесс может работать независимо от других.

Заключение


В заключение, Space-Based архитектура (SBA) представляет собой мощный подход к проектированию систем, который обеспечивает высокую производительность, масштабируемость и устойчивость к отказам. Ее ключевые принципы, такие как распределенная обработка данных, параллелизм и освобождение от «узких мест», делают ее идеально подходящей для обработки больших объемов данных и обслуживания большого количества пользователей.

Данный материал подготовлен в преддверии старта курса Enterprise Architector. Узнать подробнее о курсе и зарегистрироваться на бесплатный вебинар вы можете по этой ссылке.

Комментарии (3)


  1. RemiZOffAlex
    19.07.2023 15:34
    +1

    Событийно-ориентированная архитектура (event-driven architecture, EDA) под новым соусом названием


    1. GraDea
      19.07.2023 15:34
      +2

      SBA совсем про другое, в статье не очень раскрыта тема, как мне показалось.


  1. khmheh
    19.07.2023 15:34
    +2

    Текста написано много, но он будто обо всем и ни о чем. Сразу к примеру перейдем. Итак, в примере операция, которая будто и не требует декомпозиции, декомпозирована на три составляющие. Это, вроде как, должно помочь нам избавиться от узкого горлышка, как пишут в преимуществах.

    Давайте подумаем, что произойдет. Первая часть системы быстро (относительно) прочитает все файлы и забьет очередь картинками, которые будут без дела пылиться в оперативной памяти компьютера и ждать своей очереди. Затем по одному их прочитает обработчик, и, сразу по завершении обработки, сейвер их сохранит. Это в общем-то частая проблема, когда приходится обрабатывать видеопоток или что-то подобное, обработка как правило занимает времени больше, чем чтение, поэтому обработать поток видео покадрово - тяжелая для вычислительной машины задача, добавляют балансировщики, которые подают на обработку только ценные кадры. То есть, не очень понятно, а зачем читать условные 100 картинок сразу в оперативную память, если можно их читать по одной?

    Возможно, подразумевается, что данный паттерн будет реализован в рамках серверного приложения. То есть, 100 пользователей загрузили свои 100 картинок, и сотый идет в курилку, на обед, играет в теннис, подтягивается на турнике, пока его картинка дождется своей очереди? Понятное дело, что если там нейросети, то без очереди не обойтись. Но если нет инференса тяжелой модели, а просто алгоритмическая часть, как в примере, то почему бы эти сто операций обработки не распараллелить хотя бы на, скажем, три-четыре потока?

    Итак, написав прошлые три абзаца, я пришел вот к чему. Нам нужно разделить операцию загрузки картинок (или любых других данных) в ОЗУ (или сначала в какое-нибудь хранилище, а при надобности - из него в ОЗУ) от операции обработки этих картинок (данных), а по завершении обработки пользователю показывался либо результат, либо какое-то сообщение, что все, мол, ок. Причем, это решение должно масштабироваться, а отдельные компоненты должны не зависеть друг от друга, не считая интерфейса взаимодействия между этими компонентами.

    Разве это не микросервисы? Окей, тут важен порядок, в отличие от event-driven (если я правильно понял текст из википедии), но что это в корне меняет? Либо в статье что-то не так изложено, либо тут действительно чего-то принципиально нового и не написано...