Множество микросервисов в одном ядре dotnet + git repo? - PullRequest
0 голосов
/ 03 апреля 2019

Я ищу варианты нового архитектурного решения для уровня API. Мы решили использовать ядро ​​dotnet, и мы бы хотели, чтобы каждая часть функциональности нашего приложения была разбита на микросервисы. Мы используем azure devops для обработки рабочих процессов сборки / тестирования / выпуска CI / CD.

Основываясь на широком анализе, я бы оценил, что наше текущее серверное решение может быть разбито на 10-15 отдельных микросервисов. К сожалению, у большинства из них была бы похожая внутренняя зависимость, но я все же хотел бы разбить их на части, чтобы мы могли изолировать модульное тестирование, иметь меньшие следы CI / CD и начать проект с четкого разделения проблем.

Однако в то же время я бы хотел избежать 10-15 различных репозиториев, решений и потоков CI для облегчения этого рабочего процесса. Это станет чем-то вроде кошмара для простоты разработки, когда разработчики будут регулярно менять рабочие пространства (список «Открыть последние» в любой IDE будет полностью переполнен!), Поддерживая и синхронизируя 10-15 CI / CD.

На мой взгляд, идеальным результатом было бы одно решение, git-репо и процесс сборки, в котором каждый микросервис отделен как проект внутри решения. Когда код фиксируется, я хотел бы запустить процесс в devops Azure, который будет создавать / тестировать / развертывать только те службы, которые были изменены в фиксации.

Это возможно или я сплю? Мне не очень повезло с Google, но, возможно, я не ввожу нужную фразу для этого ...

Заранее спасибо!

1 Ответ

1 голос
/ 04 апреля 2019

Мы находимся примерно в аналогичной ситуации и решили разместить наши микросервисы (с общей базой данных, к сожалению) в одном git-репо, но у каждого есть свое решение.Каждый API имеет свое собственное определение сборки, и каждое определение сборки имеет свой собственный триггер с фильтром пути.Я полагаю, что этот подход работает, даже если API находятся в одном решении: создавать отдельные сборки с фильтром пути в триггере для папок, в которых исходный код каждого API находится в git-репо.При изменении нескольких API запускаются только сборки, ориентированные на эти папки.См. Построение конвейерных триггеров в документации по DevOps Azure .

Я бы посоветовал немного подумать о том, как вы хотите отслеживать релизы, так как в итоге вы получите 10-15 определений релизов.Отслеживать их по отдельности (чтобы увидеть, какие сборки у вас работают в определенной тестовой среде) немного затруднительно, и я пока не нашел хороший способ создать панель мониторинга, которая бы показывала все выпуски, развернутые в определенной среде./stage.

...