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

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

该项目的大概背景如下：

• 基于多个 .NET Core 服务构成的微服务架构系统

• 基于 gRPC 实现的微服务应用

• 基于主流中间件，如：Mongodb、Redis、Kafka、Zookeeper

当时提出整个项目需要支持在 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.so、libgrpc_csharp_ext.x64.so，很显然也是没有对应 linux-arm64 的版本。与 Confluent.Kafka 不同，官方并没有打算默认支持的意思，只是提到如果需要可自行基于源代码编译。在 Github 的 Issue 讨论中也看到另外一种解决方案，可是将 Grpc.Core 替换成 dotnet-grpc ，dotnet-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.so、libgrpc_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 ^[1] 和 从 ASP.NET Core 3.0 迁移到 3.1^[2] 。

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

参考资料

[1]

从 ASP.NET Core 2.2 迁移到 3.0 : https://docs.microsoft.com/zh-cn/aspnet/core/migration/22-to-30?view=aspnetcore-5.0&tabs=visual-studio

[2]

从 ASP.NET Core 3.0 迁移到 3.1: https://docs.microsoft.com/zh-cn/aspnet/core/migration/30-to-31?view=aspnetcore-5.0&tabs=visual-studio

- END -

分享、点赞、再看，三连走一波