arm板telnetd为什么运行不了_为什么越来越多企业正在往ARM平台迁移？

1. 架构变迁
说到CPU架构，我们可能必然会提到CISC(复杂指令集，比如桌面端采用的X86系列)和RISC(精简指令集，比如移动端广泛采用的ARM系列)。理论上，RISC 相比于 CISC(Intel 和 AMD) 处理器，指令译码和流水线的实现精简化，可以在芯片上使用更少的三极管，换取更多的寄存器和流水线性能 ( 多线程 / 并发能力，高吞吐 ) 。过去，由于应用主要是跑在对功耗不敏感的X86架构CPU上，人们对该架构下的应用进行了大量的优化，ARM平台的性能优势并没有充分的发挥出来。最近数年，转机出现了，ARM平台在移动端(比如手机)和物联网终端(比如家用智能设备)的大规模使用，使得对该平台算法和软件的性能优化变得越来越充分（近年来，开源社区对ARM平台的支持已经足够用户将X86应用在合理的投入下迁移到ARM平台，LLVM等基础工具大部分可以找到支持ARM平台的版本）。结合既有的并发能力优势，使得ARM 平台的服务器在一些应用场景下显得颇有吸引力。另外，对于移动应用，在云端采用ARM平台服务器，还可以做到端云同构，节省开发调试成本。

在这样的背景下，业界大厂纷纷推出ARM平台服务器CPU. ARM平台服务器CPU在云端服务器啃下一块市场也是必然。2019年，华为推出了第二代ARM平台数据中心处理器鲲鹏920芯片(预期今年推出其升级版鲲鹏930)，采用7nm制程，最高支持64个内核，工作频率高达2.6 GHz，支持8通道DDR4，以及一对100G RoCE端口。并且推出就自产自销上华为云。从配置来看，其设计特别强调高吞吐能力，目前性能仍处于ARM平台服务器CPU的第一梯队。

2.为什么需要做服务迁移
越来越多的服务转向ARM云平台是一个趋势。ARM架构芯片核的面积仅为X86核的1/7，这也意味着在单位面积下，ARM可以集成更多的核心——实际数据是四倍以上。这意味着ARM架构CPU 的众核架构横向扩展的方式会更符合分布式业务的需求。如果是新的应用，可以直接选择鲲鹏云平台进行开发，充分利益ARM云平台的优势。但是当前，绝大部分云平台应用都跑在于X86架构CPU上，需要将服务进行某种形式的“重构”才能运行在ARM云平台上。其主要原因在于，用户在往ARM平台迁移时需要处理指令集上的差异，才能使得原来运行在x86架构下的程序能够平稳运行于ARM平台，完成迁移。

指令集差异

这些指令集的差异，使得像C/C++, Go 等编译型语言写的应用程序，需要采用ARM64(aarch64)编译器重新编译后才能运行。这是因为编译型语言先要被“翻译”成汇编，然后转换成二进制指令。而ARM平台的鲲鹏处理器和X86架构的处理器，其汇编和二进制指令不一样，导致一方的可执行程序不能直接移植到另一个平台运行。像Java, Python 等本身支持跨平台的解释型语言，如果原应用不依赖C/C++语言编译的公共组件（大部分情况下），则可以直接运行在ARM平台上。对于剩下的极少部分的汇编语言，则需使用ARM指令集改写一遍。比如在X86架构下，128位按位做and运算：

 PAND xmm1 , xmm2/m128

对于ARM架构处理器，可以替换为NEON指令：

 AND Vd.<T>, Vn.<T>, Vm.<T>

三类语言的服务迁移路径

以上这些迁移路径说明，传统X86架构服务的迁移虽然会带来潜在的优势，但迁移也是有成本的，需要投入时间对软件/服务进行对应的更改和测试。

3.鲲鹏社区助力服务迁移
ARM平台的性能优势和特点是帮助其从巨大的云计算市场中吃下一块的基础。至于能以多快的速度吃下多大的市场，其决定性因素的可能并不是这些架构和制程决定技术优势，而是用户的选择，具体地，也就是用户的迁移成本相对于可能带来的优势的比较——如果只需要修改少量的代码就可以将服务转换到支持更高并发的ARM云平台上，这对于那些对吞吐量尤其敏感的后端服务来说，何乐而不为呢。

