Подход к шаблонам сообщений связи микросервисов - PullRequest
0 голосов
/ 04 марта 2019

Я пытаюсь реализовать микросервисный проект на ASP.NET Core (веб-API).Итак, у меня есть независимые компоненты, которые общаются между ними и внешним миром.Итак, у меня есть «точки соединения» между сервисами - модель представления (входные данные) одного является эквивалентом запроса / ответа для других и так далее.Я думаю, что есть несколько лучших практик для этого случая, которые позволяют мне не создавать тонны идентичного кода, я прав?

Глубоко, давайте посмотрим на ситуацию, где у меня есть, например, данные вбаза данных и микросервис, которые получают (возможно преобразовывают или немного расширяют) информацию из БД и передают ее запрашивающему.Можно ли не создавать дубликаты кода для хранения и получения информации из базы данных?

Спасибо.

Ответы [ 2 ]

0 голосов
/ 04 марта 2019

В основном это зависит от вашего варианта использования, общего намерения и архитектуры решения.

Микроуслуги должны быть автономными с точки зрения разработки и развертывания, и они не должны знатьо себе или знать как можно меньше.Чем больше они знают о других микро сервисах, тем выше связь.Они должны владеть его моделью и данными, необходимыми для того, для чего они созданы (чтобы выполнить свои обязанности).Вы можете достичь этого, например, используя интеграцию на основе событий .

В этом сценарии я не вижу необходимости повторного использования кода.Каждый микро сервис будет иметь различный ввод и логику.Вы должны стремиться к этому в своем проекте.

Если ваши микроуслуги слишком болтливы (например, им часто приходится запрашивать данные у других микроуслуг), вы, вероятно, допустили ошибку в их границах, и вам следует подуматьразработайте их снова.Также вам следует избегать создания микроуслуг, которые являются просто браузерами для своих баз данных.

Следующее, на что следует обратить внимание, это принцип DRY , и почему он не применим в мире микроуслуг.В ООП мире принято использовать этот принцип.Вот почему большинство разработчиков будут пытаться использовать его в мире микро-услуг.Но если вы попытаетесь применить это к микросервисам, вы получите высокую степень связи и не сможете разработать их по-настоящему независимо.Повторное использование кода и избыточность данных не так плохи, как вы, вероятно, думаете.

Итак, подведем итоги.Как я сказал в начале , это зависит .Если ваши «микроуслуги» являются частью одного решения, и вы, например, ссылаетесь на них в коде, вы не можете назвать их микроуслугами и можете использовать решение, как сказал Андрей.Но если это не так, и вы действительно заботитесь об их независимости (и следите за тем, что я упомянул выше), вам не следует делиться кодом между различными микро-сервисами, и в этом нет необходимости.Но если разные микро сервисы действительно используют один и тот же код (даже если они хорошо спроектированы), не бойтесь и просто используйте один и тот же код .Вы увидите, что это окупится.

Микро услуги - это не серебряная пуля для всех нужд, и вы должны знать об этом.В качестве дополнительной справки я рекомендую вам эту бесплатную книгу .

0 голосов
/ 04 марта 2019

О чем вы говорите, это модели.Входные модели и выходные модели (DTO).

Если ваши проекты являются частью одного и того же решения, то, возможно, вы можете иметь общий проект или библиотеку классов для повторного использования ваших моделей.

Если нетсоздайте пакет NuGet, распространите его через собственный канал и используйте его во всех проектах, для которых он требуется.

Чтобы это работало, вам нужно сделать этот проект очень простым.Он не должен иметь никаких зависимостей, поэтому вы можете ссылаться на него без непредвиденных последствий.Если вы держите его очень простым, то он может хорошо работать.

...