简介： 阿里云、平头哥及安谋科技联合举办的飞天技术沙龙探讨了倚天Arm架构在业务创新中的应用。活动中，千寻位置运维专家分享了将核心业务迁移到倚天处理器ECS实例的成功案例，强调了倚天处理器的高能效比和降本增效优势。迁移过程涉及操作系统、CICD系统和监控系统的适配，以及业务系统的性能测试。目前，千寻已迁移了上千台ECS实例到倚天处理器，实现了成本和效率的显著提升。未来计划继续扩展倚天处理器在核心业务和K8S中的应用。
5月16日，由阿里云、平头哥及安谋科技共同主办的飞天技术沙龙《业务创新新选择，倚天Arm架构深入探索》在上海成功举行。来自阿里云、平头哥及安谋科技的专家为现场观众深入解读了Arm架构的核心优势，并重点分享了基于倚天710的计算实例g8y在大数据和视频领域优化的最佳实践，以帮助企业用户了解倚天ECS实例如何在成本、效率方面提供助力。
图：千寻位置运维专家李轲韡
现场，千寻位置运维专家李轲韡分享了《阿里云倚天在时空智能服务上的规模化应用》主题演讲，重点分享了千寻位置的核心业务迁移至倚天ECS实例的最佳实践以及迁移的经验，以下内容根据他的演讲整理而成。
我是来自千寻的李轲韡。今天很高兴和大家分享千寻位置在迁移倚天处理器ECS实例背后的故事。现在千寻已经有上千台ECS实例运行在倚天处理器上。
1. 为什么要迁移到倚天处理器
很简单，降本增效。倚天处理器是一个能效非常高的处理器，用少量的研发资源投入，实现一个比较高性价比的产出，通过这种技术的演进路线，可以有效降低阿里云上的云资源成本。
接下来介绍整体的迁移步骤，首先是支撑系统的准备，包括调研操作系统、选型、基本的适配工作。
第二是CICD系统的适配，也就是CICD系统需要兼容ARM架构和X86架构。运维和开发操作ECS时，不应该关注ECS到底是ARM还是X86，系统应该能够自动处理掉。
第三是监控系统的适配，倚天处理器的ECS上在做基础指标的采集时，有一定的适配工作。
完成了基础系统的准备工作后，就可以做业务系统的准备。我们知道C++代码在X86和ARM处理器上要重新编译，而绝大多数的Java代码可以直接使用，所以需要把所有和处理器架构相关的代码做重新编译。
接下来对功能进行完整的回归测试，做必要的性能上的压力测试，业务系统也准备就绪了。
最后是迁移的策略，千寻在制定迁移策略时有两个假设。第一，对于自研系统，只要投入足够多的人力是一定可以迁移的。第二，对同一份代码，无论运行的ECS实例数是多少，投入迁移的人力成本是差不多的。基于这两点假设，我们制定了迁移策略。
把相同代码的ECS实例的费用做了排序，当同样一份代码运行的ECS所花掉的钱越多，就越先迁移。从金额由高到低逐步迁移，最后定了一个比例，当百分之多少的应用全部迁移完，就完成了。把目标和策略定完后，开始逐步迁移工作。
2. 迁移前准备工作
下面是准备工作中遇到的具体情况。
首先基础环境的准备。之前用的是阿里云的六代ECS，Intel Xeon Platinum 8269CY的CPU，目标是倚天710。操作系统原来用的是Alibaba Cloud Linux 2，在阿里云的ECS上使用Alibaba Cloud Linux可以获得阿里云免费的商业支持，在操作系统的层面遇到的问题，阿里云会支持的相对好一些，所以千寻一直选用这个操作系统。
在倚天710上，阿里云唯一官方商业支持的操作系统是Alibaba Cloud Linux 3，考虑到Alibaba Cloud Linux 2明年三月份就会终止生命周期，借着迁移倚天710的机会，把操作系统从Alibaba Cloud Linux 2升级到了Alibaba Cloud Linux 3。
接下来是JDK，原来在X86实例上千寻用的JDK是Oracle JDK的1.8.0_192版本，也就是1.8系列的最后一个免费版本，后面的版本都是收费的。在ARM上换成了OpenJDK，更换的理由在后面PPT详细介绍。
上图展示的是性能对比测试数据。这是千寻的C++应用，上面两条曲线是X86处理器，下面两条是ARM处理器。上面两条曲线的平均值分别是47%和41%，下面两条都是26%，可以看到性能提升都超过50%以上。
这是纯Java应用的一个性能对比测试。ARM处理器在同样的CPU核心数下，它的性能略低一点。ARM处理器的CPU占用率是69%，X86的CPU占用率是64%。
为什么要更换OpenJDK？因为Oracle JDK的最后一个免费版本在ARM处理器上没有G1 GC特性的。因为千寻的业务对数据延时非常敏感，当没有G1 GC支持时，数据延时的波动在一秒以上，下面这个图在使用了OpenJDK开启了G1 GC的特性后，整个数据延时在200ms左右。为了保证业务的低延时特性，我们在ARM处理器上更换成了OpenJDK。
接下来是迁移过程中碰到的一个现象。Linux内核是每隔五秒采集一次负载，每采集一次负载会消耗掉一个CPU时间片的时间。当负载采样时，它是根据滑动窗口逐步滑动的，比如第一个时间片，后面第二个时间片，经过若干次采样后，会回到最早采样的时间点。
千寻的业务特性是秒脉冲，所有的服务器在每一秒的前几个时间片里都特别忙，在每一秒的后面的时间片都特别闲。在X86处理器上CPU的时间片默认是一毫秒，这导致每隔1毫秒，5秒采一次，也就是5000秒，大概83分钟，每隔83分钟会有一个负载波动的周期。
在ARM处理器上时间片默认是四毫秒，只需要250次采样就完成一个负载周期，也就是1250秒，大概是21分钟不到。我们看到系统的负载波动没有变化，但是在ARM处理器上，负载波动曲线频率是X86处理器上的4倍。这只是一个现象，不代表任何问题，开发团队关注到了并分析了原因。
接下来是要关注的问题。左边是一段示例代码，可以看到它的行为，在test load的方法里面正常应该返回一个布朗值。在if条件没有触发时，没有写return true。在main方法里面调用两次，正常情况下第一次应该能够执行并且打一条信息，第二次不会进入if的条件。在老的X86处理器的平台上，Alibaba Cloud Linux 2以及GCC 7版本的编译器发现无论有没有return true，编译结果和执行结果没有任何区别。
在GCC 10上，编译的时候会提示一个警告，函数不应该返回为空。在X86上可以看到，它会运行两次，错误地进入两次if条件，然后出现一个段错误。在ARM处理器上进入一次后，程序卡住了。过了一会儿被系统OOM杀掉了。注意一些老的代码可能会遗漏return，在老的编译器上没有任何问题的情况下，使用新的GCC 10编译时，如果看到返回函数有一个返回类型的警告，一定要把警告处理掉。
否则会出现各种各样奇怪的问题。这里举的例子，一个段错误，一个OOM被杀掉。我们看到在开启O3编译时，最后的main方法，return被编译器丢掉了，导致整个执行栈进入到错误的堆栈中，把一些正确定义的变量写坏掉，会出现各种奇怪的现象，所以这种类型的编译警告一定要处理掉。
3. 正式迁移
上面是所有的准备工作，接下来是正式迁移。
这是千寻位置核心业务迁移的时间线。今年4月份开始做初步的调研工作。在倚天处理器的ECS上做了一些基本工作。5月份在测试环境进行完整的功能测试，同时做了一定规模的性能测试。6月份其中一条核心业务线的生产ECS替换了50%的ECS为倚天处理器实例，运行了一段时间没有问题。
7月份把这条业务线所有的ECS全部替换成倚天处理器实例。8月份发现这条业务线跑的没问题，所以其他业务线开始逐步推广适配倚天ECS。9月份其他业务线逐步在生产环境做50%的替换，这个替换工作现在还在持续进行中。
下面是一个性价比的测算。这边挑了两个场景，分别是千寻的业务对于倚天处理器最友好的场景和最不友好的场景。原来用的是第6代的C6系列，和C8Y系列做对比，同样是8核16G的ECS，第一个场景C++，40G的磁盘。倚天处理器的ECS只能购买ESSD，原来用的高效云盘，所以磁盘的成本会高一些。
价格是官网原价，没有任何折扣。原来C6的实例是762元，倚天是532.5元。性能基准C++的话，倚天的性能基准在C++场景大概是原来C6实例的1.46倍，整体性价比提升在100%以上。也就是原来用X86的ECS 1000元能干完的事情，换成倚天只要不到500元。
下面是一个纯Java应用场景。它的磁盘也比较大，它的ESSD会花更多钱，价格差距没那么大，888元和712.5元。因为Java的基准性能ARM会略低，所以整个性价比提升在15%以上。C6的1000元能干完的事，换成倚天的不到850元。这两个场景相对比较极端，千寻平均换倚天的收益是多少？大概是30%以上。
接下来是几点注意事项。
第一是后面的分享中会提到Easy Yitian的工具，可以帮助快速评估程序迁移倚天处理器的兼容性。
第二是周边的配套系统。为了配套整个倚天ECS相关的业务系统生产环境，CICD和监控系统要提前进行准备和测试工作。
第三是拉长时间线，灰度迁移。因为操作系统和JDK版本都换掉了，灰度迁移可以尽可能把问题提前暴露出来，降低影响。
因为整个迁移过程拉的比较长，在这个过程中，所有的X86和ARM的测试环境和CICD的环境是需要长期共存的。比如一个应用迁了半年才迁完，这半年中，每发布一个版本，所有的X86和ARM版本要分别测一遍，直到最后一台X86的生产服务器下线，全部换成ARM。
接下来是ECS宿主机的打散度。千寻现在有上千台倚天ECS实例，但是阿里云倚天处理器的宿主机，相比于X86处理器的宿主机数量比较少，虽然X86和倚天整个底层的故障率没有区别，但是千寻实例相对比较多，在倚天处理器的宿主机上，可能一台宿主机上跑了3台，5台，6台千寻的实例。
如果一台宿主机发生故障，千寻业务可能感受比较明显。如果涉及到比较大量的倚天ECS的迁移，建议和阿里云提前沟通好ECS在宿主机上的打散度怎么样。另外阿里云提供了一个ECS部署集功能，可以强制把ECS打散到不同的宿主机上，这部分可以根据迁移时的情况和阿里云沟通。
最后是我们验证发现ARM处理器在上下文切换场景特别多的情况下，性能会下降。这部分可能从业务上考虑，尽可能避免上下文切换。
4. 后续计划
在后续计划中，首先千寻会继续迁移核心业务到倚天处理器的实例，希望把核心业务全部迁移到基于倚天的处理器的ECS实例上。第二点考虑把K8S的worker也迁移到基于倚天处理器ECS实例。
第三点是RDS经济版，基于倚天的RDS只有MySQL 8.0，目前千寻还有很多业务跑在5.6、 5.7上，需要做完改造后，再往RDS经济版上迁。最后千寻对外输出的项目能否借鉴倚天处理器的迁移经验。
以上就是本次分享的全部内容。
