-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.txt
79 lines (51 loc) · 5.91 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
Описание сервисов
1. task tracker
Сервис для работы с задачами: создание задачи, (пере)назначение на рандомный попугов, изменение статуса.
В БД сервиса есть соответствующая таблица task c колонками id, description, assign_fee, complete_cost, status, assignee_id.
2. auth
Единый сервис для аутентификации. Хранит информацию о пользователях и их ролях.
В БД сервиса есть таблица user (колонки id, name, role_id, account_id) и role (id, name). Если у
попуга может быть больше одной роли, то нужна еще и промежуточная таблица users_to_roles.
3. accounting
Сервис для учета движения средств на счетах попугов при назначении/выполнии задач.
В БД сервиса есть таблица account (колонки id, balance, user_id) и audit(id, event_name, description, creation_time, amount, account_id).
При каждом изменении баланса создается запись в таблице audit.
4. mailer
Севис по отправке электронных писем. В честности, для отправки письма попугу о заработке за день.
5. analytics
- самая дорогая задача за день/неделю/месяц - выборка из таблицы tasks сервиса task tracker;
- сколько заработал топ-менеджмент за сегодня - выборка из таблицы audit: сумма amount для задач с
event_name = (task_assigned, task_done).
- сколько попугов ушло в минус - выборка из таблицы account: берем все записи, у которых на начало дня
баланс >= 0, а на конец дня - < 0.
Процессы
Создание задачи
При создании задачи она назначается на рандомного попуга. При этом по известной формуле вычисляется
количество денег, которое нужно списать с попуга (assign_fee) и количество денег, которое нужно
начислить при завершении задачи (complete_cost).
Создание попуга
При создании попугов в таблице users сервиса auth создается соответствующая запись с попугов, а в roles -
с его ролью. При этом сервис auth публикует событие в топик users с темой "user created".
Сервис accounting подписан на топик users, и при получении события создает в своей таблице account
запись с нулевым балансом и id попуга-assignee. Возможно, стоит делать первую запись в аудит (?).
(Пере)назначение задачи на попуга
При нажатии на кнопку "заассайнить задачи" задачи (пере)назначаются на случаных попугов. При этом
в mq в топик tasks публикуется событие "task assigned" с объектом задачи.
На топик tasks подписан сервис accounting. При получении сообщения о назначении задачи сервис берет
assign_fee из задачи, обновляет баланс попуга (в таске укзан id) в таблице account и
создает запись в таблице audit, указывая в поле description id задачи и ее описание.
Закрытие задачи
При закрытии задачи обновляется статус задачи в таблице tasks, и в топик tasks отправляется событие
"task done" с объектом задачи. При получении этого сообщения accounting вычисляет, сколько денег надо
начислить попугу, и обновляет его баланс. В audit делается соответствующая запись.
В конце дня вычисляется, сколько каждый попуг заработал за день: выбираются записи из audit за
сегодняшний день, суммируется их amount, и записи группируются по account_id.
Cоздается письмо о выплате за день (email берется из объекта user, полученного через REST API сервиса auth).
Отправка почты
При получении события letter_created из топика mail сервис mailer отправляет
Аутентификациия пользователей
Для взаимодействия с любым сервисом (кроме auth) по REST API нужно указать JWT-токен. Попуг сначала делает запрос
в auth для логина, указывая форму своего клюва, получает токен, где в claims указано имя попуга и его роль.
Дальше все операции с другими сервисами делаются с указанием этого токена. В сервисах есть middleware, где
для того или иного url проверяется роль попуга из JWT claims.
В UI также функциональность ограничивается тем, что разрешено роли попуга.