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