Привет, Хабр!
Клеточная архитектура — это подход к проектированию систем, основанный на принципе изоляции и независимости компонентов. Такая модель позволяет разделить большие и сложные системы на меньшие, самостоятельно функционирующие модули или клетки. Каждая клетка представляет собой законченный функциональный блок с собственным набором ресурсов и зависимостей.
Основная цель такого разделения — минимизация радиуса поражения при возникновении сбоев и упрощение масштабирования системы.
Но вы наверное спросите: - А в чем же отличии от микросервисной архитектуры?
Клеточная архитектура и архитектура микросервисов действительно имеют много общего, так как обе направлены на разделение больших и сложных систем на более мелкие, управляемые компоненты. Однако есть ключевые отличия:
Уровень изоляции:
Микросервисы разделяют приложение на независимые сервисы, каждый из которых выполняет определённую функцию или бизнес-логику. Эти сервисы могут общаться друг с другом через определённые API.
Клеточная архитектура уходит дальше, предлагая не только разделение по функциональности, но и по изоляции сред выполнения. Каждая клетка может содержать один или несколько микросервисов, но при этом они изолированы от других клеток в плане ресурсов, зависимостей и сетевых вызовов.
Обработка сбоев:
В микросервисной архитектуре каждый сервис может независимо масштабироваться и обновляться, что как-то хоть и повышает гибкость системы, но при этом сбой в одном сервисе может повлиять на другие сервисы через сетевые вызовы.
Клеточная архитектура стремится минимизировать этот эффект, закладывая ещё более строгую изоляцию, так что сбои в одной клетке не влияют на работу других клеток. Это достигается за счёт использования отдельных сред выполнения и данных для каждой клетки.
Масштабируемость:
Микросервисы предлагают масштабирование путём добавления экземпляров сервиса в зависимости от нагрузки.
Клеточные архитектуры используют аналогичный подход к масштабированию, но масштабирование может быть более гранулированным, так как каждая клетка может включать в себя все необходимые сервисы и данные для обслуживания определенного сегмента юзеров или задач.
Основные компоненты клеточной архитектуры
Маршрутизатор клеток: является центральным элементом, который управляет маршрутизацией запросов к соответствующим клеткам на основе ключа разделения. Этот ключ обычно связан с определенными атрибутами запроса, типа ID пользователя или ресурса. Маршрутизатор клеток должен быть максимально оптимизирован и иметь минимальную задержку, поскольку он обрабатывает все входящие запросы и направляет их в соответствующие клетки.
Клетка: каждая клетка — это автономный модуль, который содержит все необходимые ресурсы и компоненты для обработки части общей нагрузки системы. Клетки проектируются таким образом, чтобы быть самодостаточными и независимыми, что позволяет изолировать сбои в пределах одной клетки, не затрагивая работу других клеток.
Плоскость управления: отвечает за админ задачи, такие как развертывание новых клеток, их удаление и миграция клиентов между клетками.
Где реализовали клеточную архитектуру
Slack
Slack внедрил клеточную архитектуру для решения проблем с серыми отказами, когда разные компоненты системы имеют разное представление о доступности друг друга. Основной проблемой было то, что сбой в одной зоне доступности мог негативно сказаться на работе всей системы.
Основной элемент в реализации Slack - это дренажные механизмы, которые позволяют быстро перенаправлять трафик из одной зоны доступности в другую. Это достигается благодаря модели, в которой каждая зона доступности рассматривается как отдельная клетка, которая может быть независимо изалирована от трафика в случае необходимости.
Система Slack построена так, что каждый сервис внутри AZ функционирует изолированно, обрабатывая только трафик внутри своей зоны. Это достигается за счёт применения различных сервисов обнаружения служб, таких как Envoy и Consul, которые поддерживают механизмы динамического управления трафиком и конфигураций.
Также Slack интегрирвла клеточную архитектуру с облачной инфраструктурой AWS, что позволило использовать возможности автоматического масштабирования и управления ресурсами на уровне облака, оптимизируя таким образом производительность и доступность сервисов. Это подчеркивает важность тесной интеграции клеточной архитектуры с облачными платформами для достижения наилучших результатов в управлении распределёнными системами.
Okta
Клеточная архитектура в Okta реализована как основной элемент их масштабируемой инфраструктуры. Такая архитектура состоит из отдельных клеток, каждая из которых является изолированным, автономным репликатом инфраструктуры, что позволяет минимизировать воздействие сбоев в одной клетке на всю систему. Okta строит свои клетки таким образом, чтобы они могли быть размещены в разных географических регионах, что улучшает доступность и надежность сервисов на глобальном уровне.
Основная фича клеточной архитектуры Okta заключается в её способности к горизонтальному масштабированию с использованием таких инструментов, как Elasticsearch, Kinesis, ProxySQL, Redis и Storm, что позволяет линейно увеличивать количество клеток в зависимости от потребностей клиентов. Каждая клетка Okta предназначена для работы с определенным объемом трафика, и при ее насыщении система автоматически масштабируется, добавляя новые клетки.
Для управления выпуском обновлений и изменений Okta использует инструменты, моделирующие release trains, которые позволяют обновлять и масштабировать клетки без необходимости ручного вмешательства. Это обеспечивает единообразие развертывания артефактов во всех средах и позволяет параллельно выпускать апдейты с возможностью отката в случае сбоев.
Door dash
Основная цель DoorDash в переходе на клеточную архитектуру заключалась в уменьшении расходов на трансфер данных между различными зонами доступности при использовании микросервисов. Традиционная архитектура с балансировкой нагрузки типа round-robin приводила к значительным затратам из-за трафика, пересекающего границы AZ.
DoorDash реализовала зонное маршрутизирование с помощью сервисного меша на базе Envoy, что позволило управлять трафиком в пределах одной зоны доступности, минимизируя более дорогой межзональный трафик. Для этого был модифицирован собственный сервисный меш компании, который предоставлял Envoy информацию о зоне для каждого узла.
Пример конфигурации для Envoy:
resources:
- "@type": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment
cluster_name: payment-service.service.prod.ddsd
endpoints:
- locality:
zone: us-west-2a
lb_endpoints:
- endpoint:
address:
socket_address:
address: 1.1.1.1
port_value: 80
- locality:
zone: us-west-2b
lb_endpoints:
- endpoint:
address:
socket_address:
address: 2.2.2.2
port_value: 80
- locality:
zone: us-west-2c
lb_endpoints:
- endpoint:
address:
socket_address:
address: 3.3.3.3
port_value: 80Каждая клетка в клеточной архитектуре функционирует как независимый модуль с собственным набором сервисов и хранилищ. Это приводит к повышенной сложности маршрутизации и координации между клетками. Нужно обеспечить, чтобы системы могли масштабироваться и управляться без значительного увеличения задержек или сложности коммуникаций.
Решение этой проблемы часто решается использованием централизованных дашбордов и мониторинга, к примеру как это реализовано в Amazon CloudWatch, что позволяет следить за состоянием всех клеток в реальном времени и быстро реагировать на любые проблемы.
Помимо этого, каждая клетка должна иметь четко определенные политики безопасности и управления данными. Для этого можно реализовать автоматизацию и обновление клеток через AWS Step Functions и AWS CodeDeploy.
Больше практических навыков по архитектуре приложений вы можете получить в рамках практических онлайн-курсов от экспертов отрасли.