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

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个问题：

服务启动时加载 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 的项目基础包进行升级，然后相关服务升级基础包即可。

服务启动时加载 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 工具中对发布的程序文件进行二次替换即可解决报错问题。

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] 。