.NET Core 服务在 ARM64 服务器中的部署

Linux 服务器 CPU 架构主要可分为:X86_64/AMD64ARM64/AARCH64 两大类,大多情况使用的都是基于 AMD64 CPU 架构的服务器。但随着国产操作系统、CPU 等自主生态打造的应用产品得到越来越多的用户认可和应用,如:华为鲲鹏、统信 UOS 这类服务器不断被采购使用,而它们均有采用 ARM64 CPU 架构,所以 .NET 程序如果需要在更多的国产服务器中运行,适配 ARM64 CPU 架构将是开始的第一步。

本文的介绍并不是一个简单的 Demo 示例,而是基于一个较大项目适配 ARM64 架构改造的经验分享。

该项目的大概背景如下:

  • 基于多个 .NET Core 服务构成的微服务架构系统
  • 基于 gRPC 实现的微服务应用
  • 基于主流中间件,如:MongodbRedisKafkaZookeeper

当时提出整个项目需要支持在 ARM64 CPU 架构的服务器中进行部署时,其实并没有太多担忧,因为 .NET Core 的跨平台能力与生俱来,所以随便找了个服务来测试,结果马上被打脸了,跑不起来。接着一度怀疑是运行环境的问题,尝试多次重装 .NET Core SDK,并测试了多个版本,结果还是失败。经过一番研究与确认,主要是以下3个问题:

  1. 服务启动时加载 Confluent.Kafka(Kafka 操作的封装库)会出现如下错误:

    Unhandled exception. System.DllNotFoundException: Failed to load the librdkafka native library.
      at Confluent.Kafka.Impl.Librdkafka.Initialize(String userSpecifiedPath)
      at Confluent.Kafka.Consumer`2..ctor(ConsumerBuilder`2 builder)
      at Confluent.Kafka.ConsumerBuilder`2.Build()
    

    该问题的原因是在发布代码中并不包含在 linux-arm64 运行所需的 librdkafka.so,解决方法其实比较简单,因为我们的项目引用的 Confluent.Kafka NuGet 包版本相对较低,在高版本中已包含对 linux-arm64 的支持,所以只需要对引用了 Confluent.Kafka 的项目基础包进行升级,然后相关服务升级基础包即可。

  2. 服务启动时加载 Grpc.Core(gRPC 核心实现)会出现如下错误:

    Unhandled exception. System.IO.IOException: Error loading native library "/usr/local/temp/program/publish/runtimes/linux/native/libgrpc_csharp_ext.x64.so". 
      at Grpc.Core.Internal.UnmanagedLibrary..ctor(String[] libraryPathAlternatives)
      at Grpc.Core.Internal.NativeExtension.LoadUnmanagedLibrary()
      at Grpc.Core.Internal.NativeExtension.LoadNativeMethods()
      at Grpc.Core.Internal.NativeExtension..ctor()
      at Grpc.Core.Internal.NativeExtension.Get()
      at Grpc.Core.Internal.NativeMethods.Get()
      at Grpc.Core.GrpcEnvironment.GrpcNativeInit()
      at Grpc.Core.GrpcEnvironment..ctor()
      at Grpc.Core.GrpcEnvironment.AddRef()
      at Grpc.Core.Channel..ctor(String target, ChannelCredentials credentials, IEnumerable`1 options)
      at Grpc.Core.Channel..ctor(String target, ChannelCredentials credentials)
    

    该问题相对复杂很多,引用 Grpc.Core 后,程序在发布时也会生成对应运行平台的 runtime 文件 libgrpc_csharp_ext.x86.solibgrpc_csharp_ext.x64.so,很显然也是没有对应 linux-arm64 的版本。与 Confluent.Kafka 不同,官方并没有打算默认支持的意思,只是提到如果需要可自行基于源代码编译。在 Github 的 Issue 讨论中也看到另外一种解决方案,可是将 Grpc.Core 替换成 dotnet-grpcdotnet-grpc 是官方随 .NET Core 3.0 一起发布的一个 gRPC 扩展组件,没有额外的 runtime 文件的依赖,但是替换成 dotnet-grpc 的时间成本相对较高(虽然这条路看上去之后还是得走,gRPC 在 C# 中的未来属于grpc-dotnet ),所以当前选择了自编译的方式。

    以下是基于 Debian ARM64 CPU 架构服务器上编译操作。

    安装基础依赖组件

    sudo apt-get install build-essential autoconf libtool pkg-config
    sudo apt-get install libgflags-dev libgtest-dev
    sudo apt-get install clang libc++-dev
    sudo apt-get install cmake
    

    拉取 grpc 源码(项目当前使用是 v1.22.1)

    git clone -b v1.22.1 https://github.com/grpc/grpc
    cd grpc
    
    # 获取依赖的子模块
    git submodule update --init
    

    编译

    mkdir -p cmake/build
    cd cmake/build
    cmake -DgRPC_BUILD_TESTS=OFF -DCMAKE_BUILD_TYPE="${MSBUILD_CONFIG}" ../..
    make -j4 grpc_csharp_ext
    

    获取 libgrpc_csharp_ext.so

    cp libgrpc_csharp_ext.so ../../../libgrpc_csharp_ext.x86.so
    cp libgrpc_csharp_ext.so ../../../libgrpc_csharp_ext.x64.so
    

    得到 libgrpc_csharp_ext.x86.solibgrpc_csharp_ext.x64.so 之后,在 CI 工具中对发布的程序文件进行二次替换即可解决报错问题。

  3. ASP.NET Core Runtime 版本问题,官方并没有提供 ASP.NET Core Runtime 2.2.x 对应的 ARM64 版本

    针对此问题的处理方式还是比较果断的,那就是全面升级到 3.1,首先 3.1 是 LTS 版本,且提供了 ARM64 对应的 runtime,另外因为之前已经升级过一波,目前基于 2.2 的服务残留的并不多,当然整个升级改造过程还是需要谨慎,可参考:从 ASP.NET Core 2.2 迁移到 3.0 和 从 ASP.NET Core 3.0 迁移到 3.1 。

以上主要是 .NET Core 服务本身适配 ARM64 服务器部署遇到的一些问题,不过不同的项目还是会面对不一样的情况,解决后目前来看一切正常。当然这还不包含其他配套组件的改造,比如:MySQL 替换成 MariaDB 等。

你可能感兴趣的:(.NET Core 服务在 ARM64 服务器中的部署)