SB
На фото текущая версия модели с высоты птичьего полета.
Size: a a a
2020 September 05
АЛ
Sergey Baranov
На фото текущая версия модели с высоты птичьего полета.
А есть ссылка на более читаемую модель?
SB
Андрей Лесных
А есть ссылка на более читаемую модель?
Мне бы пока не хотелось ее на широкую общественность представлять по ряду причин. Одна из них - сырость, требует множества пояснений. Поэтому я и ищу заинтересованных людей, кому было бы интересно совместно обсудить, проработать и развить модель и в итоге презентовать ее сообществу, можно приурочить первую финалку к archdays, например.
2020 September 06
GK
Sergey Baranov
Мне бы пока не хотелось ее на широкую общественность представлять по ряду причин. Одна из них - сырость, требует множества пояснений. Поэтому я и ищу заинтересованных людей, кому было бы интересно совместно обсудить, проработать и развить модель и в итоге презентовать ее сообществу, можно приурочить первую финалку к archdays, например.
👍
AT
Некоторые подробности про архитектуру нового процессора POWER10:
https://www.itjungle.com/2020/08/24/drilling-down-into-the-power10-chip-architecture/
https://www.itjungle.com/2020/08/24/drilling-down-into-the-power10-chip-architecture/
A
Коллеги, здравствуйте!
Коллеги, есть один архитектурный вопрос, касающийся микросервисной архитектуры.
Все мы знаем, что микросервис должен обладать своей собственной базой данной, в которой хранит сущности.
Но тут возникает следующий вопрос, как же тогда обстоит дело с содержаниеим этих сущностей и нормализацией базы данных.
Поясню на примере. У нас есть микросервис отвечающий за клиентов. Их заведение, авторизацию и т.д. В его базе данных хранятся данные клиента: идентификатор (уникальный), ФИО, Пол, Дата рождения и т.д. В смежных таблицах или прямо в таблице клиента хранится номер телефона, Email и т.д.
Также есть микросервис диалогов между пользователями. Одним из требований к нему является выдача данных диалога в котором указаны ФИО, пол и телефон пользователя, который оставил конкретное сообщение. Этот микросервис обладает базой данных сообщений.
В чем собственно вопрос: нужно ли в таблице сообщений иметь кроме поля уникального идентификатора клиента, также поля ФИО, пол, телефон? Или же их нужно запрашивать у микросервиса отвечающего за клиента по уникальному идентификатору? При отображении диалогов таких запросов к микросервису клиентов будет множество.
Если же записывать их в таблицу диалогов микросервиса диалогов, у нас возникает избыточность данных, а также потенциальная несогласованность этих данных в случае если клиент изменит свои данные.
В формате сервисной архитектуры все понятно. У нас N-е кол-во сервисов и одна база данных и у нас есть возможность через JOIN запрашивать данные клиента из таблицы клиентов (или N-го кол-ва связанных таблиц).
А как правильно поступать в ситуации с микросервисами? Ведь вызов получения данных клиента по идентификатору из друго микросервиса достаточно дорог.
Коллеги, есть один архитектурный вопрос, касающийся микросервисной архитектуры.
Все мы знаем, что микросервис должен обладать своей собственной базой данной, в которой хранит сущности.
Но тут возникает следующий вопрос, как же тогда обстоит дело с содержаниеим этих сущностей и нормализацией базы данных.
Поясню на примере. У нас есть микросервис отвечающий за клиентов. Их заведение, авторизацию и т.д. В его базе данных хранятся данные клиента: идентификатор (уникальный), ФИО, Пол, Дата рождения и т.д. В смежных таблицах или прямо в таблице клиента хранится номер телефона, Email и т.д.
Также есть микросервис диалогов между пользователями. Одним из требований к нему является выдача данных диалога в котором указаны ФИО, пол и телефон пользователя, который оставил конкретное сообщение. Этот микросервис обладает базой данных сообщений.
В чем собственно вопрос: нужно ли в таблице сообщений иметь кроме поля уникального идентификатора клиента, также поля ФИО, пол, телефон? Или же их нужно запрашивать у микросервиса отвечающего за клиента по уникальному идентификатору? При отображении диалогов таких запросов к микросервису клиентов будет множество.
Если же записывать их в таблицу диалогов микросервиса диалогов, у нас возникает избыточность данных, а также потенциальная несогласованность этих данных в случае если клиент изменит свои данные.
В формате сервисной архитектуры все понятно. У нас N-е кол-во сервисов и одна база данных и у нас есть возможность через JOIN запрашивать данные клиента из таблицы клиентов (или N-го кол-ва связанных таблиц).
А как правильно поступать в ситуации с микросервисами? Ведь вызов получения данных клиента по идентификатору из друго микросервиса достаточно дорог.
Несколько нескромных вопросов
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
A
Я не архитектор, но интересная задача с точки зрения бизнес-логики.
Если подумать, когда я просматриваю ваше сообщение в телеграме, я не работаю в одном сервисе "сообщений", я вижу сообщение (статичный текст, когда то созданный вами) + ваш ник (срез информации вашего аккаунта телеграм, который существует сам по себе).
Значит ли это, что чат на самом деле работает с двумя сервисами - и сообщения, и аккаунты? И информация сообщения представляет соединение таблиц, которое происходит в момент чтения, а не вывод данных из БД одного сервиса
Если подумать, когда я просматриваю ваше сообщение в телеграме, я не работаю в одном сервисе "сообщений", я вижу сообщение (статичный текст, когда то созданный вами) + ваш ник (срез информации вашего аккаунта телеграм, который существует сам по себе).
Значит ли это, что чат на самом деле работает с двумя сервисами - и сообщения, и аккаунты? И информация сообщения представляет соединение таблиц, которое происходит в момент чтения, а не вывод данных из БД одного сервиса
С
Andrey
Несколько нескромных вопросов
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
1. Решить описанную задачу можно сервисной архитектурой.
2 и 3 похожи. Предполагается, что точность важна, и важно чтобы все видели актуальное имя пользователя.
Описанная система - пример для иллюстрации терзающего меня вопроса, хоть и имеет отношение к проектируемой мной сейчас платформе.
В своей платформе программе лояльности на сгораемых бонусах я в итоге применил сервисный подход при использовании одного сервера MySQL. И микросервисный при использовании Azure SQL.
Т.к. много делал исходя из собственного представления, то и решил узнать у сообщества, есть ли какие либо шаблоны или best practices в этом вопросе.
Узнал много нового, за что благодарен всем вовлечённым.
2 и 3 похожи. Предполагается, что точность важна, и важно чтобы все видели актуальное имя пользователя.
Описанная система - пример для иллюстрации терзающего меня вопроса, хоть и имеет отношение к проектируемой мной сейчас платформе.
В своей платформе программе лояльности на сгораемых бонусах я в итоге применил сервисный подход при использовании одного сервера MySQL. И микросервисный при использовании Azure SQL.
Т.к. много делал исходя из собственного представления, то и решил узнать у сообщества, есть ли какие либо шаблоны или best practices в этом вопросе.
Узнал много нового, за что благодарен всем вовлечённым.
С
Andrey
Я не архитектор, но интересная задача с точки зрения бизнес-логики.
Если подумать, когда я просматриваю ваше сообщение в телеграме, я не работаю в одном сервисе "сообщений", я вижу сообщение (статичный текст, когда то созданный вами) + ваш ник (срез информации вашего аккаунта телеграм, который существует сам по себе).
Значит ли это, что чат на самом деле работает с двумя сервисами - и сообщения, и аккаунты? И информация сообщения представляет соединение таблиц, которое происходит в момент чтения, а не вывод данных из БД одного сервиса
Если подумать, когда я просматриваю ваше сообщение в телеграме, я не работаю в одном сервисе "сообщений", я вижу сообщение (статичный текст, когда то созданный вами) + ваш ник (срез информации вашего аккаунта телеграм, который существует сам по себе).
Значит ли это, что чат на самом деле работает с двумя сервисами - и сообщения, и аккаунты? И информация сообщения представляет соединение таблиц, которое происходит в момент чтения, а не вывод данных из БД одного сервиса
Вопрос как раз к этому и сводится. Как организовать такой вывод оптимально.
PD
Andrey
Несколько нескромных вопросов
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
1. Нельзя ли решить задачу сервисной архитектурой? То есть что то типа вот этого:
https://t.me/itarchitect/69225
2. Насколько критична точность и актуальность данных?
3. А собственно какое имя должно отражаться в прлшлом сообщении, если оно отправлено до смены имени?
А зачем? По идее подсистема лояльности данные по пользователю должна брать из соответствующей подсистемы. Общая база тут скорее плохая идея.
С
Не понял сообщения, можно как-то пояснить позицию?
@dphil
Я имею ввиду, что при использовании паттерна bff у нас все равно будут запросы к нашим сервисам, только не от клиента, а от экземпляра слоя bff.
Понятно, что мы можем кешировать данные, но все же... если на то пошло, то кешировать можно и на стороне клиента (хотя это и извращение).
При денормализации/обогащении данных в диалоге дергать другие сервисы не нужно.
Я имею ввиду, что при использовании паттерна bff у нас все равно будут запросы к нашим сервисам, только не от клиента, а от экземпляра слоя bff.
Понятно, что мы можем кешировать данные, но все же... если на то пошло, то кешировать можно и на стороне клиента (хотя это и извращение).
При денормализации/обогащении данных в диалоге дергать другие сервисы не нужно.
A
Если прямо проецировать бизнес-логику на техническое решение - сообщение имеет только идентификатор. Информация о вас (имя, фото) не есть часть сообщения и читается отдельно.
Точнее, не так. Частью сообщения является ваше имя, от которого я его получил в свое время. Если у меня не прогрузилось ваше текущее имя, а сообщение прогрузилось - я должен увидеть ваше старое имя, от которого я получал его.
Те Вы для меня "срез наиболее свежей информации, которую я знаю о вас".
Точнее, не так. Частью сообщения является ваше имя, от которого я его получил в свое время. Если у меня не прогрузилось ваше текущее имя, а сообщение прогрузилось - я должен увидеть ваше старое имя, от которого я получал его.
Те Вы для меня "срез наиболее свежей информации, которую я знаю о вас".
PD
@dphil
Я имею ввиду, что при использовании паттерна bff у нас все равно будут запросы к нашим сервисам, только не от клиента, а от экземпляра слоя bff.
Понятно, что мы можем кешировать данные, но все же... если на то пошло, то кешировать можно и на стороне клиента (хотя это и извращение).
При денормализации/обогащении данных в диалоге дергать другие сервисы не нужно.
Я имею ввиду, что при использовании паттерна bff у нас все равно будут запросы к нашим сервисам, только не от клиента, а от экземпляра слоя bff.
Понятно, что мы можем кешировать данные, но все же... если на то пошло, то кешировать можно и на стороне клиента (хотя это и извращение).
При денормализации/обогащении данных в диалоге дергать другие сервисы не нужно.
Денормализацию между сервисами - дорогая вещь. Обогащение на bff - чуть ли не самое простое решение во многих случаях. Локальные вызовы по сети - это дешёвый ресурс.
С
А зачем? По идее подсистема лояльности данные по пользователю должна брать из соответствующей подсистемы. Общая база тут скорее плохая идея.
А общей базы и нет. Несколько баз данных, каждая из которых хранит свои данные. Но сервисы обращаются к разным базам данных для получения результирующих данных.
PD
А общей базы и нет. Несколько баз данных, каждая из которых хранит свои данные. Но сервисы обращаются к разным базам данных для получения результирующих данных.
Это явно не то, что имел в виду автор поста. Перечитайте ещё раз тред
С
Денормализацию между сервисами - дорогая вещь. Обогащение на bff - чуть ли не самое простое решение во многих случаях. Локальные вызовы по сети - это дешёвый ресурс.
Я это понимаю, вот и спрашивал как же лучше поступать. Но с тезисом, что по локальной сети вызовы не дорогие, мне сложно согласится - все зависит от нагрузки.
PD
А когда они дорогие?
A
А зачем? По идее подсистема лояльности данные по пользователю должна брать из соответствующей подсистемы. Общая база тут скорее плохая идея.
Да, я уже пришел к другому выводу
https://t.me/itarchitect/69304
https://t.me/itarchitect/69304
A
В такой логике одна бд действительно не нужна
2020 September 07
DT
всем привет, подскажите, пожалуйста, есть ли какие-то готовые и проверенные временем решения, подходы для реализации сервера лицензирования? может быть какой-то высокоуровневый протокол?