.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個問題：

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 和 從 ASP.NET Core 3.0 遷移到 3.1 。

以上主要是 .NET Core 服務本身適配 ARM64 服務器部署遇到的一些問題，不過不同的項目還是會面對不一樣的情況，解決後目前來看一切正常。當然這還不包含其他配套組件的改造，比如：MySQL 替換成 MariaDB 等。