Это вопрос должен решать архитектор. Или нет?
Комментарии (8)
22 июня 2017 в 19:03
+1↑
↓
Мне кажется, что большая часть описанных проблем возникает из-за того, что пытаемся создать модель классов, а структура БД является «вспомогательной» (ORM).
Но сам по себе описанный проект ближе к тем задачам, для которых разрабатывались реляционные базы. И логичнее продумывать архитектуру не от классов java, а от er диаграммы базы. В таком случае большей части описанных проблем не появится. А если вспомнить о прочих проблемах, которые приносит за собой ORM, то описанный подход выглядит как сплошная проблема.22 июня 2017 в 19:24
0↑
↓
Я вас огорчу, но вы пока занимаетесь детскими задачами. Откройте например постановление 354 по расчету платы за коммуналку и запроектируйте.
SirEdvin
22 июня 2017 в 20:05
0↑
↓
А какой фреймворк возьмем? Если немного погуглить, то станет понятно, что особо вариантов нет, мы будем делать на Spring Framework. Причина проста, в Spring Cloud есть все, что нам потребуется.
Да ладно? http://www.gajotres.net/best-available-java-restful-micro-frameworks/. Выбор более чем есть. Я не особо вкурсах, но Spring Cloud же правда не tomcat использует?
Для тех, кто думает что нет, что язык программирования второстепенен и вообще, важна только команда, я предлагаю провести маленький мысленный эксперимент. Подумайте, на каком языке вы бы такой проект точно не делали, т.е. считаете, что это было бы однозначно неправильное решение. А теперь представьте себе, что архитектор решил таки сделать проект именно на этом языке. А когда вы будете гневно возмущаться, он вам скажет: это второстепенный вопрос, главное команда!
Потому что заставлять писать команду на языке, который она не знает довольно глупо, нет? Но такого языка нет, все решается затратами и неудобством. Если нужно писать на haskell и мне объяснят, почему именно на нем (скажем, какая-то важная либа есть только под него) то так и быть. Почему нет?
Ogoun
22 июня 2017 в 20:41
0↑
↓
А можно и по другому. При старте каждый сервис должен постучаться к VehicleTypesService сообщить ему о своем существовании. Это решение вроде хорошо выглядит, но не отвечает на вопрос что делать, если нам надо не добавить, а удалить вид транспортного средства.
В моем решении микросервисы которые должны предоставлять метаинформацию о своих услугах создают в шине обмена inbox с определенным именем при запросе на который отдают эту самую информацию. В итоге, тот кому информация нужна делает RequestMany в этот inbox и получает актуальную на текущий момент информацию.
22 июня 2017 в 22:17
0↑
↓
>единая точка входа, он же API Gateway
>поиск сервисов, он же Service Discovery
>одна точка конфигурации, он же Config Service
>центральная точка сбора и анализа логов
>мониторингИ в итоге мы получаем… получаем… ну например полноценную реализацию OSGI. Где микросервисы — вовсе не автономные непонятно какие процессы, а управляемые объекты в управляемой среде, где есть и поиск/дискавери, и сбор/анализ логов, и мониторинг, и конфигурация, и многое другое.
Lofer
22 июня 2017 в 22:49
0↑
↓
>поиск сервисов, он же Service Discovery
UDDI?
ngalayko
22 июня 2017 в 23:15 (комментарий был изменён)
0↑
↓
Во первых, если ты считаешь, что твоя архитектура хороша, то это значит, что ты ее еще никому не показывал. К коду это, кстати, тоже относится.
комментарии подтверждают
22 июня 2017 в 23:34
0↑
↓
Внимательно прочел, нашел одну принципиальную ошибку — что мешает разным сервисам пользоваться одной (ОК, физически разными, но реплицируемыми или federated) базами данных? Ответ: ничто не мешает.Сервис — это превращатель request в response. Какую он там БД использует — исключительно его дело, не так ли?
