Size: a a a

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

2020 June 29

S

Sergey in Архитектура ИТ-решений
в keycloak  и авторизацию накрутили. Там полно всего
источник

S

Sergey in Архитектура ИТ-решений
только миллионы юзеров не факт что потянет
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
что значит миллионы?
источник

PD

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
миллионы одновременно? в среднем в час? на пике?
источник

GK

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

S

Sergey in Архитектура ИТ-решений
кто-то клон ЕАИС пишет :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey
кто-то клон ЕАИС пишет :)
тогда нужно с нуля писать:)
источник

S

Sergey in Архитектура ИТ-решений
...на Си
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
ну тогда конечно всё будет сразу быстро) и дорого
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
если не знаешь как сделать быстро - бери С
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Была кассандра, для неё не нашли бизнес-моделей, не научились на ней зарабатывать, в отличие от кафки (канфлюент). Начали пилить сциллу на С.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
я бы взял keyclock и и когда он не справится с ростом нагрузки - сделать свой кастомный. просто на начальном этапе проекта
а) вряд ли вы сможете оценить правильно нагрузку и профиль нагрузки
б) не все проекты переживают переход 10.000 -> 1.000.000 клиентов, так что нет смысла вкладываться прямо с начала
источник

S

Sergey in Архитектура ИТ-решений
да, самый разумный совет. Внутри просто заложиться на openID connect протокол. А конкретное решение подобрать потом. Начать с keycloak
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey Lukin
я бы взял keyclock и и когда он не справится с ростом нагрузки - сделать свой кастомный. просто на начальном этапе проекта
а) вряд ли вы сможете оценить правильно нагрузку и профиль нагрузки
б) не все проекты переживают переход 10.000 -> 1.000.000 клиентов, так что нет смысла вкладываться прямо с начала
С другой стороны, если сразу делать на keyclock, то нужно продумывать (инвестировать) в абстрации, которые позволят сделать решение независимым от имлементации.

Альтернатива - сделать просто собственное решение.

Но, опять же, нужны цифры, показатели назначения (арх. характеристики). А ещё ведь есть отказоустойчивость/катастрофоустойчивость, SLA и т.д.

Впрочем, лично я бы взял keyclock не раздумывая для этой задачи, но постарался бы всё же спроектировать абстракции
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
При решении таких задач есть обычно, а на самом деле всегда, всего три альтернативы:

- сделать с нуля из навоза и потом выкинуть
- взять что-то готовое и потом выкинуть
- сразу делать правильно и развивать

В первых двух случаях нужно продумывать абстракции, чтобы была потом возможность выкинуть. Иначе потом придётся жить с этим вечно (почти).

Это позволит выиграть время и определить для себя метрики, когда уже пора готовиться к тому, чтобы выкинуть.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И есть разумный компромисс - сделать правильные абстрации и имлементацию из навоза
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Sergey
да, самый разумный совет. Внутри просто заложиться на openID connect протокол. А конкретное решение подобрать потом. Начать с keycloak
Ну и авторизацию делать на каком-нибудь Kong, не на keycloak.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Во всех случаях абстрациями (дизайном, будь он неладен) стоит озаботиться, то есть немного поднатужиться и подумать
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Gennadiy Kruglov
При решении таких задач есть обычно, а на самом деле всегда, всего три альтернативы:

- сделать с нуля из навоза и потом выкинуть
- взять что-то готовое и потом выкинуть
- сразу делать правильно и развивать

В первых двух случаях нужно продумывать абстракции, чтобы была потом возможность выкинуть. Иначе потом придётся жить с этим вечно (почти).

Это позволит выиграть время и определить для себя метрики, когда уже пора готовиться к тому, чтобы выкинуть.
да, согласен, в данном случае  (что бы не делать свою собственную имплетментацию OIDC/Auth)  - - "взять что-то готовое и потом выкинуть", выглядит лучше.
источник