Есть два микросервиса они базарят между собой по http. Сервис А вызвает сервис В. У обоих сервисов два разных солюшена.
Вопрос. В каком салюшене должен лежать клиент к сервису В. Учитывая, что им могут пользоваться и другие сервисы.
Здравствуйте, Gattaka, Вы писали:
G>Есть два микросервиса они базарят между собой по http. Сервис А вызвает сервис В. У обоих сервисов два разных солюшена. G>Вопрос. В каком салюшене должен лежать клиент к сервису В. Учитывая, что им могут пользоваться и другие сервисы.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Gattaka, Вы писали:
G>>Есть два микросервиса они базарят между собой по http. Сервис А вызвает сервис В. У обоих сервисов два разных солюшена. G>>Вопрос. В каком салюшене должен лежать клиент к сервису В. Учитывая, что им могут пользоваться и другие сервисы.
F>в третьем.
Казалось бы логично. Но давайте пойдем дальше. На примере .net. Пусть у нас есть еще солюшен с логером. Сборка лежит в nuget. Естественно, что его используют все. В том числе и клиент к сервису (предположим для примера).
Когда мы обновляем логер. Мы можем обновить его в сервисе A, но не обновить в клиенте к сервису B. Будет ошибка во время выполнения, т.к. dll c логером одна. А две сборки сервиса ссылкаются на разные версии.
Либо можно обновлять версию логера везде, но это не нужно и не удобно очень. Т.к. ссылаются на него все. Как в данном случае быть? Это на самом деле был основной вопрос.
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, Gattaka, Вы писали:
G>>Как в данном случае быть?
_R_>Использовать bindingRedirect
Пока мне это решение кажется вносящим излишнию сложность. Не могли бы вы пояснить как конкретно это можно использовать.
Здравствуйте, Gattaka, Вы писали:
G>Когда мы обновляем логер. Мы можем обновить его в сервисе A, но не обновить в клиенте к сервису B. Будет ошибка во время выполнения, т.к. dll c логером одна. А две сборки сервиса ссылкаются на разные версии. G>Либо можно обновлять версию логера везде, но это не нужно и не удобно очень. Т.к. ссылаются на него все. Как в данном случае быть? Это на самом деле был основной вопрос.
Я больше по JVM, но разве в С# мире нет понятия binary compatibility? В идеале, такие частоиспользуемые части, как логгер, должны оставаться обратно совместимы. Отступления от этого правила приводят к IPC, OSGi, микросервисам.
Здравствуйте, Gattaka, Вы писали:
F>>в третьем. G>Казалось бы логично. Но давайте пойдем дальше. На примере .net. Пусть у нас есть еще солюшен с логером. Сборка лежит в nuget. Естественно, что его используют все. В том числе и клиент к сервису (предположим для примера). G>Когда мы обновляем логер. Мы можем обновить его в сервисе A, но не обновить в клиенте к сервису B. Будет ошибка во время выполнения, т.к. dll c логером одна. А две сборки сервиса ссылкаются на разные версии. G>Либо можно обновлять версию логера везде, но это не нужно и не удобно очень. Т.к. ссылаются на него все. Как в данном случае быть? Это на самом деле был основной вопрос.
использовать обе версии, если не хочется обновляться.
nuget не умеет в версионность?
Здравствуйте, Gattaka, Вы писали:
G>Когда мы обновляем логер. Мы можем обновить его в сервисе A, но не обновить в клиенте к сервису B. Будет ошибка во время выполнения, т.к. dll c логером одна. А две сборки сервиса ссылкаются на разные версии. G>Либо можно обновлять версию логера везде, но это не нужно и не удобно очень. Т.к. ссылаются на него все. Как в данном случае быть? Это на самом деле был основной вопрос.
Надо делать клиента отдельным проектом. Со своими релизами, тасками и так далее. Соотвественно обновлять его версии в сервисах А и Б надо будет вдумчиво, читая релизноты и так далее.
Но конкретно с логами можно порешать проще, заюзать в клиенте https://github.com/net-commons/common-logging
