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

以上主要是 .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 -

分享、點贊、再看，三連走一波

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的.NET Core 服务在 ARM64 服务器中的部署的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。