Size: a a a

Архитектура ИТ-решений

2020 December 02

PD

Phil Delgyado in Архитектура ИТ-решений
Viktor Alexandrov
ну дык я и вёл к этому оттокнувшись от "Иногда надо точное соответствие". Всё равно выйдет "примерно", как обычно основной вопрос в снижении влияния на пользователей, а не в устранении оного(
Ну, статус платежа надо показать актуальный, хотя в витрине его еще может и не быть.
И баланс (тут уже нет грязных чтений, баланс всегда точен)
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Phil Delgyado
Ну, статус платежа надо показать актуальный, хотя в витрине его еще может и не быть.
И баланс (тут уже нет грязных чтений, баланс всегда точен)
И как решаете, если не секрет?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Запросом на сервис биллинга, увы.
А вот если биллинг отвечает медленно (бывают такие клиенты), то все грустно. Или долго ждем и показываем "часики" вместо баланса или показываем данные из кэша (иногда другого цвета) и ждем прихода точных данных.
Сильно зависит от конкретики.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Когда я сам делаю биллинг и аккаунтинг, то состояние счета приходит достаточно быстро всегда.
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Phil Delgyado
Запросом на сервис биллинга, увы.
А вот если биллинг отвечает медленно (бывают такие клиенты), то все грустно. Или долго ждем и показываем "часики" вместо баланса или показываем данные из кэша (иногда другого цвета) и ждем прихода точных данных.
Сильно зависит от конкретики.
ну понятно, в целом-то
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Угу. Магии-то нет (
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
волшебных решений нет)
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
впрочем баланс другого цвета с подписью "актуально на чч:мм" доставаемый из кэшей это нормальный UX, мы тоже так делали (но я хз, доделали ли, успел уйти не дождавщись)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, вот у нас UXеры скорее против такого решения, клиенту не удобно.
Так что делаем разными способами, благо это все легко конфигурируется
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но вообще пользователи уже привыкли, что баланс может быть кривой на приложении или сайте.
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Вообще уже наконец все привыкли, что айти кривое
источник

PO

Pavel Osipov in Архитектура ИТ-решений
Viktor Alexandrov
Вообще уже наконец все привыкли, что айти кривое
а когда было не так?)))
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, дело не в айти, у тебя связь может не работать...
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Pavel Osipov
а когда было не так?)))
всегда было так, но все только начали привыкать
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Phil Delgyado
Ну, дело не в айти, у тебя связь может не работать...
с точки зрения пользователя -- это "всё виноваты программисты"
источник

N

Nico in Архитектура ИТ-решений
Коллеги, приветствую!
Есть интересный вопрос про внедрение IdentityService4 в "микросервисную" архитектуру.
У нас есть Ui React, страницы которого защищены Identity, используется authorization_code flow для получения access_token.
Скоупами в данном случае являются openid profile и cms_service
После его получения мы обращаемся с ним к cms_service, который в свою очередь запускает цепочку вызовов других сервисов для получения данных
К примеру цепочка такая
ui ==> cms_service ==> business_service ==> data_service
так вот, если мы получаем токен только для cms_service с ним мы уже не можем обращаться к business_service, поэтому была идея настроить взаимодействие между cms и business через M2M с помощью client_credentials flow, но при таком потоке мы не получаем данные о авторизованном пользователе, а эти данные необходимы в data_service....
и вот вопрос, есть ли какие-то "лучшие практики" для создания подобного рода взаимодействия?
примерное графическое представление цепочки действий во вложении
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Nico
Коллеги, приветствую!
Есть интересный вопрос про внедрение IdentityService4 в "микросервисную" архитектуру.
У нас есть Ui React, страницы которого защищены Identity, используется authorization_code flow для получения access_token.
Скоупами в данном случае являются openid profile и cms_service
После его получения мы обращаемся с ним к cms_service, который в свою очередь запускает цепочку вызовов других сервисов для получения данных
К примеру цепочка такая
ui ==> cms_service ==> business_service ==> data_service
так вот, если мы получаем токен только для cms_service с ним мы уже не можем обращаться к business_service, поэтому была идея настроить взаимодействие между cms и business через M2M с помощью client_credentials flow, но при таком потоке мы не получаем данные о авторизованном пользователе, а эти данные необходимы в data_service....
и вот вопрос, есть ли какие-то "лучшие практики" для создания подобного рода взаимодействия?
примерное графическое представление цепочки действий во вложении
Просто -- приложите идентити юзера в заголовках и рассчитываете, что все сервисы друг другу доверяют (либо защищённая сеть, либо по MTLS, либо по client_credentials). Сложно -- почитайте про OAuth Token Excnahge (это пока draft, но уже почти стандарт) и пусть каждый промежуточный сервис на основе полученного токена запрашивает новый для доступа к следующему сервису. Однако при значимой нагрузке AS становится точкой отказа. Ибо если даже access_token является JWT, и его можно проверить без обращения к AS, то для выписки новых токенов нужен запрос в AS, что довольно накладно. Плюс менджмент этих токенов со стороны каждого сервиса (не на каждый же апи запрос получать новый "промежуточный" токен)
источник

N

Nico in Архитектура ИТ-решений
ну да, получается хоть второй вариант и более защищенный, но получается что может не выдержать большой нагрузки...
источник

N

Nico in Архитектура ИТ-решений
спасибо большое, буду пробовать запихивать информацию в заголовки) осталось только понять необходимое и достаточное количество информации, чтобы заголовки не раздувались
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
а это уже от предметной области и ролевой модели зависит
источник