ML.NET机器学习API容器化与Azure DevOps实践：RESTful API

Posted 2021-04-16 移动开发和人工智能

通过上文所述案例，我们已经选择了最优回归算法来预测学生的综合成绩，并且完成了基于训练数据集的预测模型训练。从实现上，训练好的模型被保存成一个ZIP文件，以便在其它项目中直接调用以完成机器学习的实践场景。在本文中，我将介绍如何在ASP.NET Core中使用这个ZIP文件，以提供用于学生成绩预测的RESTful API。

我们已经得到了经过ML.NET训练好的模型数据文件，也就是一个ZIP文件，在开发的RESTful API中，需要读入这个文件以便实现预测功能。于是，ZIP文件保存在何处就成为了我们首要解决的问题。在开发环境，我们可以将ZIP文件保存在ASP.NET Core的运行目录中，可是，开发好的RESTful API最终还是要部署到生产环境，这种部署有可能是单节点的，也有可能是位于负载均衡服务器后端的多节点部署，而且模型文件也会随着训练数据集的增加或变化进行增量式更新，因此，依赖于部署环境的本地文件系统并不是一个好的做法。因此，我选择将模型文件保存在Azure Blob Storage中。

注意：为了防止在开发调试阶段过多使用Azure Blob Storage的流量，我们可以在ASP.NET Core的应用程序中实现两套模型数据供应器：一套从本地文件系统读入模型，用于开发环境，另一套从Azure Blob Storage读入模型，用于生产环境，然后通过ASP.NET Core的Hosting Environment进行区分以选择不同的供应器。

我们首先登录Microsoft Azure的主页，在主页中创建一个新的Storage Account。注意：我这里使用的是Global的Azure，对于由世纪互联运营的Azure，操作过程有可能不一样。

创建过程就不一一赘述了，根据自己的需要和钱包的厚度来决定所需的配置，待创建完成后，进入Storage Account的Access keys页面，注意其中的Connection string部分的值，接下来构建RESTful API的时候，需要用到这些值。值得一提的是，Azure会同时给你提供两个不同的Key和Connection String，因为经常更换Access key将会是一个良好的习惯，为了防止Access key更新时，应用程序无法正常工作，因此会有一个备用Key来保证程序的正常运行。我们先不管Azure Key Vault的事情，目前先把其中的某个Key复制下来。

然后，进入Blobs服务，新建一个容器（Container），比如命名为mlnetmodel，这个名字也要记下来。之后，在容器中上传我们的模型文件即可，如下：

在准备好模型文件之后，我们就可以开始开发RESTful API了。

打开宇宙第一最强IDE Visual Studio，我用的是2019的版本，新建一个ASP.NET Core的应用程序，启用docker支持，因为我们接下来会将这个应用程序编译成docker镜像，以便在容器中运行。详细的项目创建过程以及RESTful API实现过程我也就不多说明了，网上相关资料实在太多了。这里只强调几个需要重点注意的地方。

首先需要添加如下NuGet包的引用，由于我们需要使用ML.NET，并且需要访问Azure Blob Storage，因此，以下依赖项不可缺少：

• Microsoft.ML

• Microsoft.Azure.Storage.Blob

有点小坑的地方是，当你直接引用Microsoft.Azure.Storage.Blob时，编译项目会出错，提示所依赖的Microsoft.Azure.KeyVault.Core不支持.NET Standard。解决办法就是手工添加Microsoft.Azure.KeyVault.Core的依赖，我使用的是3.0.3的版本。

接下来，通过ASP.NET Core的配置系统，从配置数据中读入访问Azure Blob Storage所需的连接字符串参数，然后初始化Storage Account以及Blob Client对象，以便将保存在Azure Blob Storage中的模型文件下载下来。代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public void ConfigureServices(IServiceCollection services) {     services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);     var defaultEndpointsProtocol = Configuration[BlobProtocolConfigName];     var accountName = Configuration[BlobAccountNameConfigName];     var accountKey = Configuration[BlobAccountKeyConfigName];     var endpointSuffix = Configuration[BlobEndpointSuffixConfigName];     var connectionString = $@"DefaultEndpointsProtocol={defaultEndpointsProtocol}; AccountName={accountName}; AccountKey={accountKey}; EndpointSuffix={endpointSuffix}";     var storageAccount = CloudStorageAccount.Parse(connectionString);     var blobClient = storageAccount.CreateCloudBlobClient();     var mlnetContainer = blobClient.GetContainerReference("mlnetmodel");     var blob = mlnetContainer.GetBlobReference("student_perf_model.zip");     using (var ms = new MemoryStream())     {         blob.DownloadToStream(ms);     } }

