岳阳网站优化公司,模版破解免费wordpress,外贸推广网站建设,打开官方网站浏览器Linux 服务器 CPU 架构主要可分为#xff1a;X86_64/AMD64、ARM64/AARCH64 两大类#xff0c;大多情况使用的都是基于 AMD64 CPU 架构的服务器。但随着国产操作系统、CPU 等自主生态打造的应用产品得到越来越多的用户认可和应用#xff0c;如#xff1a;华为鲲鹏、统信 UOS… 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.KafkaKafka 操作的封装库会出现如下错误Unhandled exception. System.DllNotFoundException: Failed to load the librdkafka native library.at Confluent.Kafka.Impl.Librdkafka.Initialize(String userSpecifiedPath)at Confluent.Kafka.Consumer2..ctor(ConsumerBuilder2 builder)at Confluent.Kafka.ConsumerBuilder2.Build()
该问题的原因是在发布代码中并不包含在 linux-arm64 运行所需的 librdkafka.so解决方法其实比较简单因为我们的项目引用的 Confluent.Kafka NuGet 包版本相对较低在高版本中已包含对 linux-arm64 的支持所以只需要对引用了 Confluent.Kafka 的项目基础包进行升级然后相关服务升级基础包即可。服务启动时加载 Grpc.CoregRPC 核心实现会出现如下错误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, IEnumerable1 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.1git 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_TESTSOFF -DCMAKE_BUILD_TYPE${MSBUILD_CONFIG} ../..
make -j4 grpc_csharp_ext
获取 libgrpc_csharp_ext.socp 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?viewaspnetcore-5.0tabsvisual-studio[2]从 ASP.NET Core 3.0 迁移到 3.1: https://docs.microsoft.com/zh-cn/aspnet/core/migration/30-to-31?viewaspnetcore-5.0tabsvisual-studio- END -分享、点赞、再看三连走一波
