Глянул тут на картинку ф-ти API Gateway сервиса
и возник вопрос -- а с тз SRP это нормально иметь такой объем
функциональности в одном процессе(точнее, в адресном пространстве)? Ну как минимум rate limit можно еще до организовать. Или это нормально?
Здравствуйте, Sharov, Вы писали:
S>возник вопрос -- а с тз SRP это нормально иметь такой объем S>функциональности в одном процессе(точнее, в адресном пространстве)? Ну как минимум rate limit можно еще до организовать. Или это нормально?
Нормально.
SRP это про классы. Если в указанной схеме каждый квадратик будет отдельным классом, то как раз все ок с точки зрения SRP.
Здравствуйте, gandjustas, Вы писали:
G>Нормально. G>SRP это про классы. Если в указанной схеме каждый квадратик будет отдельным классом, то как раз все ок с точки зрения SRP.
Ну тот же rate limit можно отдельно сделать, все-таки каждый квадратик это latency. С др. стороны да, раз
latency критично и неизбежно, то имеет смысл держать все поближе, в одном адресном пространстве.
Здравствуйте, Doom100500, Вы писали:
S>>.... ф-ти .... а с тз ... D>Дикий оффтоп, но пригорело... D>Ты что буквы экономишь, или Владу место на дорогом SSD? Ну нафига эти ребусы?
Здравствуйте, Sharov, Вы писали:
S>Глянул тут на картинку ф-ти API Gateway сервиса S>и возник вопрос -- а с тз SRP это нормально иметь такой объем S>функциональности в одном процессе(точнее, в адресном пространстве)? Ну как минимум rate limit можно еще до организовать. Или это нормально?
Во-первых, SRP даже к микросервисам довольно аккуратно применять надо, под довольно дорогой ресурс, особо раскидываться ими не стоит. А конкретно AGW это вообще не микросервис, его не прикладная команда пишет, так что толку делать его микросервисом немного. Наконец, AGW связан с ингрессом, и городит под ингрессом несколько сервисов или несколько ингрессов сажать на один домен — ну то такое.
Во-вторых схемка та отличается определенной степенью бредовости. Parameter validation это вообще какой то бред либо я не понял что автор имел в виду. Allow/Deny lists это часть Authorization, которая в квадратике рядом. Rate limit обычно не в AGW реализуют, оно для разных микросервисов и даже разных урлов одного микросервиса как правило разное. Но ок, в ряде ситуаций можно и в AGW засунуть при условии того что это настраивается индивидуально. Service Discovery совершенно отдельная задачка, ей занимается либо оркестратор, либо специализированный внутренний сервис типа Consul, пихать это в AGW какой то злобный велосипедизм. На кой черт это тащить в торчащий наружу AGW понять сложно. Красные квадратики это тоже не задача AGW, и эти задачи надо решать не только при внешних запросах, но и при коммуникации между внутренними сервисами. И на то есть отдельные готовые решения типа istio.
Итого: задачи AGW это аутентификация, авторизация (и это совсем разные задачи, как правило совершенно независимые, а на схеме запихнули в один квадрат), роутинг до downstream сервиса, ну и иногда логично что там же protocol conversion. Все остальное, если мы типовой AGW рисуем, лишнее.
Да, еще один момент с аутентификацией. Надо понимать что в AGW только часть аутентификации, как правило он только проверяет подпись в токене и подгружает ключи из IdP. А собственно аутентификацией занимается IdP, это отдельная очень объемная задача.
Здравствуйте, gandjustas, Вы писали:
G>SRP это про классы. Если в указанной схеме каждый квадратик будет отдельным классом, то как раз все ок с точки зрения SRP.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Во-вторых схемка та отличается определенной степенью бредовости. Parameter validation это вообще какой то бред либо я не понял что автор имел в виду.
Первичная валидация данных. Дорого ходить в бизнес-логику с различным невалидным уг.
НС>Итого: задачи AGW это аутентификация, авторизация (и это совсем разные задачи, как правило совершенно независимые, а на схеме запихнули в один квадрат), роутинг до downstream сервиса, ну и иногда логично что там же protocol conversion. Все остальное, если мы типовой AGW рисуем, лишнее.
Аутентификация и авторизация тоже отдельно обычно висят — обычно сайд-кар для идентити и какой-нибудь абак/рбак. Зачем пихать все это в фасадный сервис — хз.
Здравствуйте, IncremenTop, Вы писали:
НС>>Во-вторых схемка та отличается определенной степенью бредовости. Parameter validation это вообще какой то бред либо я не понял что автор имел в виду. IT>Первичная валидация данных.
И откуда AGW знать бизнес-логику валидации?
IT>Аутентификация и авторизация тоже отдельно обычно висят — обычно сайд-кар для идентити и какой-нибудь абак/рбак.
рбак должен как раз AGW реализовывать, пусть даже непосредственно вычисление правил выполняется сайдкаром с каким нибудь OPA. Без этого AGW не будет выполнять свою функцию основную. А аутентификация тут в том смысле, что нужно проверить подпись токена. По сути это тоже аутентификация, только сильно упрощенная по сравнению с получением самого токена.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И откуда AGW знать бизнес-логику валидации?
Речь о первичной валидации. Т.е. числовой параметр — числовой параметр, строка — строка и в таком духе.
Хотя кто-то ради экономии и часть бизнес-правил выносит.
Кстати, подпись токена — гораздо больше бизнес-валидация, чем вот это все.
НС>рбак должен как раз AGW реализовывать, пусть даже непосредственно вычисление правил выполняется сайдкаром с каким нибудь OPA. Без этого AGW не будет выполнять свою функцию основную. А аутентификация тут в том смысле, что нужно проверить подпись токена. По сути это тоже аутентификация, только сильно упрощенная по сравнению с получением самого токена.
Отчего же не будет?
Это входная точка в приложение и соответственно занимается всеми входными делами. От маппинга до роутингов.
Здравствуйте, IncremenTop, Вы писали:
НС>>И откуда AGW знать бизнес-логику валидации? IT>Речь о первичной валидации. Т.е. числовой параметр — числовой параметр, строка — строка и в таком духе.
Откуда AGW знать где число, а где строка? Только если бизнес-логика, включая формат значений, протечет из микросервиса в него.
Или речь про валидацию на основе swagger.json? Тогда это не особо имеет смысл, если только сервис настолько странный, что неверный формат числа там очень частое явление.
IT>Хотя кто-то ради экономии и часть бизнес-правил выносит.
Это уже не AGW, а что то куда более сложное. И точно не микросервисы.
IT>Кстати, подпись токена — гораздо больше бизнес-валидация, чем вот это все.
Почему? Подпись токена проверяется стандартными алгоритмами и никак от конкретного прикладного решения не зависит. Оно, к примеру, встроено в aspnet и включается там одной строкой в коде. Каким внезапным образом это оказалось бизнес-валидацией?
НС>>рбак должен как раз AGW реализовывать, пусть даже непосредственно вычисление правил выполняется сайдкаром с каким нибудь OPA. Без этого AGW не будет выполнять свою функцию основную. А аутентификация тут в том смысле, что нужно проверить подпись токена. По сути это тоже аутентификация, только сильно упрощенная по сравнению с получением самого токена.
IT>Отчего же не будет? IT>Это входная точка в приложение и соответственно занимается всеми входными делами. От маппинга до роутингов.
И? Как из этого следует, что авторизацией должен заниматься кто то другой?
