Кто работает с микросервисами - есть вопросы
Вот еще, более практическая задачка.
Слепил я простенький сервис на Web API. Как делаю отладку в студии на докере - все работает.
Как запускаю прямо в докере - не откликается страница.
Это проект тип - строка 1
А если делаю проект тип - строка 2, то страница показывается как из под студии в докере, так и прямо с докера.
Что еще нужно добавить первому проекту чтобы в докере также работал? НЕТ Коре 3.1
....
Похоже, что то обновилось/испортилось второй тип проекта тоже перестал работать - "The connection to the server was reset while the page was loading. Это под виндой
...
Но если делаю Publish на Docker Hub, то получается как и было описано. Я раньше именно так проверял.
...
Получилось - как обычно, самдурак 
Или путь к сервису неправильно указывал или забывал строку соединения к базе указывать. Ошибок то особых никаких не показывает.
Под виндой для отладки так и не работает, ну и фиг с ним.
Я ж явист и работаю со спрингом. Перед тем, как нттп-запрос попадает ко мне, как к прикладному программисту для обработки он проходит ряд фильтров. Где и настраивается защита. Токен извлекается из заголовка запроса и проверяется. По результатам проверки запрос или пропускается дальше или формируется отказ в запросе с соответствующим кодом.
Если с сервисом общается другой сервис, то там свои способы защиты. Кроме того сервис, который запрашивает, может запросить сначала токен у сервера авторизации
Если у двух сервисов общие 100 таблиц, то, наверное, с ахритектурой что-то не так.
Синхронизировать обычно специально не надо. При появлении нового объекта он кидается в очередь сообщений на которую подписаны все сервисы.
При этом каждый сервис берет из нее себе то, что ему нужно.
Недостатков у такого подхода тоже немало и такая архитектура подходит отнюдь не для всех задач, но кострукция получатеся гибче, ее легче поддерживать и в нее легче вноситъ изменения.
Монолит может состоять хоть из 100 длл. Он выполняется в одном процессе/на одной машине, у него одна большая бд, а вечно увеличивать память и количество ядер мы не можем.
Тот кто удаляет пользователя посылает об этом сообщение. Все остальные на это реагируют. Кто-то может и удалит из базы, кто-то просто пометит пользователя как невалидного, кто-то из-за закона о защите личных данные поменяет ему имя на Джон Доу, а кто-то просто проигнорирует (Сервису который собирает статистику обычно без разницы валидный юзер или нет).
В монолите удалить пользоватея тоже не просто. На него обычно ссылаются тысячи сделаных им за годы работы изменений.
Если сервис недоступен, то, например, сообщение для него останется в очереди до тех пор пока он не поднимется. Или система через некий промежуток времени не получив подтверждения начнет все откатывать назад. Почитайте, например про SAGA pattern.
И да, распределенные трансакции подерживать тяжело и накладно, но как показывает
практика это нужно очень и очень редко. Обычно достаточно отложенной консистенции.
В монолите удалить пользоватея тоже не просто
Обычно это дело базы.
SAGA pattern
https://habr.com/ru/post/427705/
Интересно, спасибо
Если у двух сервисов общие 100 таблиц
Нет имелось в виду несколько другое.
Сервис берет данные их базы и отдает их по какому АПИ. Дальше данные переводятся в "UI формат" (типа те же данные только с атрибутами).
Вот как это все синхронизировать?
При этом каждый сервис берет из нее себе то, что ему нужно.
Это вроде еще сложнее, нужно знать ИД объекта и какие данные он имеет.
Он выполняется в одном процессе/на одной машине
Не обязательно. Можно иметь несколько отдельных машин, работающих через балансировщик загрузки. Точно так же как и отдельные сервисы. Да. Память загружается всем приложением. Но если имеется 20 сервисов, то не значит, что будет 20 отдельных машин под них. Если запустить несколько сервисов на одной машине, то придется делить память между этими процессами. Это может быть слижнее. Я не знаю, как запускаются веб-приложения с-шар, но обычно веб-приложения запускаются из под веб-сервера и распределением потоков и памяти все равно занимается этот самый веб-сервер(аппликатион-сервеr)
Обычно я запрашиваю токен авторизации по имени пользователя и паролю, а сервис как?
По разному. Например создается специальный пользователь, первый сервис сначала запрашивает от имени этого пользователя токен авторизации у сервера авторизации, а потом с этим токеном лазит где надо. Этого пользователя можно ограничить специально правами. Кроме того можно ставить защиту на заптос только с определенного домена только приложениями с определенным именем и с соответствующим кодовым словом.
Сервис берет данные их базы и отдает их по какому АПИ. Дальше данные переводятся в "УИ формат" (типа те же данные только с атрибутами).Вот как это все синхронизировать?
С чем синхронизировать? Сервис - это нечто, что по запросу предоставляет какой то ресурс в пользование. Итак веб-сервис(апи), который отвечает на веб-запрос, передает запрос внутреннему сервису (чертов термин 'сервис', который используется везде в разных контекстах), который в свою очередь вытаскивает ентети-обьект(как правило из базы данных) и передает апи. Апи серелизует полученные данные согласно транспортному протоколу и отправляет как хттп-ответ. Все. Что спросили, то и ответили. Ничего синхронизовать не надо.
>Но если имеется 20 сервисов, то не значит, что будет 20 отдельных машин под них
Можно и на одной. А можно и на разных. Две машины с 64гб памяти могут оказаться дешевле одной с 128гб.
А можно сегодя на одной, а на выходных, когда нагрузка больше, на трех. С монолитом такой трюк не пройдет.
И это мы еще не начали обсуждать как обновлять наше монолиное приложение когда клиент требует 7х24 доступности основного функционала.
То бишь делаем дополнительную защиту и называем ее SS7В принципе да. Есть стандартные решения. Но если мы выходим за рамки
контрекста приложение и еще используем каналы связи, то внезапно встает
задача защиты доступа к отдельным частям проги. Но это нормально. Кроме
того, что веб-сервисы между собой взаимодействуют, может потребоваться
доступ сторонним приложениям. Например приложения, которое занимается
изготовлением берихтов (например квик селс) потребует данные по
РЕСТ-протоколлу.
Ничего синхронизовать не надо
вытаскивает ентети-обьект(как правило из базы данных) и передает апи --> Апи сериализует полученные данные --> вытаскиваем объект "для UI"
Добавили в таблицу поле адрес, обновили апи, хотим показать адрес в UI. Как без "синхронизации"?
Ааа, имеется в виду синхронизировать транспортные объекты на фронте и на бэке. Да. Синхронизировать надо. Для этого есть или стандартные средства фреймворков(например валидация) или всегда договариваться. Но да. Надо. Ещё раз. Можно написать без синхронизации. Например просто приходят пары проверти ключ-значение. И другая сторона роется в этих ключах, ища что то свое или просто сохраняя все без разбора. Но обычно синхронизировать надо.
и какой будет наиболее удобный способ?
В небольшом проекте руками. Но я не особенно большой специалист в этой области, я работаю в бэке и мы не пользуемся тулами. Пока. Я видел проекты с подключенным сваггеро, есть такой тул, он при построении проверяет, но для управления такими вещами нужен выделенный архитект, у нас таких нет. Поэтому при изменении бэк и фронт-проггеры просто догавариваются. Или это вообще один человек.