Всем привет!
Я упоминал в посте про JMS vs Kafka про ESB - Enterprise Service Bus. Она же Корпоративная Сервисная Шина.
Какие плюсы и минусы данного решения?
Плюсов я вижу три:
1) унификация API в пределах компании
2) единая точка мониторинга и контроля всех интеграций
3) больше возможностей для переиспользования уже существующих API
Минусы такие:
1) т.к. ESB - это отдельная система, то ее разрабатывает как правило отдельная команда, которая быстро становится узким местом. Особенно при внедрении микросервисной архитектуры и резком увеличении числа интеграций
2) ESB как правило вносит дополнительные задержки, что особенно критично при синхронном взаимодействии
3) как правило ESB предлагают коммерческие компании, что приводит к vendor lock. Слезть с такого решения будет сложно
4) неочевидная штука - с одной стороны команда ESB унифицирует все API. Но с другой - API становятся перегруженными. Там будут какие-то стандартизированные для всех поля, общие базовые типы, которые во многих случаях будут избыточными
5) также ESB из-за стандартизации затрудняет развитие API. Т.к. унификация, а кроме того больше команд участвует в согласовании - три вместо двух
Вывод: на данном этапе развития ПО идея ESB выглядит избыточной.
Но что же с плюсами, как добиться того же результата с API точка-точка и микросервисной архитектурой?
1) унификация вещь полезная, главное чтобы она не была избыточной. Архитектор может выставить требования по API, DevOps - встроить их проверку в pipeline.
2) единая точка контроля - в случае облачной среды такой точкой может быть Istio или k8s. Либо ставить proxy на границах сред.
3) для переиспользования можно использовать каталог API. Да и не всегда переиспользование полезно, см. выше про избыточное API. Также отдельное API для каждого потребителя позволяет лучше контролировать доступ к данным
#api #esb
Я упоминал в посте про JMS vs Kafka про ESB - Enterprise Service Bus. Она же Корпоративная Сервисная Шина.
Какие плюсы и минусы данного решения?
Плюсов я вижу три:
1) унификация API в пределах компании
2) единая точка мониторинга и контроля всех интеграций
3) больше возможностей для переиспользования уже существующих API
Минусы такие:
1) т.к. ESB - это отдельная система, то ее разрабатывает как правило отдельная команда, которая быстро становится узким местом. Особенно при внедрении микросервисной архитектуры и резком увеличении числа интеграций
2) ESB как правило вносит дополнительные задержки, что особенно критично при синхронном взаимодействии
3) как правило ESB предлагают коммерческие компании, что приводит к vendor lock. Слезть с такого решения будет сложно
4) неочевидная штука - с одной стороны команда ESB унифицирует все API. Но с другой - API становятся перегруженными. Там будут какие-то стандартизированные для всех поля, общие базовые типы, которые во многих случаях будут избыточными
5) также ESB из-за стандартизации затрудняет развитие API. Т.к. унификация, а кроме того больше команд участвует в согласовании - три вместо двух
Вывод: на данном этапе развития ПО идея ESB выглядит избыточной.
Но что же с плюсами, как добиться того же результата с API точка-точка и микросервисной архитектурой?
1) унификация вещь полезная, главное чтобы она не была избыточной. Архитектор может выставить требования по API, DevOps - встроить их проверку в pipeline.
2) единая точка контроля - в случае облачной среды такой точкой может быть Istio или k8s. Либо ставить proxy на границах сред.
3) для переиспользования можно использовать каталог API. Да и не всегда переиспользование полезно, см. выше про избыточное API. Также отдельное API для каждого потребителя позволяет лучше контролировать доступ к данным
#api #esb
Highload прошел, но интересные доклады еще остались)
"AppHost: как Яндекс организует взаимодействие сотен микросервисов"
Честно - не ожидал такого хода от Яндекса.
В чем суть?
У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.
Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.
Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.
Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.
Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.
#arch #aac #saga #esb
"AppHost: как Яндекс организует взаимодействие сотен микросервисов"
Честно - не ожидал такого хода от Яндекса.
В чем суть?
У Яндекса микросервисная архитектура, большое количество микросервисов и жесткие требования по времени ответа пользователю. При этом очень сложно контролировать всю цепочку вызовов микросервисов по конкретной фиче, чтобы оптимизировать время ответа. Убрать лишние вызовы или найти самый долгий для его оптимизации. Один из вариантов решения проблемы есть в предыдущем моем посте (реверс-инжиниринг по трейсам), но ребят данный вариант не устроил из-за его не 100% точности.
Они тоже сделали граф вызовов для каждого бизнес-процесса. Но граф этот задается владельцем процесса явно в текстовом виде. Ремарка - как найти владельца для бизнес-процесса из десятка микросервисов - отдельный вопрос. Возвращаясь к сути, из того что я увидел: в конфигурации задаются сервисы - поставщики данных, их зависимости, таймауты, протоколы и схемы обмена данными. И это не просто часть аналитики, более того - как я понимаю в Яндексе нет требований по наличию аналитики. Это исполняемая спецификация: каждый запрос вначале попадает на новый микросервис - собственно AppHost из названия доклада - который загружает граф и выполняет его. Вызывая нужные микросервисы, предварительно проверяя необходимость и возможность его вызова. В итоге получаем топологию микросервисов в виде звезды, где AppHost в центре.
Сразу же возникает вопрос по надежности решения.
Ответы:
а) AppHost - stateless сервис, горизонтально масштабируемый, более того его инсталляции разделены по разным бизнес-доментам. Плюс есть всякие лайфхаки - например, при сбое по умолчанию пользовательский запрос отправляется на повторное выполнение, но при наличии специфических ошибок (ошибок, ломающих логику AppHost) повтор отключается
б) всегда есть критически важные сервисы, от которых зависят все или почти все остальные. Аутентификация, авторизация, прокси - как минимум. И ничего - они тоже дорабатываются, новые версии выкатываются. Здесь главное не сделать такой оркестратор слишком сложным.
Да, возвращаясь к принципу: все новое - это хорошо забытое старое. Во-первых это мне напоминает паттерн Сага в виде оркестратора. Во-вторых - старый недобрый ESB - Enterprise Service Bus - на новом витке развития. Напомню, его ключевое отличие от Kafka - брокер ESB содержит бизнес-логику и занимается маппингом данных, а брокер Kafka - в основном обеспечивает отказоустойчивость.
Ну и отдельно - вот принцип Architecture As Code в действии. Этап вливания конфигурации с графом сервисов - хорошая точка для контроля архитектуры. В целом идея мне нравится, ключевой момент тут - сознательное ограничение сложности оркестратора. Тогда получим увеличение надежности системы в целом. Но повторюсь - не ожидал, что эта идея возникнет у Яндекса.
#arch #aac #saga #esb