.NET Core 服务在 ARM64 服务器中的部署
Posted dotNET跨平台
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了.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个问题:
服务启动时加载
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 服务器中的部署的主要内容,如果未能解决你的问题,请参考以下文章
实战ASP.NET Core 6 部署在 ARM 树莓派实现 DDNS 和网络唤醒