Linux 服務(wù)器 CPU 架構(gòu)主要可分為：X86_64/AMD64、ARM64/AARCH64 兩大類(lèi)，大多情況使用的都是基于 AMD64 CPU 架構(gòu)的服務(wù)器。但隨著國(guó)產(chǎn)操作系統(tǒng)、CPU 等自主生態(tài)打造的應(yīng)用產(chǎn)品得到越來(lái)越多的用戶(hù)認(rèn)可和應(yīng)用，如：華為鯤鵬、統(tǒng)信 UOS 這類(lèi)服務(wù)器不斷被采購(gòu)使用，而它們均有采用 ARM64 CPU 架構(gòu)，所以 .NET 程序如果需要在更多的國(guó)產(chǎn)服務(wù)器中運(yùn)行，適配 ARM64 CPU 架構(gòu)將是開(kāi)始的第一步。

本文的介紹并不是一個(gè)簡(jiǎn)單的 Demo 示例，而是基于一個(gè)較大項(xiàng)目適配 ARM64 架構(gòu)改造的經(jīng)驗(yàn)分享。

該項(xiàng)目的大概背景如下：

• 基于多個(gè) .NET Core 服務(wù)構(gòu)成的微服務(wù)架構(gòu)系統(tǒng)
• 基于 gRPC 實(shí)現(xiàn)的微服務(wù)應(yīng)用
• 基于主流中間件，如：Mongodb、Redis、Kafka、Zookeeper

當(dāng)時(shí)提出整個(gè)項(xiàng)目需要支持在 ARM64 CPU 架構(gòu)的服務(wù)器中進(jìn)行部署時(shí)，其實(shí)并沒(méi)有太多擔(dān)憂(yōu)，因?yàn)?.NET Core 的跨平臺(tái)能力與生俱來(lái)，所以隨便找了個(gè)服務(wù)來(lái)測(cè)試，結(jié)果馬上被打臉了，跑不起來(lái)。接著一度懷疑是運(yùn)行環(huán)境的問(wèn)題，嘗試多次重裝 .NET Core SDK，并測(cè)試了多個(gè)版本，結(jié)果還是失敗。經(jīng)過(guò)一番研究與確認(rèn)，主要是以下3個(gè)問(wèn)題：

1. 服務(wù)啟動(dòng)時(shí)加載 Confluent.Kafka（Kafka 操作的封裝庫(kù)）會(huì)出現(xiàn)如下錯(cuò)誤：

   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()
   

   該問(wèn)題的原因是在發(fā)布代碼中并不包含在 linux-arm64 運(yùn)行所需的 librdkafka.so，解決方法其實(shí)比較簡(jiǎn)單，因?yàn)槲覀兊捻?xiàng)目引用的 Confluent.Kafka NuGet 包版本相對(duì)較低，在高版本中已包含對(duì) linux-arm64 的支持，所以只需要對(duì)引用了 Confluent.Kafka 的項(xiàng)目基礎(chǔ)包進(jìn)行升級(jí)，然后相關(guān)服務(wù)升級(jí)基礎(chǔ)包即可。

2. 服務(wù)啟動(dòng)時(shí)加載 Grpc.Core（gRPC 核心實(shí)現(xiàn)）會(huì)出現(xiàn)如下錯(cuò)誤：

   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)
   

   該問(wèn)題相對(duì)復(fù)雜很多，引用 Grpc.Core 后，程序在發(fā)布時(shí)也會(huì)生成對(duì)應(yīng)運(yùn)行平臺(tái)的 runtime 文件 libgrpc_csharp_ext.x86.so、libgrpc_csharp_ext.x64.so，很顯然也是沒(méi)有對(duì)應(yīng) linux-arm64 的版本。與 Confluent.Kafka 不同，官方并沒(méi)有打算默認(rèn)支持的意思，只是提到如果需要可自行基于源代碼編譯。在 Github 的 Issue 討論中也看到另外一種解決方案，可是將 Grpc.Core 替換成 dotnet-grpc ，dotnet-grpc 是官方隨 .NET Core 3.0 一起發(fā)布的一個(gè) gRPC 擴(kuò)展組件，沒(méi)有額外的 runtime 文件的依賴(lài)，但是替換成 dotnet-grpc 的時(shí)間成本相對(duì)較高（雖然這條路看上去之后還是得走，gRPC 在 C# 中的未來(lái)屬于grpc-dotnet ），所以當(dāng)前選擇了自編譯的方式。

   以下是基于 Debian ARM64 CPU 架構(gòu)服務(wù)器上編譯操作。

   安裝基礎(chǔ)依賴(lài)組件

   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 源碼（項(xiàng)目當(dāng)前使用是 v1.22.1）

   git clone -b v1.22.1 https://github.com/grpc/grpc
   cd grpc
   
   # 獲取依賴(lài)的子模塊
   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 工具中對(duì)發(fā)布的程序文件進(jìn)行二次替換即可解決報(bào)錯(cuò)問(wèn)題。

3. ASP.NET Core Runtime 版本問(wèn)題，官方并沒(méi)有提供 ASP.NET Core Runtime 2.2.x 對(duì)應(yīng)的 ARM64 版本

   針對(duì)此問(wèn)題的處理方式還是比較果斷的，那就是全面升級(jí)到 3.1，首先 3.1 是 LTS 版本，且提供了 ARM64 對(duì)應(yīng)的 runtime，另外因?yàn)橹耙呀?jīng)升級(jí)過(guò)一波，目前基于 2.2 的服務(wù)殘留的并不多，當(dāng)然整個(gè)升級(jí)改造過(guò)程還是需要謹(jǐn)慎，可參考：從 ASP.NET Core 2.2 遷移到 3.0 和 從 ASP.NET Core 3.0 遷移到 3.1 。

以上主要是 .NET Core 服務(wù)本身適配 ARM64 服務(wù)器部署遇到的一些問(wèn)題，不過(guò)不同的項(xiàng)目還是會(huì)面對(duì)不一樣的情況，解決后目前來(lái)看一切正常。當(dāng)然這還不包含其他配套組件的改造，比如：MySQL 替換成 MariaDB 等。