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.KafkaNuGet 包版本相对较低，在高版本中已包含对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 和 从 ASP.NET Core 3.0 迁移到 3.1 。
以上主要是 .NET Core 服务本身适配 ARM64 服务器部署遇到的一些问题，不过不同的项目还是会面对不一样的情况，解决后目前来看一切正常。当然这还不包含其他配套组件的改造，比如：MySQL 替换成 MariaDB 等。
