Как Airbnb масштабируется, отходя от монолита

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

На прошлой неделе я писал о как Google пишет чистый, удобный в сопровождении код.

Airbnb начинался как простой монолит Ruby on Rails в 2008 году.

В 2018 году Airbnb начал переход на сервис-ориентированную архитектуру, поскольку «монорельс» Ruby on Rails стал трудно обслуживать и стал единственной точкой отказа.

Основное различие между SOA и микросервисами связано с областью архитектуры.

В модели SOA сервисы или модули являются общими и повторно используются в масштабе всего предприятия, тогда как архитектура микросервисов построена на отдельных сервисах, которые функционируют независимо. (Источник)

Хотя Airbnb не обязательно переходить на SOA, они решили это сделать, поскольку это имело смысл для их организационных нужд.

В недавнем разговор 2023 годаони изложили четыре урока:

• Инвестируйте в общую инфраструктуру заранее

• Упрощение зависимостей служб

• Централизовать гидратацию данных (извлечение и преобразование)

• Отделите логику пользовательского интерфейса от внутренней логики.

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

Airbnb создал общую инфраструктуру, которой пользуются команды разных сервисов.

1. Собственная платформа API, построенная на Apache. Бережливость

   1. Разрешено всем сервисам Airbnb определять чистые API и взаимодействовать друг с другом.

   2. Платформа обеспечивала межсервисное взаимодействие, распространение ошибок, метрики наблюдаемости и проверку схемы.

   3. Инженеры могли сосредоточиться на реализации основной бизнес-логики.

   4. Facebook/Meta использует настроенную внутреннюю версию Apache Thrift под названием fbthrift, исходный код которой открыт.

   5. Google, Netflix, Square и другие компании используют gRPC.

2. Энергосистема: Собственная библиотека для параллельного выполнения задач.

   1. Помог организовать код в направленный ациклический граф (DAG), позволяющий выполнять задачи одновременно.

   2. Полезно для таких задач, как проверка и агрегирование данных.

3. Одно касание: Платформа, построенная на Kubernetes для управления сервисами и их эффективного развертывания.

   1. Обеспечено, чтобы все конфигурации сервисов управлялись в одном месте.

   2. Предоставлен инструмент командной строки для развертывания служб в различных средах.

   3. Google использует Borg в качестве менеджера кластера. Это был предшественник Kubernetes. Google и Google Cloud работает на Borg.

   4. Facebook/Meta использует Twine для управления кластером.

4. Спинакер: Платформа непрерывной доставки с открытым исходным кодом, которая обеспечивает безопасные и повторяемые рабочие процессы для развертывания изменений в рабочей среде.

   1. Добавлен автоматический канареечный анализ для обеспечения плавного развертывания в большом масштабе.

   2. Автоматический канареечный анализ позволяет частично внедрить изменение, а затем сравнить его с текущим развертыванием, чтобы оценить его производительность.

   3. Спинакер был создан на Netflix.

   4. Uber фантастически рассказывает о безопасное и быстрое развертывание в масштабе планеты.

Инвестируя в эту общую инфраструктуру, Airbnb смогла ускорить переход на SOA и воспользоваться преимуществами более высокой надежности и гибкости бизнеса.

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

Служба более высокого уровня может вызывать службу более низкого уровня, но не наоборот. Чтобы реализовать эту многоуровневую архитектуру, основанную на топологии, Airbnb представила сервисные блоки на уровне платформыкаждый из которых содержит связанные бизнес-функции.

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

Гидратация данных это процесс импорта данных в объект.

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

Чтобы упростить этот процесс и избежать дублирования (что в больших масштабах обходится дорого!), Airbnb ввела уровень централизованного доступа к данным. Этот уровень предоставил консолидированную схему GraphQL, которая объединила различные объекты, такие как списки, пользователи и бронирования, из различных источников данных.

Централизуя логику извлечения и гидратации данных, инженеры могли сосредоточиться на инновациях в продуктах, а не писать один и тот же код гидратации повторно.

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

Чтобы обеспечить единообразие пользовательского опыта и оптимизировать разработку, Airbnb представила App Framework, унифицированная система пользовательского интерфейса, управляемая службами.. Эта структура позволила Airbnb предоставить клиентам стандартизированный API и не позволила инженерам постоянно изобретать велосипед с использованием собственных API.

Бэкэнд управлял содержимым и стилем пользовательского интерфейса в каждом разделе отображаемой страницы внешнего интерфейса. Интерфейс в основном отвечал за рендеринг каждого раздела.

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

Данные пользовательского интерфейса были отправлены из серверной части.

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

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

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

• Делайте шаг только тогда, когда вам нужно. Airbnb прекрасно работал на одном монолите Rails в течение десяти лет! Они перешли на SOA только после того, как продолжать разработку монолита стало очень болезненно.

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

Поделиться Кодексом инженера