2

我的目标是让以前的版本是不可变的：它们的定义和功能不应该改变。API 是使用基于 .NET 4.7.2（依赖原因）的 ASP.NET Core 构建的，并作为 Azure 应用服务托管。

最好，我不想通过添加“版本知识”来弄乱我的代码。此外，如果版本可以托管在相同的基本 URL 下，那也很好。

我的研究：

  1. ASP.NET API 版本控制

有了这个，您可以完全控制应用程序中的版本控制。但是当新版本发布时，所有旧版本也会更新，因此可以更改。这意味着您不能改变任何现有函数，但必须创建新版本，就像 Scott 在 URL PATH SEGMENT VERSIONING 中所做的那样。

  1. Azure 部署槽

正如文档所解释的，这应该用于分期。但是，这也可以用于“存储”您的版本，因为每个部署槽都是托管的，彼此之间没有任何关系。

  1. 虚拟应用程序

将版本托管为虚拟应用程序也是一种选择。但是，应用服务的所有设置都在这些虚拟应用程序之间共享。这意味着在更改任何设置时，这将影响每个版本。

  1. 用于容器的 Azure Web 应用

我对此的了解有限，但从我所阅读的内容来看，这也是一种选择。根据应用程序的版本创建图像，将这些图像上传到Azure Container Registery。然后使用这些图像为每个版本创建一个应用服务。

4

2 回答 2

2

最好的方法是适合您的用例的方法 - 您提出的所有方法都是有效的。

如果您希望能够在不更改任何代码来进行版本控制的情况下进行单独的设置，那么您可以选择部署槽和容器。在这两者之间，如果您不熟悉 Docker，插槽会更容易使用。

正如您所提到的，虚拟应用程序做了类似的事情，但您不能分离配置。

请记住，这意味着在同一个应用服务上运行您的应用的多个副本，因此您需要适当地扩展它。这可能是使用 API 版本控制的最大优势，即使它确实意味着一些不同的编码实践。您仍然只运行一个副本。随着您获得越来越多的版本，运行应用程序的多个副本的成本将会上升，除非您开始弃用旧版本。

所有 Azure 网站都使用 https://{app_name}.azurewebsites.net 网址，因此从技术上讲，它们都具有相同的基础。如果您正在寻找它们都具有相同的子域，那么 API 版本控制或虚拟应用程序是可行的方法，除非您想构建一些重定向逻辑。当然，使用自定义域，您可以更好地控制 DNS 记录的映射方式。

于 2020-01-21T21:41:08.747 回答
1

@SamaraSoucy-MSFT 是正确的 - 所有选项都有效。最好的方法是非常主观的，但我将进一步详细说明 API 版本控制的具体选项。

API 版本控制与您的基础架构正交。如果您想将事物拆分为单独的应用程序或添加其他级别的隔离，这是一种受支持的方案。版本广告的概念对此进行了详细描述。简而言之，您的应用程序可以做广告未在该特定实现中托管的 API 版本。版本广告的实现方式有很多种，因此没有具体的指导。在最简单的模型中，您只需使用新的约定、属性等更新您的应用程序。但是，很可能希望不对现有部署进行任何更改。这意味着您需要想出一种方法来在应用程序之外更新此信息（例如：config、db 等）或放弃版本广告。这部分取决于每个实现的隔离程度。如果您不关心广告可用或已弃用的 API 版本，那么这不是问题。

使用 API 版本控制至少有 4 种方法可以实现您的目标。

选项 1 - 复制、粘贴、替换

复制、粘贴、替换(CPR) 方法涉及从字面上将服务的先前版本复制并粘贴到新文件夹和新代码命名空间中。这在不更改原始版本的情况下形成了先前版本的新版本的基线。然后根据需要替换新版本中的差异。这个过程可以重复多久，只要你愿意。

如果版本之间的更改相当小，这可能是一个非常简单且有效的策略。一个关键的缺点是随着时间的推移膨胀和实现耦合。如果您有可靠的版本控制策略（例如N-2），那么可以最大限度地减少影响。最大的挑战是进行重大的实施更改，这对共同主持没有意义或可能导致更改以前的版本。这样的示例将尝试在同一实现中1.0使用 ASP.NET Web API 和ASP.NET Core 托管。2.0

我已经看到这种方法使用了几次，它可能是有效的。

选项 2 - 注入和编写

在此变体中，您将在单独的 API 程序集中实现每个版本。您将拥有一个 API 主机应用程序，该应用程序从每个版本化程序集中注入和组合所有 API。这提供了实现之间的完全隔离，仍然具有 API 版本控制的所有好处。

像选项 1一样，您仍然必须考虑臃肿；特别是因为每个程序集可能具有不同的依赖项。托管为不同平台编写的 API 也非常困难，但在技术上应该是可行的。

选项 3 - 主机头映射

大多数 Web 服务器都有某种方式将Host标头映射到不同的应用程序。您可以使用此技术将应用程序的每个版本托管为独立的应用程序。

选项 4 - 网关

使用网关提供了最大的灵活性，但设置起来可能最具挑战性。此方法可以使用任意数量的路由方法，例如 DNS、URL 重写或基于请求中可用版本信息的 URL 重定向。端点很可能是一个孤立的应用程序，例如在选项 3中。网关负责将请求转发或重定向到正确的版本端点。

我松散地使用术语网关。这可以是现有的服务或平台、基于硬件的或您自己的定制设计。这将取决于您的需求以及开箱即用的解决方案是否可以满足这些需求。

其他注意事项

这些当然不是唯一的选择，也不是相互排斥的。您可以组合它们的任何变体以满足您的需求。

选择选项 3或选项 4将对 API 版本控制带来一些挑战，因为物理隔离屏障超越了每个已部署的应用程序。您要么需要想出一种方法来更新广告版本，要么完全放弃这个概念 - 如上所述。如果您最终根本没有发布版本，那么每个部署的实现都应该是一个单独的、独立的代码库，这可能根本不需要 API 版本控制，因为它是在抽象层处理的。

您的整体版本控制策略和政策也将发挥作用。如果您在您的服务中使用对称版本，则 URL 设计和 API 版本是一致的，但会附带添加的部署来满足此要求。如果您选择拥有独立的、不断发展的服务，那么版本发现和广告就会变得更加有趣。例如，您的政策可能规定已弃用的版本将在 6 个月后停用。然后，客户端应通过检测响应标头来检测此广告。api-deprecated-versions可以通过HEADand/orOPTIONS方法支持版本发现。

于 2020-02-17T22:06:02.647 回答