Поделиться через

Создание, развитие и управление версиями API и контрактов микрослужбы

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

API микрослужбы — это контракт между службой и ее клиентами. Вы сможете развивать микрослужбу независимо только в том случае, если вы не прерываете контракт API, поэтому контракт так важен. Если изменить контракт, это повлияет на клиентские приложения или шлюз API.

Характер определения API зависит от используемого протокола. Например, если вы используете обмен сообщениями, например AMQP, API состоит из типов сообщений. Если вы используете службы HTTP и RESTful, API состоит из URL-адресов и форматов JSON запроса и ответа.

Тем не менее, даже если вы тщательно обдумали свой первоначальный контракт, API службы со временем потребуется изменить. Когда это происходит, особенно если API является общедоступным API, используемым несколькими клиентскими приложениями, обычно не удается принудительно обновить все клиенты до нового контракта API. Обычно необходимо постепенно развертывать новые версии службы таким образом, чтобы одновременно выполнялись как старые, так и новые версии контракта службы. Поэтому важно иметь стратегию для управления версиями служб.

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

Однако иногда необходимо внести основные и несовместимые изменения в API службы. Так как вы не сможете принудительно принудительно обновлять клиентские приложения или службы до новой версии, служба должна поддерживать более старые версии API в течение некоторого периода. Если вы используете механизм на основе HTTP, например REST, один из способов заключается в внедрении номера версии API в URL-адрес или в заголовок HTTP. Затем можно выбрать между реализацией обеих версий службы одновременно в одном экземпляре службы или развертыванием разных экземпляров, которые обрабатывают версию API. Хорошим подходом для этой функции является шаблон посредника (например, библиотека MediatR), чтобы разделить различные версии реализации на независимые обработчики.

Наконец, если вы используете архитектуру REST, Гипермедиа — это лучшее решение для версионирования ваших служб и поддержки развивающихся API.

Дополнительные ресурсы

НазадДалее