译自 The Insider’s Guide to Building a Multi-Arch Infrastructure 。
从单一体系结构向多体系结构框架的迁移可能比较困难。以下是早期采用者简化迁移过程的一些指导思路。
多体系结构基础设施使不同任务可以运行在最合适的硬件(x86 或 Arm 架构)上，不仅可以优化价格与性能比，还可以增加设计灵活性。但是从单体系结构向多体系结构的过渡确实不容易。以下是一些早期实践者的简化迁移过程的经验。
在考虑向开发基础架构中添加第二个硬件体系结构时，首先要评估的是预期的收益。毕竟，扩展基础架构影响面很大，从基础设施即代码的设置、CI/CD 流程，到打包、二进制文件、镜像、Kubernetes 升级、测试、调度、上线、可重现构建、性能测试等各个方面都有影响。
那么，为什么要进行这么大的努力呢？主要有两个原因。第一，多体系结构可以降低运营成本；第二，它可以增加在做出各种开发决策时的选择余地。
如何控制云计算的成本依然是一个难题。价格变动可能非常快速而不可预见，导致运行相同工作负载的成本突然上升。对工作负载的更改也可能引发意外的额外收费，甚至小的低效也会随时间积累对基础设施成本造成影响。因此，在尽量减少基础设施预算的同时优化硬件的价格与性能比，成为产生节省的重要手段。
Arm架构以其低功耗操作和高效处理而著称，可以帮助降低成本，使硬件处理更加经济高效。在并排比较中，基于RISC的Arm架构一直显示出比基于CISC的x86对手有更高的工作效率。因此，开发者发现，在Arm架构上运行部分或全部工作负载，是提高效率的有效手段，从而优化价格与性能比。
“在此服务迁移后，EC2实例账单降低了40%，这项投资非常值得。” - Honeycomb.io Field CTO Liz Fong Jones
云计算成本上升和Arm架构硬件在更多应用中采用这两个趋势，正在推动多体系结构基础设施的采用。有了多体系结构基础设施之后，工作负载可以无需开发者担心底层架构即可在x86或Arm硬件上运行，这样可以更容易更快地创建、引入和维护新功能。开发团队发现，前期迁移的投入是值得的，因为它可以节省后续的时间和精力。
相当长时间以来，x86架构主导了云服务提供商的产品，但这已经不是局面了。自2018年亚马逊网络服务(AWS)在EC2上推出首款64位Arm CPU Graviton以来，Arm开发生态系统持续扩大。
其他云服务提供商也迅速添加了自己的Arm产品，独立软件供应商也在为Arm开发持续推出新的基于云的工具。如今，Arm开发所需的要素已经到位，使开发者可以更轻松地找到所需的用于Arm硬件的云原生资源。
随着向Arm架构的持续转变，包括移动设备、汽车以及笔记本电脑等领域，云端开发也受到影响。Arm架构的Raspberry Pi开发平台广泛使用，以及Arm架构可以在各种用例中授权使用，从边缘设备到数据中心，这改变了许多开发者的设计方法。
如今的开发者不仅更熟悉Arm架构，在评估功能时也有更多选择。有些情况下，开发者选择不在传统x86环境中工作，因为在他们的日常开发机上编译和构建可能非常痛苦。
此外，在越来越多的情况下，最新选择仅适用于Arm架构。迁移到多架构基础设施使得更容易利用这些选择，因为工作负载可以在最匹配运行需求的硬件上运行。
“亚马逊EC2的前50大客户中，有48个在其工作负载上使用AWS Graviton处理器。” - 亚马逊AWS欧洲、中东和非洲区首席传道师 Danila Poccia，2022年8月
从规划角度来看，多架构迁移面临的最大挑战之一是，这不仅仅涉及一个方面，而是涵盖了几乎所有事项。以一个电商网站的基础设施为例。
Kubernetes容器编排平台是一个基础元素，还有CI/CD流水线、监控功能和一系列基于容器的微服务。设置中还可能包括存储，是否附带存储声明。
升级Kubernetes实例可能是任何迁移的重要步骤，但这只是需要考虑的一部分。还有许多其他因素需要考虑，比如基础设施即代码(IaC)设置的细节、CI/CD 流水线的性质、创建可重现构建的过程。您的打包、二进制文件、镜像和注册表是什么样子?您的测试、调度、推出和性能评估过程是怎样的?此外，您可能已经优化了设置，在价格和性能之间达到了良好平衡。迁移时接触那么多设置元素，这种平衡是否会被打破?
实施多架构基础设施的具体机制显然将取决于您的个别设置。有些迁移将比其他迁移更复杂。但是根据我们的经验和早期用户的经验，我们可以提供一些总体指导意见。
我们的建议基于两个基本假设：您已经采用了云原生基础设施，并在公有云上运行。我们还参考了业内最佳的Linux基金会FinOps项目。我们欣赏它对基于云的管理的方法，以及它如何将复杂的运营任务分解为三个阶段：洞悉、优化和运营。
对我们而言，洞悉阶段是确定正在运行的内容。下一步是优化阶段，选择一小部分工作负载进行试验，第三步是运营阶段，进行所有必要的升级并开始部署。
让我们详细看看。
列出现有开发基础设施涉及的所有内容。从完整的软件栈清单开始。您使用的操作系统和正在运行的镜像是什么?它们依赖哪些资源？您访问了哪些库和框架来构建、部署和测试?如何监控或管理关键运营如安全？
把所有内容记录下来，您的列表可能会非常长，检查每个项目是否支持Arm。在验证Arm支持时，请注意不同来源对Arm的64位扩展有不同的名称。例如，GNU编译器集合(GCC)将它们分类为AArch64，但Linux内核将它们列在arm64下。
制定完库存后，检查热点。哪些是您最昂贵的计算项目?就现有设置来说，您在哪些方面花费最多?了解执行指令最密集的地方，可以帮助您理解哪些迁移方面将带来最大的节省。
选择一小部分工作负载，置备到Arm测试环境。为了可控性，从小规模开始。更新一些容器镜像并测试语法，检查您的性能测试，修改CI/CD流水线以支持Arm的可重现构建。
将所有内容旋转到公有云，开始处理运行另一架构所需的所有小升级、更改和“if语句”补充。在迁移单个工作负载之前，无需升级整个环境。例如，您可以在不修改Kubernetes平台的情况下进行更改。
这很有趣，因为您将构建Kubernetes集群、调整基础设施并推出新的流程。首先要做出的决定可能是如何迁移控制平面和工作节点。您可能不想一次完成所有操作，因此需要仔细考虑各种选择。例如，您可以先移动控制节点，然后移动工作节点，或者可以分批地一起移动它们。创建每个集群的权衡将反映您的软件栈、节点可用性和工作负载性质。
您还需要检查用于集群创建的脚本，为每个硬件架构添加更改。混合使用x86和Arm脚本会影响在DaemonSet控制器中运行的任何内容。确保为您使用的架构获取了正确的镜像。
当新的Kubernetes集群就绪后，您可以开始部署。我们建议从金丝雀部署的小规模子集开始，或在活动生产环境旁运行新的发行候选版本，进行蓝绿部署。无论哪种方式，最好从渐进式推出开始，同时进行监控。
在检查调度是否按计划工作时，Kubernetes的节点亲和性概念可以帮助简化设置。使用污点和容忍度的组合可以确保正确的工作负载运行在正确的节点上。您还可以根据每个架构调整请求数，微调限制以优化性能。
回顾这三个迁移阶段，您可能已经注意到，在前两个阶段(洞悉和优化)做的是基本原型设计。也就是说，您要确定功能并使用少量工作负载作为概念验证，看测试环境是否产生良好结果。完成这两个首要阶段不需要超过几个下班后的空闲时间。即使您还不确定是否要进行完整迁移，单独完成前两个阶段也可能值得尝试。
在寻找多架构迁移的案例时，最简单的地方看AWS Graviton，因为这是迄今在云中运行时间最长的Arm架构。我们的第一个迁移案例FusionAuth至今仍运行混合架构，第二个Honeycomb.io最终使用其多架构迁移完全采用了Arm架构。
拥有超过1000万次下载，FusionAuth是全球领先的身份和用户管理解决方案供应商之一。它是首批为认证和授权提供面向开发者的API的供应商之一，迁移就集中在这方面功能上。
迁移是由社区成员发起的，他希望在Raspberry Pi开发板上试验授权。FusionAuth是一个Java工作室，这意味着它必须找到一个支持Arm的Java虚拟机(Java 17是第一个支持的版本)。FusionAuth将Java 17/Arm支持添加到代码中，然后使用jlink和多架构构建更新Docker以适用于Arm架构。由于FusionAuth基于Java运行，Arm迁移的工作量相对较小。最大的障碍是找到为Arm构建的JVM。此外，就是解决剩余的问题。
当FusionAuth的SaaS解决方案开发中(2019年)，运行Arm的公有云区域仍相对有限，因此它必须谨慎选择。在使用AWS Graviton服务器负载测试FusionAuth并更新JVM后，它于2022年6月开始正式支持Arm。扩展很快，截至2023年3月，其SaaS服务器实例的70%以上运行在Arm上。
对于负载测试，FusionAuth选择了登录请求，因为密码散列使登录成为一个特别CPU密集的过程。在AWS EC2环境中测试了50，000次登录后，FusionAuth团队发现Arm架构每秒可以处理26%至49%更多的登录，而且成本也低8%至10%。
“我刚刚将一个FusionAuth实例切换到Arm64，这个迁移顺利到我甚至无法判断它是否真的运行在Arm64上。” - FusionAuth用户Dunia Anak Alam基金会首席信息官Hendy Irawan
通过其可观察性平台，Honeycomb.io帮助工程团队深入理解自己的生产系统和终端用户体验。该团队于2020年3月开始在AWS Graviton上进行试验。一年内，首批工作负载已投入生产。仅仅6个月后，近乎全部(92%)的工作负载和环境都运行在Arm vCPU上。到2022年4月，他们能够关闭最后的x86 EC2实例，99%以上运行在AWS Lambda指令集上。
Honeycomb.io仔细考虑了迁移顺序。该团队从无状态的、性能关键的、相对易于横向扩展的摄入工作器开始。此外，摄入工作器使用Golang编写，针对Arm编译很容易。
他们同时准备了多个环境，并在自己身上使用dogfooding环境进行了测试，就像他们的最终用户一样。他们起初没有使用Kubernetes或容器编排，而是选择了Terraform和Chef，以通过枚举所有依赖项的更新来切换Arm Amazon机器镜像(AMIs)。
在摄入工作器之后，他们迁移了自己的工作负载，即Apache Kafka，因为这些是最易重新编译的，并代表了最高的计算支出。从那以后，他们按优先级处理各种杂项和一次性服务，将最难的工作负载留到最后。在回顾工作和评估路线图时，他们决定停止使用x86硬件。切换完全到Arm可以降低复杂性，减少运营成本，获得重大竞争优势。
“通过AWS Graviton，我们可以在不增加运维负担的情况下扩大产品规模，计算花费更少，并具有更小的环境影响。” - Honeycomb.io工程经理Ian Smith
谈到基础设施迁移的案例时，值得注意的是，Arm的开发团队也经历了这个过程，并已将我们最计算密集的操作迁移到云端的Arm架构。(如果我们不使用自己的产品，那我们就不是一个好的科技公司!)
2019年，我们将本地的数据的x86基础设施迁移到了AWS Graviton，用于电子设计自动化(EDA)，我们用它来设计、建模、仿真、测试和分析我们的电路设计。在此过程中，我们将性能提高了60%以上，将成本减半，每天节省了100多万瓦时的用电。
从高层面来看，运行多架构基础设施的目标是让工作负载运行在最适合其价格/性能需求的硬件上，而开发人员不必关心底层架构。但这并不意味着它是一个轻松实现的目标。为了简化迁移过程，我们建议遵循FinOps方法，将任务分为三个阶段:洞悉、试验和监控部署。
要从专家那里了解有关多架构迁移的更多信息，请点击这里查看更多资源。