Кто работает с микросервисами - есть вопросы
Решил вот тоже попробовать, но вопросов больше чем ответов. В принципе интересует ASP.NET Core 3.1 C#, но общие соображения тоже не помешают.
Фронтенд пока не трогаем пусть останется монолитом, хотя хотелось бы всё закинуть в один сервис. Для блазора решение есть во всяком случае.
Первое - это данные.
Сделал я базу, создал объекты, сделал рестфул апи - микросервис с постманом работает.
Теперь надо его вызвать. Сделал вызовы допустим, но ведь данные должны быть теже самые. То бишь или копия или ссылка.
А как же независимость? Если сервис изменил данные то тоже менять надо на фронтенде.
А базы как разные делать? Пользователь то мне нужен везде один и тот же, и подобных общих объектов море.
Пока остановлюсь...
Если нет, лучше оставить монолит
проблема не в этом. Что когда использовать не сильно интересует.
Задача разобраться с микросервисами и сделать демо приложение.
Микросервисы это всё же о бекенде
ну может название другое, но в идеале хотелось бы иметь "лего блоки" и для блазора + НЕТ 5 такое уже есть.
https://devblogs.microsoft.com/premier-developer/microfron...
Можно мешать Разор с Ангуляром и прочим. По ссылке только идея.
Задача разобраться с микросервисами и сделать демо приложение.
Так это уже давно сделано: Первая попавшаяся ссылка на Гитхабе.
Первая попавшаяся ссылка на Гитхабе.
Для начала нужно сделать самому чтобы понять. Не нашел пока ни одного подходящего проекта
Что в ссылке не подходит:
10 microservices showcasing Kubernetes, Istio, gRPC and OpenCensus.
и
Нужно ASP.NET Core попроще и без зайцев желательно. Это все следующий этап.
Тут бы получить данные с Рестапи от доскер контейнера
Спасибо гляну, но первое, что смущает "deploy changes to the AKS cluster".
Но вопрос по данным всё равно остается открытым.
Даннные и вычисления нужно разделять, в этом суть.
AKS в Azure я поднял за 10 минут. Поигрался пару дней. Стоило меньше 2 Евро.
Данные и вычисления нужно разделять, в этом суть.
Меня немного другое интересует. Данные на сервисе и фронтенде должны то быть одинаковыми. А как же "независимые сервисы"?
AKS в Azure я поднял за 10 минут.
Вообще то хотел дома в докере поиграться, а то за базу с приложением 5-ку драли ежемесячно. Сейчас поотключал всё, хотел глянуть выйдет ли на 0.
А Fabric Azure - это другое? Тоже вроде для микросервисов.
Данные на сервисе и фронтенде должны то быть одинаковыми. А как же "независимые сервисы"?
Какие данные? Что такое данные в этом контексте? Фронт делает запрос по определенному адресу. Определенному. Состоящему из хоста, порта и ендпойнта(ресурса). Нттп запрос . Получает нттп ответ. Что значит "независимый"? Бэкенд отвечает на любой запрос. Фронта, постмана, другого бэкэнда. Бэкенд занимается подготовкой данных к показу или изменению. Фронт запрашивает , бэк вытаскивает данные из одного или многих источников, подготавливает к отправке и предоставляет по запросу.
Пользователь то мне нужен везде один и тот же, и подобных общих объектов море.
Каждый сервис занимается чем то своим. Например сервис пользователей. То есть есть база данных пользователей и доступ к ней только через сервис пользователей. Если нужно что то другому сервису, он не имеет права лезть в чужую базу, а запрашивает данные через соответствующий сервис. Сервисы отдают данные по запросам не только фронту, но и другим сервисам.
Какие данные? Что такое данные в этом контексте?
У меня в есть в базе пользователь, сервис отдает мне например: имя, майл, роль. Для этого у меня есть POCO объект, создаваемый автоматом.
На фронтенде мне нужно получить тоже самое: имя, майл, роль. То бишь нужен идентичный POCO объект.
Теперь я в сервисе добавил телефон, значит нужна синхронизация с бекэндом и другими сервисами. Где же эта декларируемая независимость?
а запрашивает данные через соответствующий сервис
А как же дизайн базы? Удаляю я пользователя - значит автоматом со всех связанных таблиц должно удалится. Опять сервисам всё поручать и сообщения об удалении отслеживать? А если сервис слег и не получил сообщения?
Удаляю я пользователя - значит автоматом со всех связанных таблиц должно удалится.
Для этого есть нормализация данных, это вопрос дизайна БД, это не совсем про микросервисы.
Каждый пользователь и его атрибуты должен писаться один раз (в идеале, конечно).
А если сервис слег и не получил сообщения?
Для этого СУБД должна уметь транзакции
это вопрос дизайна БД
Для одной базы то нет проблем, а когда все таблицы по разным базам раскиданы? По базе на сервис.
То есть вы атомарный объект описываете атрибутами из разных БД? Не думаю, что это кошерно...
Есть конечно распределённые транзакции, но там с производительностью вопросы.
То есть вы атомарный объект описываете атрибутами из разных БД?
Почему атомарный?
Вот есть у меня пользователи на германке.
Теперь хочу сервис теннисные клубы сделать, что бы каждый пользователь мог туда записаться.
Для одной базы мы бы добавили таблицу клубов и затем еще одну клуб-пользователь. Как теперь правильно сделать две базы для сервиса?
Где же эта декларируемая независимость?
------
Рефрешишь импликацию клиента и получаешь.
Смотрел как-то способы расширения класса без перекомпиляции - ничего приличного не обнаружил. Хотя и какие-то решения были.
Рефрешишь импликацию клиента и получаешь.
Так везде же кричат микросервисы, микросервисы - добавляй что хошь без изменений. Лукавят значат?
Не надо сюда приплетать микросервисы, тут скорее про дизайн БД.
А микросервисы вообще не всем нужны.