上面高亮的代码，通过blob对象，将模型文件下载到MemoryStream中。问题来了，干嘛不保存在本地文件中呢？因为我们接下来需要使用的ML.NET中的PredictionEngine（预测引擎）不是线程安全的，我们只能通过services.AddScoped方法来注册PredictionEngine的实例，也就是说，每当有一个新的HTTP请求到来时，PredictionEngine实例都需要构建一次，而PredictionEngine的构建是需要访问模型文件的，频繁的访问文件系统中的文件会损耗应用程序的性能。

因此，我构建了下面的数据结构，用来保存下载的模型数据：

1 2 3 4 5 6 7 8 9

public class ModelData {     public ModelData(byte[] dataBytes)     {         this.DataBytes = dataBytes;     }     public byte[] DataBytes { get; } }

于是，上面的blob.DownloadToStream这部分代码，就可以改写为：

1 2 3 4 5

using (var ms = new MemoryStream()) {     blob.DownloadToStream(ms);     services.AddSingleton(new ModelData(ms.ToArray())); }

然后，通过如下方法来注册PredictionEngine实例：

1 2 3 4 5 6 7 8 9 10 11

services.AddScoped(serviceProvider => {     var mlContext = serviceProvider.GetRequiredService<MLContext>();     var dataStream = serviceProvider.GetRequiredService<ModelData>().DataBytes;     using (var modelStream = new MemoryStream(dataStream))     {         var model = mlContext.Model.Load(modelStream);         return model.CreatePredictionEngine<StudentTrainingModel, StudentPredictionModel>(mlContext);     } });

现在，我们已经完成了模型文件的下载，以及PredictionEngine实例的注册，接下来就非常简单了，只需要在API Controller中，使用构造器注入的PredictionEngine实例来实现我们的预测功能即可。代码非常简单：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

[Route("api/[controller]")] [ApiController] public class StudentsController : ControllerBase {     private readonly PredictionEngine<StudentTrainingModel, StudentPredictionModel> predictionEngine;     public StudentsController(PredictionEngine<StudentTrainingModel, StudentPredictionModel> predictionEngine)     {         this.predictionEngine = predictionEngine;     }     [HttpPost("predict")]     public IActionResult Predict([FromBody] StudentTrainingModel model)         => Ok(predictionEngine.Predict(model)); }

至此，API编写完成，将API运行起来，并进行简单的测试：

测试成功。cURL命令从本地文件data.json中读入学生问卷调查数据，并预测他的综合成绩是12.8184786分（实际是9分，还是有点偏差）。

由于在创建ASP.NET Core应用程序时，已经选择了docker支持，因此，我们可以直接使用docker build命令来编译镜像，并使用docker run来运行容器。当然，在Windows环境下需要安装Docker for Windows，不过这里就不多说明安装步骤了，在我以前的博客中有详细介绍。为了方便编译和运行容器，我在ASP.NET Core的上层目录中建了一个docker-compose.yml文件，以使用docker compose来实现容器镜像的编译与容器的运行。在这里我强调“上层目录”，因为，docker-compose.yml文件中，已经通过相对路径指定了docker build的context路径。docker-compose.yml文件内容如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

version: '3' services:   mlnet_webapi:     image: daxnet/mlnet_webapi     build:       context: .       dockerfile: mlnet_webapi/Dockerfile     environment:       - BLOB_ACCOUNT_NAME=${BLOB_ACCOUNT_NAME}       - BLOB_DEFAULT_ENDPOINTS_PROTOCOL=${BLOB_DEFAULT_ENDPOINTS_PROTOCOL}       - BLOB_ENDPOINT_SUFFIX=${BLOB_ENDPOINT_SUFFIX}       - BLOB_ACCOUNT_KEY=${BLOB_ACCOUNT_KEY}       - Serilog__MinimumLevel=${Serilog__MinimumLevel:-Debug}     container_name: mlnet_webapi     ports:       - 880:80       - 8443:443

值得一提的是，文件中环境变量都是通过.env文件注入进来的，因此，访问Azure Blob Storage的Connection String相关信息不会签入到Github代码库中。

使用docker-compose up命令一键编译并启动容器，再次访问我们的API以确保程序能够正常工作：

本文主要介绍了如何在ASP.NET Core项目中使用ML.NET产生的训练模型，并向外界提供RESTful API，案例使用了容器技术，使得所生成的RESTful API应用能够在容器中运行，以便为下一步的持续部署做铺垫。在下文中，我将介绍基于Azure DevOps的持续集成与持续部署。