Микросервисы со многими хранилищами устарели

Question

В архитектуре микросервисов лучшая стратегия для поддержания множества сред разработчиков в современных хранилищах исходного кода?

Предположим, что в git было 10 команд из 10 разработчиков, работающих на 200 микросервисах. Каждый разработчик должен регулярно извлекать данные из каждого репозитория. Это можно сделать со сценариями, но есть ли лучший способ? Мы делаем это неправильно, потому что это похоже на тяжелые накладные расходы.

Answer 1

Я бы не советовал каждому разработчику строить каждый микросервис. Я бы предложил какую-то непрерывную интеграционную среду. Один централизованный сервер сборки, подключенный ко всем git-репозиториям.

Каждый раз, когда репо обновляется, сервер сборки должен обнаруживать изменения, строить код, запускать единичные (или функциональные) тесты, а затем нажимать службу на какую-то среду интеграции. Затем сервер сборки может также выполнить некоторые интеграционные проверки с развернутой службой.

Большинство разработчиков должны иметь возможность выполнять все свои разработки и испытания без необходимости доступа к другим микросервисам. Если разработчик строит сервис X, который зависит от Y Z и зависит от A & B, то разработчик должен, по большей части, иметь только сервис X. Для служб модульного тестирования Y & Z следует издеваться/имитировать.

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

Способ решения, который, как я полагаю, должен состоять в регулярном тестировании интеграции, вызванном построением службы X или выполняемой на регулярной основе. С проектом это осложняет сильную и надежную философию модульных тестов и интеграционную тестовую платформу.

Answer 2

Это хорошо подходит для вашего местоположения/обнаружения. Вся одна служба должна знать, куда отправить запрос X, чтобы получить ответ Y от конкретной службы. Если это хорошо реализовано. вы могли бы очень хорошо, чтобы каждый разработчик выполнял все подмножества сервисов, которые он непосредственно работает на локальном компьютере, и остальные службы запускаются в общей среде (назовем его удаленным)

Пульт будет настроен для запуска всех служб в вашем платформу и будет иметь некоторый способ получить последний код (основанный на каденции или на основе регулярных интервалов). Локальные среды могут быть настроены так, чтобы все службы, запущенные локально, знали, что еще работает локально, и будут знать, как добраться до удаленных служб, когда им нужна какая-либо информация. Для среды разработчиков добавьте соглашения, в которых каждый разработчик запускает минимальное количество услуг, необходимых для продуктивной разработки. Это означает, что если вы не работаете с кодом службы, запустите его удаленно, чтобы вы знали, что используете последний код и не устарели.

Пара подводных камней с таким подходом

1. можно запустить услугу А на местном уровне и имеют службы B работает на пульте дистанционного управления. вы проверяете все на местном уровне и, похоже, работаете, поэтому вы решаете нажать. Пока вы нажимаете, другой разработчик также подталкивает изменения к B, и теперь ваши изменения более несовместимы.
2. Если вы выполняете локальные службы A и C локально и B удаленно, это должно быть довольно прямолинейно для направления запросов на обслуживание B в удаленную среду.Тем не менее, вы должны быть осторожны, что если A называет B и B вызывает C, вызов C необходимо перенаправить из удаленной среды на локальную службу C, а не на вашу службу Remote C.
3. Тестирование. Вы можете преодолеть множество проблем, связанных с тестированием в сложной среде, например, иметь два отдельных набора тестов. 1. единичные тесты - тесты, которые проверяют отдельные компоненты в вашем сервисе, при этом все звонки на другое обслуживание высмеиваются. 2. Тесты интеграции среды - эти тесты подтверждают связь между различными службами. Suite 1 проверит внутренний код вашей службы, а Suite 2 будет запущен после того, как вы нажмете свои изменения на удаленный, и будете постоянно следить за тем, чтобы межсервисная связь была как ожидается.

Надежда, что помогает