Как обработать обновление схемы базы данных в микросервисе

Question

Мы начнем с этой схемы

CREATE TABLE [dbo].[Label]
(
    [Id] UNIQUEIDENTIFIER NOT NULL PRIMARY KEY, 
    [Prefix] VARCHAR(50) NOT NULL UNIQUE,
    [ArtistName] VARCHAR(MAX) NOT NULL
)

У нас также есть микросервис, который управляет «метками».http://labels.example.com/v1/all вернет все метки в этом формате:

{ Id = xxx, Prefix = xxx, ArtistName = xxx }

Как мы обрабатываем изменение схемы, которое не затрагивает потребителей этого микросервиса?

Мы должны сделать некоторыерефакторинг и художник перемещается к своему собственному столу.

CREATE TABLE [dbo].[Label]
(
    [Id] UNIQUEIDENTIFIER NOT NULL PRIMARY KEY, 
    [Prefix] VARCHAR(50) NOT NULL UNIQUE,
    [ArtistId] UNIQUEIDENTIFIER NOT NULL,

    CONSTRAINT FK_Label_Artist
        FOREIGN KEY (ArtistId) REFERENCES Artist(Id)
)

CREATE TABLE [dbo].[Artist]
(
    [Id] UNIQUEIDENTIFIER NOT NULL PRIMARY KEY, 
    [Name] VARCHAR(MAX) NOT NULL,
    [Country] VARCHAR(MAX) NOT NULL
)

Наш микросервис должен будет вернуть следующий объект

{ Id = xxx, Prefix = xxx, Artist = { Id = xxx, Name = xxx, Country = xxx } }

Нам нужно будет создать вызов API v2, который возвращает этот новыйсостав.Нам также придется перенести данные в новую структуру.Это означает, что v1 также нужно изменить для поддержки новой схемы, но он по-прежнему будет возвращать тот же объект.

Так ли это происходит при создании версии микросервиса?Что нужно иметь в виду?Есть ли другой способ сделать это?

Answer 1

Звучит так, как будто вы на правильном пути.Архитектурный стиль микросервисов был изобретен, чтобы позволить организациям создавать логически разделенные команды разработчиков с четко определенными интерфейсами.Интерфейсы, являющиеся API-интерфейсом службы или чем-либо еще, доступным для потребителей.

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

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

Короче говоря, относитесь к своим внутренним зависимостям так же, как с внешними зависимостями.

Некоторые дополнительные мысли:

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

  { Id = xxx, Prefix = xxx,  ArtistName = xxx, Artist = { Id = xxx, Name = xxx, Country = xxx } }
  

  Здесь вы заплатите избыточностью данных для обеспечения совместимости.

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

• Вы можете использовать схему версии, чтобы указатькритические изменения: например, незначительное изменение версии 1.1 совместимо с версией 1.0, но основное изменение версии 2.0 несовместимо с 1.1.

• Клиентские адаптеры: иногда API-интерфейсы поставляются с клиентскими библиотеками для обеспечения доступаболее простой и независимый от транспортного формата и т. д. В этом случае клиентская библиотека также должна иметь правильные версии и должна поддерживать все активные версии.

• Инструменты: ознакомьтесь с такими стандартами, как GraphQL, которыепомочь с большим количеством задач, связанных с API.

Answer 2

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