为了降低用户的迁移成本，华为花费了相当的力量建设了华为云学院和鲲鹏社区，指导和帮助用户进行应用迁移方面的工作。并且推出了鲲鹏开发套件(包括扫描评估工具Dependency Advisor, 迁移工具Porting Advisor, 和性能优化工具Tuning Kit)帮助用户评估工程的可移植性，检查用户软件 C/C++ 源码，识别需要修改的部分并提供修改建议和性能调优。而且这些内容中的绝大部分对用户来说是免费获取的。在注册华为云之后，用户可以在华为云端实验室免费使用华为云资源(ECS等)进行应用往ARM云平台迁移的实验。

以相对更耗时更复杂的C/C++应用迁移为例，可选择云端实验室中的“通过鲲鹏工具链将X86 C/C++代码迁移到鲲鹏平台”实验进行体验。用户在该实验中首先预置实验环境，免费获取实验所需的鲲鹏ECS、EIP, VPC, 安全组等资源（可以通过开发者免费试用区获取更多更长时间的资源试用）。

然后可以依照提示，在网页端中通过公网EIP登录分配的ECS之后，修改教程中提供的C/C++应用包的编译脚本和相关代码段，重新编译即可完成安装、验证和测试。

实验体验环境

4.服务迁移实战
在上文的体验例子中，可以完整的经历如下典型的C/C++工程迁移过程的关键部分：

包括修改编译脚本；修改宏定义，增加aarch64 架构的宏定义；修改编译宏分支，确保 aarch64 架构下使能 SIMD 的 NEON 特性；修改aarch64 架构下的内联汇编指令；重新编译源码并安装测试。

对于C/C++工程迁移的鲲鹏ARM平台移植，可能会碰到如下的典型问题：

1.编译时gcc参数设置需要调整，这方面的问题可以参考gcc官方文档

2.编译时找不到函数、缺少库文件等。可以通过安装鲲鹏ARM平台兼容的依赖库来解决。目前来看，随着ARM平台的发展，这种情况下的问题解决不了的可能性越来越小。如果你的C/C++工程本身是在Linux平台编写/编译的，那这种情况还会相比于从windows平台迁移少很多

3.开源项目库不支持 ARM 架构，这种情况较就更少了，一般发生在较旧的项目代码。面对这种情况可能不得不寻找替代组建或者修改自己的代码以消除依赖。

4. 编译时提示代码错误，比如在上面的体验例子中如果不修改相关类型的宏定义就会出现，解决方法于上面体验例子中类似。

5. 需要重写内联汇编语句，如上文所述，这是由于ARM与X86架构指令集不同导致的。可能需要使用ARM指令指令修改每一条相关代码才能解决。

至于云端常见但由于Java的跨平台性，迁移更为容易的Java Web应用，可以通过云学院提供的“基于华为云鲲鹏弹性云服务器部署Web应用”教程体验，其过程中不涉及对代码的修改，这类应用的迁移相比于C/C++类应用要容易得多。

对于将软件迁移到ARM平台来说，大部分情况下只要建立软件开发编译环境-编译软件-出现错误-修复bug的流程就可以解决问题，这跟很多人碰到过的将Windows平台软件迁移到Linux平台运行差不多。对于更复杂的应用软件，比如数据库、翻译程序，可能需要修改汇编语言。当然现在很多数据库采用的是开源软件的或者本身支持多平台的软件，这类问题也变得越来越容易解决。

当然，实际的业务迁移到鲲鹏ARM云平台，涉及的程序语言和软件依赖会相当复杂。比如某大数据搜索系统的业务软件栈：

这里的mysql, redis, Apache和Hadoop都可以通过鲲鹏代码迁移工具找到鲲鹏ARM平台兼容的版本，其迁移自然不是问题。对于其他暂不兼容的，比如kudu, Impala和Ceph，其官方发布已经提供了完整的或者大部分功能的aarch64平台支持(kudu aarch64, Impala aarch64), 如果升级到支持aarch64的新版后调试通过，那移植到aarch64平台也不会有问题。对于剩下的不兼容的，则需要找替代或者修改代码了。

从上面的实例可以看出，如果你的业务软件栈大量采用开源软件并且保持了版本的更新(大家都意识到aarch64平台变得越来越流行，需求越来越多，顺势推出了该平台的版本)，那么迁移的成本就会比较低。相反，如果采用了较老的软件或者不支持aarch64的商业软件，那就需要花费比较多的精力，甚至不得不采取绕过依赖的方案。这也就意味着，仅从实际业务软件栈的情况来看，就有部分业务并不适合迁移，企业需要根据自己的实际情况量力而行。因此，企业业务迁往ARM云平台虽然是一个趋势，但X86云平台在未来相当长一段时间并不会消失，而是会继续占有相当的市场，与ARM云平台并驾齐驱。