Хороший архитектурный дизайн для управления сервером и шлюзом в kdb - PullRequest
Новая
       6

Хороший архитектурный дизайн для управления сервером и шлюзом в kdb

1 голос
/ 01 марта 2020

У меня есть 2 шлюза, которые подключаются к серверу, на котором регистрируются данные пользователя.
Я могу придумать два способа регистрации пользователей, получающих доступ к серверу через шлюз.

Первый способ: регистрация ведется на стороне сервера, т.е. 

Server(port 5001) Code:
au:([user:`$()]; tim:`timestamp$()); /- Table to maintain logged users
.z.pw:{`au upsert (x;.z.n); show y; 1b}

Gateway 1:
h:hopen `::5001:a:uts1

Gateway 2:
h: hopen `::5001:b:uts2

Второй способ: регистрация ведется со шлюза, т.е. 

Server(port 5001) Code:
au:([user:`$()]; tim:`timestamp$()); /- Table to maintain logged users

Gateway 1:
q)h:hopen `::5001:a:uts1
q)h"`au upsert (`a;.z.p)"

Gateway 2:
q)h: hopen `::5001:b:uts2
q)h"`au upsert (`b;.z.p)"

Следовательно, хорошо ли писать код регистрации пользователя на стороне сервера ( Сервер) или на стороне клиента (в данном случае шлюз) или есть лучший / стандартный способ сделать то же самое?

РЕДАКТИРОВАТЬ - Что, если мы добавим промежуточное программное обеспечение (диспетчер пользователей) между несколькими шлюзами и несколькими серверами в этом случае будет хорошо написать код регистрации пользователя на промежуточном программном обеспечении (диспетчер пользователей) или на стороне клиента (в данном случае шлюз)?

1 Ответ

1 голос
/ 01 марта 2020

Если пользователи подключаются через шлюз к нескольким серверам, я бы включил регистрацию пользователей и аутентификацию на уровне GW. Это еще больше отвлечет конфиденциальные данные от потенциально неавторизованных пользователей и упростит ведение учетной записи основной записи, поскольку всем пользователям необходимо go через GW. Для выполнения действий с учетными записями на стороне сервера потребуется агрегирование на нескольких серверах, чтобы получить полную картину активности системы.

...