database - 如何在微服务中处理数据库架构更新

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 }

我们如何处理不影响此微服务消费者的架构更改？

我们必须进行一些重构，美 worker 员会搬到他自己的 table 上。

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 } }

我们将不得不创建一个返回这个新结构的 v2 api 调用。我们还必须将数据迁移到新结构。这意味着 v1 也需要更改以支持新架构，但它仍将返回相同的对象。

当您对微服务进行版本控制时，这是完成工作的方式吗？要记住的事情？有没有其他方法可以做到这一点？

Answer 1

听起来您的方向是正确的。微服务架构风格的发明是为了允许组织构建具有明确定义的接口(interface)的逻辑上分离的开发团队。接口(interface)是服务 API 或向消费者公开的任何其他内容。

数据库模式应该是服务内部的，因此随着时间的推移而发展成为您常规开发过程的一部分。仅当对您的服务消费者有影响(通过更改服务接口(interface))时，您才必须确保有正式的版本控制流程。

正式流程还应包括适用于外部依赖项的所有方面。您可以以 facebook 为例，因为他们会发布新版本的公共(public) 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 相关的任务。