Укрощение Data-ориентированной сервисной сетки

Автор оригинала: Adam Miskiewicz
  • Перевод
Микросервисы — модная и распространённая сегодня архитектура. Но когда количество микросервисов разрастается до тысяч и десятков тысяч микросервисов, что делать со «спагетти» огромного графа зависимостей, как удобно изменять сервисы? Специально к старту нового потока курса «профессия Data Scientist» мы подготовили перевод материала, в котором рассказывается о Viaduct — ориентированной на данные сервисной сетке от Airbnb, по сути, повторяющей путь парадигм программирования — от процедурного до ориентированного на данные подхода. Подробности под катом.





22 октября мы представили Viaduct — то, что мы называем data-ориентированной сервисной сеткой. Она, как нам кажется, — шаг к улучшению модульности нашей сервисно-ориентированной архитектуры (SOA), основанной на микросервисах. Здесь мы расскажем о философии Viaduct и дадим приблизительный набросок её работы. Чтобы узнать о деталях, пожалуйста, посмотрите видеопрезентацию.

Большие графы зависимостей SOA


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



Это граф зависимостей в Airbnb, но такие графы не редкость. Amazon, Netflix и Uber — примеры компаний, работающих с похожими графами зависимостей.

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

Процедурный и Data-ориентированный дизайн


Организация больших программ в модульные блоки — не новая проблема в программной инженерии. Вплоть до 1970-х годов основная парадигма организации программного обеспечения сосредоточивалась на группировке кода в процедуры, а процедур — в модули. При таком подходе модули публикуют открытый API для использования другим кодом вне модуля; за этим открытым API модули скрывают внутренние вспомогательные процедуры и другие детали реализации. На этой парадигме основаны такие языки, как Pascal и C.

С 1980-х годов процедурная парадигма сместилась в сторону организацией программного обеспечения в первую очередь вокруг данных, а не процедур. В этом подходе модули определяют классы объектов, которые инкапсулируют внутреннее представление объекта, доступ к представлению осуществляется через открытый API методов объекта. Пионерами этой формы организации были Simula и Clu.

SOA — это шаг назад, к более процедурно-ориентированным конструкциям. Сегодняшний микросервис — это набор процедурных конечных точек — классический модуль в стиле 1970-х годов. Мы считаем, что SOA должна развиваться до поддержки ориентированного на данные дизайна и что эта эволюция может обеспечиваться путем перехода нашей сервисной сетки от процедурной ориентации к ориентации на данные.

Viaduct: Data-ориентированная сервисная-сетка


Центральное место в современных масштабируемых SOA-приложениях занимает сервисная сетка (например Istio, Linkerd), направляющая вызовы служб к экземплярам микросервисов, которые, в свою очередь, могут их обрабатывать. Сегодняшний отраслевой стандарт для сервисных сеток состоит в том, чтобы организовываться исключительно вокруг удаленных вызовов процедур, ничего не зная о данных. Наше видение в том, чтобы заменить эти процедурно-ориентированные сервисные сетки сервисными сетками, которые организованы вокруг данных.

В Airbnb GraphQL️ используется для построения ориентированной на данные сервисной сетки под названием Viaduct. Сетка обслуживания Viaduct определяется в терминах схемы GraphQL, состоящей из:

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

Типы (и интерфейсы) в схеме определяют единый граф для всех данных, управляемых в пределах сервисной сети. Например, в компании электронной коммерции схема сервисной сети может определять поле productById (id: ID), которое возвращает результаты типа Product. С этой отправной точки один запрос позволяет потребителю данных перейти к информации о производителе продукта, например productById {Manufacturer}, отзывах о продукте, например productById {reviews} и даже об авторах отзывов, например productById {reviews {author}}.

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

Размещение схемы в центре


Здесь мы обсудим, как в отличие от других распределенных систем GraphQL, таких как GraphQL Modules или Apollo Federation Viaduct рассматривает схему в качестве единого артефакта и реализует несколько примитивов, позволяющих нам поддерживать единую схему, в то же время позволяя многим командам продуктивно сотрудничать по этой схеме. По мере того как Viaduct заменяет все больше и больше наших базовых ориентированных на процедуры сервисных сетей, его схема все более и более полно фиксирует управляемые нашим приложением данные.

Мы воспользовались преимуществами этой «центральной схемы», как мы её называем, в качестве места для определения API-интерфейсов некоторых микросервисов. В частности, мы начали использовать GraphQL для API некоторых микросервисов. Схемы GraphQL этих сервисов определены как подмножество центральной схемы. В будущем мы хотим развить эту идею дальше, используя центральную схему для определения схемы данных, хранящихся в нашей базе данных.

Среди прочего использование центральной схемы для определения API-интерфейсов и схем баз данных решит одну из самых серьезных проблем крупномасштабных приложений SOA: подвижность данных. В современных приложениях SOA изменение схемы базы данных часто требует ручного отражения в API-интерфейсах двух, трёх, а иногда и более уровней микросервисов, прежде чем оно может быть представлено клиентскому коду. Такие изменения могут потребовать недель координации между несколькими командами. При получении сервисных API и схемы базы данных из единой центральной схемы подобное изменение схемы базы данных может быть передаваться клиентскому коду одним обновлением.

Приходим к бессерверности


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

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

Заключение


Viaduct построен на graphql-java и поддерживает детализированный выбор полей с помощью наборов выбора GraphQL. Viaduct использует современные методы загрузки данных, а также такие методы обеспечения надежности, как «короткое замыкание» и мягкие зависимости, реализует кэш внутри запроса. Viaduct обеспечивает наблюдаемость данных, позволяя нам понять вплоть до уровня полей, какие сервисы и какие данные потребляют. Будучи интерфейсом GraphQL, Viaduct позволяет использовать преимущества большой экосистемы инструментов с открытым исходным кодом, включая Live IDE, заглушки серверов и визуализаторы схем.

Viaduct начал поддерживать производственные процессы на Airbnb более года назад. Мы начали с нуля, с чистой схемы из нескольких сущностей и расширили её, включив 80 основных сущностей, которые могут работать с 75 % нашего современного трафика API.

image



Рекомендуемые статьи


SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Комментарии 0

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое