Русский
Русский
English
Статистика
Реклама

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

Микросервисы модная и распространённая сегодня архитектура. Но когда количество микросервисов разрастается до тысяч и десятков тысяч микросервисов, что делать со спагетти огромного графа зависимостей, как удобно изменять сервисы? Специально к старту нового потока курса профессия 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



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


Источник: habr.com
К списку статей
Опубликовано: 17.11.2020 18:17:45
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании skillfactory

Big data

Микросервисы

Data engineering

Skillfactory

Bigdata

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru