#java #spring #orm #dependencies #microservices
#java #spring #orm #зависимости #микросервисы
Вопрос:
У меня есть сценарий с несколькими приложениями, каждое из которых обрабатывает свои собственные данные. Но поскольку бизнес взаимосвязан, нам необходимо получить доступ к данным приложений друг друга.
У нас в основном есть стратегия зависимости от базы данных, совместное использование объектов с некоторыми приложениями или отображение представлений в других. Это создало ад зависимостей!
-
Как микросервисы могут помочь нам в таком сценарии?
-
Как получить доступ к нескольким URL-адресам лучше, чем использовать соединения с базой данных? (например, EntityA имеет зависимость сопоставления с EntityB. Если я использую стратегию микросервиса, мне пришлось бы вызывать /apirest /resourceA и /apirest/resourceA /resourceB, верно? Как это было бы лучше / быстрее, чем иметь select * from EntityA inner join EntityB?)
-
Как я могу разделить данные между всеми приложениями (это примерно 10 приложений, которые в какой-то момент получают доступ к одним и тем же данным)?
-
Какие-либо материалы / статьи / технологии указывают?
Комментарии:
1. Это распространенный вопрос в microservice, и вы найдете ответы на похожие вопросы под тегом «microservice». Короче говоря, синхронный доступ к нескольким URL-адресам обычно не рекомендуется, поскольку он тесно связывает службы. Когда кто-то сталкивается с такими сценариями, два часто рекомендуемых маршрута: 1. Пересмотрите свой дизайн, чтобы убедиться, что «ограниченный контекст» правильный, 2. Примените «шаблон материализованного представления», который говорит об асинхронной передаче данных отдельным микросервисам для создания локального «материализованного представления» в их собственной БД, чтобы они могли получить доступ к данным локально.
Ответ №1:
- Микросервисы определяют четкую границу. Они чудесным образом не сделают все быстрее.
- Объединения баз данных также являются жизнеспособными решениями. Если у вас очень сильная связь между вашими данными, микросервисы могут оказаться неподходящим вариантом. Микросервисы позволяют вашим различным службам использовать технологию, независимую от остальных. Допустим, у вас есть службы A и B. Вы могли бы использовать реляционную базу данных в службе A для данных, которые сильно связаны и требуют транзакционной безопасности, и графическую базу данных в службе B для управления реляционными данными. Службам A и B все равно, что использует другая сторона, поскольку это скрыто за границей службы.
- Если вы можете разделить свои данные на домены с минимальным взаимодействием, эти доменные границы станут хорошей отправной точкой для ваших сервисов. В конечном итоге службам придется ссылаться на объекты другой службы. Два возможных варианта — либо всегда вызывать другую службу, либо сохранять минимальную локальную копию удаленных данных (например, только первичный ключ удаленного объекта). Локальная копия, конечно, должна поддерживаться в соответствии с данными (с событиями?). На данный момент мы боремся именно с этим моментом…
- Если вы загуглите микросервисы, вы утонете в информации. Мне нравится https://martinfowler.com/articles/microservices.html в качестве отправной точки.
Я уверен, что я не коснулся здесь всех аспектов микросервисов, это просто краткий намек на направление, с которого можно начать свое путешествие…