Создание микросервисов

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

Метаверсия

По окончании сквозного тестирования вполне можно прийти к мысли: раз все эти сервисы данной версии могут работать вместе, почему бы их вместе и не развернуть? Вскоре это превращается в разговор о том, почему бы не воспользоваться номером версии для всей системы. Все по Брэндону Брайарсу (Brandon Bryars): «Теперь у вас 2.1.0 проблем».

Объединяя в единую версию изменения, внесенные сразу в несколько сервисов, мы фактически принимаем идею приемлемости одновременного изменения и развертывания сразу нескольких сервисов. Это становится нормой, не вызывающей сомнений. Поступая таким образом, мы отказываемся от одного из основных преимуществ микросервисов — возможности развертывания отдельно взятого сервиса независимо от всех других сервисов.

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

И в этом нет ничего хорошего.

Тестируйте маршруты, а не истории

Несмотря на указанные недостатки, при использовании одного или двух сервисов многие пользователи все же смогут справиться с управлением сквозными тестами, проведение которых в подобных ситуациях представляется вполне разумным действием. А что, если используются 3, 4, 10 или 20 сервисов? Очень быстро эти наборы тестов станут весьма сильно раздутыми, что в худшем случае приведет к взрывному росту тестируемых сценариев.

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

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

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

Тесты на основе запросов потребителей, спасающие ситуацию

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

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