- Получит ли каждый микросервис свой репозиторий github и конвейер CI / CD?
Из моего опыта вы можете сделать и то, и другое. Я видел, как некоторые команды размещали несколько микро-сервисов в одном репозитории.
Мы поместили каждый микро-сервис в отдельный репозиторий, так как конвейер Jenkins был построен в общем
способ построить их таким образом. Это включало наличие некоторых файлов конфигурации в определенных каталогах, таких как
"/Scripts/microserviceConf.json"
Это помогало нам в некоторых случаях. В целом, вы также должны учитывать стоимость, поскольку GitHub имеет ценовую модель.
который учитывает, сколько у вас есть частных репозиториев.
- Как сохранить версии в синхронизации? Допустим, микросервис инструментов использует блог версии 2.3. Но блог только что получил версию 2.4, которая
несовместим с инструментами. Как мне сохранить постановку и производство
синхронизируемые среды, на какую версию они должны полагаться?
Вы должны быть обратно совместимы. Это означает, что если ваша версия блогов 2.4 не совместима с инструментами версии 2.3, у вас будет высокая зависимость
и соединение, которое снова становится одним из ключевых преимуществ микро-услуг. Есть много способов, как вы можете обойти это.
Вы можете внедрить систему управления версиями в свои микро-сервисы. Если у вас есть изменение тормоза, скажем, API, который вы должны поддержать
старая версия еще некоторое время и создает новый v2 нового API. Как POST "блоги / API / блог" будет иметь новый API
POST "blogs / api / v2 / blog", в котором будут представлены новые функции и инструменты, будет иметь некоторое время для поддержки
Bot API, так что он может перейти на v2.
Также посмотрите на Семантическое управление версиями здесь .
- Если я развертываю сервисные инструменты на нескольких разных серверах, чьи IP-адреса могут меняться, как другие сервисы находят ближайший
местонахождение этой услуги?
Я не совсем уверен, что вы имеете в виду здесь. Но это идет в направлении оркестровки микросервисов. Обычно ваш поставщик облачных услуг
Сервис имеет инструменты для борьбы с этим. Вы можете ознакомиться с сервисом AWS ECS и / или AWS EKS Kubernetes и узнать, как они это делают.
- Для монолитного приложения я могу запустить одну команду и просто перейти на сайт, чтобы взаимодействовать с моим кодом. Каковы хорошие практики
для локального развития с несколькими различными службами?
Я бы предложил использовать docker и docker-compose для создания ваших настроек разработки. Вы бы создали локальную сеть развития докера
контейнеры, которые будут представлять всю вашу систему. Это будет включать в себя: ваши микро-сервисы, инфраструктура (база данных, кэш, помощники) и другие. Вы можете прочитать об этом больше в этом ответе здесь . Это описано в разделе «Рассмотрение настроек разработки».
Куда я могу пойти, чтобы узнать больше?
Есть несколько источников для изучения этого. Некоторые из них:
https://microservices.io/
https://www.datamation.com/applications/devops-and-microservices.html
https://www.mindtree.com/blog/look-devops-microservices
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/multi-container-applications-docker-compose