加速云：最后一步

(本文是Ampere Computing“加速云计算”系列文章的第五部分。您可以在SitePoint上阅读所有文章。)

云原生应用开发的最后一步是决定从哪里开始。作为本系列的最后一期，我们将探讨如何进行云原生应用开发，在您的组织内部从哪里开始这个过程，以及在此过程中可能遇到的各种情况。

正如本系列的其他部分所展示的那样，云原生平台正在迅速成为基于x86计算的强大替代方案。正如我们在第四部分中展示的那样，在性能、可预测性和能效方面，全核Ampere vCPU和半核x86 vCPU之间存在巨大差异。

如何进行云原生应用开发

为云原生计算环境设计、实现和部署分布式应用程序的自然方法是将该应用程序分解成更小的组件或微服务，每个组件负责一项特定任务。在这些微服务中，您通常会拥有多种技术元素来共同提供该功能。例如，您的订单管理系统可能包含一个私有数据存储（可能用于在内存中缓存订单和客户信息）和一个会话管理器来处理客户的购物车，此外还有一个API管理器来使前端服务能够与其交互。此外，它可能连接到库存服务以确定商品可用性，可能是一个交付模块以确定运费和交付日期，以及一个支付服务以收取付款。

云计算的分布式特性使应用程序能够随着需求而扩展，并以单体软件无法实现的方式独立维护应用程序组件。如果您对电子商务网站的流量很大，您可以独立于库存服务或支付引擎扩展前端，或添加更多工作程序来处理订单管理。云原生应用程序的设计目标是通过隔离一个组件中的故障来避免其他组件受到影响，而不是单个大型应用程序，其中一个故障可能导致全局系统故障。

此外，云原生方法使软件能够充分利用可用的硬件功能，只需创建处理当前负载所需的服务器，并在非高峰时段关闭资源。像Ampere这样的现代云原生CPU提供了数量非常多的快速CPU内核和快速互连，使软件架构师能够有效地扩展其应用程序。

在本系列的第二部分和第三部分中，我们展示了将应用程序迁移到基于ARM的云原生平台相对简单。在本文中，我们将描述通常需要采取的步骤才能使这种迁移成功。

在您的组织内部从哪里开始

迁移到Ampere的云原生Arm64处理器的第一步是选择合适的应用程序。一些与其他CPU架构紧密耦合的应用程序可能更难以迁移，原因可能是它们对特定指令集存在源代码依赖性，或者是因为与指令集相关的性能或功能限制。但是，Ampere处理器在设计上通常非常适合许多云应用程序，包括：

• 微服务应用程序、无状态服务：如果您的应用程序分解成可以根据需要独立扩展的组件，则Ampere处理器非常适合。分解应用程序并利用云所提供的优势的关键部分是分离有状态和无状态服务。无状态应用程序组件可以水平扩展，根据需要提供更高的容量，同时使用数据库等有状态服务来存储非短暂数据。扩展无状态服务很容易，因为您可以在许多服务副本之间进行负载平衡，为您的计算基础设施添加更多内核以应对需求的增加。由于Ampere的单线程CPU设计，您可以以更高的负载运行这些内核而不会影响应用程序延迟，从而降低整体价格/性能。
• 音频或视频转码：将数据从一种编解码器转换为另一种编解码器（例如，在视频播放应用程序中或作为IP电话系统的一部分）是计算密集型的，但通常不是浮点密集型的，并且可以通过添加更多工作程序很好地扩展到许多会话。因此，这种类型的负载在Ampere平台上的性能非常好，并且可以提供比其他平台高出30%以上的价格/性能优势。
• AI推理：虽然训练AI模型可以受益于用于训练的非常快速的GPU的可用性，但是当这些模型部署到生产环境中时，将模型应用于数据并不是非常浮点密集型的。事实上，可以使用精度较低的16位浮点运算来满足AI模型推理的性能和质量SLA，并且可以在通用处理器上运行良好。此外，AI推理可以受益于添加更多工作程序和内核以响应事务量的变化。总而言之，这意味着像Ampere这样的现代云原生平台将提供出色的价格/性能。
• 内存数据库：因为Ampere内核的设计具有每个内核的大型L2缓存，所以它们通常在内存密集型工作负载（如对象和查询缓存以及内存数据库）中表现非常好。Redis、Memcached、MongoDB和MySQL等数据库工作负载可以利用每个内核的大型缓存来提高性能。- 持续集成构建农场：构建软件可能非常计算密集型且可并行化。作为持续集成实践的一部分运行构建和集成测试，并使用持续交付实践来验证即将进入生产的新版本，可以受益于在Ampere CPU上运行。作为迁移到Arm64架构的一部分，在该架构上构建和测试您的软件是先决条件，并且在原生Arm64硬件上执行这项工作将提高构建的性能并提高开发团队的吞吐量。

分析您的应用程序依赖项

一旦您选择了您认为适合迁移的应用程序，您的下一步就是确定更新依赖项堆栈所需的工作。依赖项堆栈将包括主机或客户操作系统、编程语言和运行时，以及您的服务可能具有的任何应用程序依赖项。Ampere CPU中使用的Arm64指令集在最近几年才变得突出，并且许多项目近年来都努力改进Arm64的性能。因此，本节中的一个共同主题是“较新的版本会更好”。

• 操作系统：由于Arm64架构在过去几年取得了巨大进步，您可能希望运行更新的操作系统以利用性能改进。对于Linux发行版，任何最近的主流发行版都将为您提供原生Arm64二进制安装介质或Docker基本映像。如果您的应用程序目前使用的是较旧的操作系统，例如Red Hat Enterprise Linux 6或7，或Ubuntu 16.04或18.04，您可能需要考虑更新基本操作系统。
• 语言运行时/编译器：所有现代编程语言都可用于Arm64，但流行语言的最新版本可能包含额外的性能优化。值得注意的是，最新版本的Java、Go和.NET在Arm64上的性能有了显着提高。
• 应用程序依赖项：除了操作系统和编程语言之外，您还需要考虑其他依赖项。这意味着检查您的应用程序使用的第三方库和模块，验证这些库中的每一个都可用于Arm64并已为您的发行版打包，同时根据需要考虑外部依赖项，例如数据库、防病毒软件和其他应用程序。依赖项分析应包括多个因素，包括Arm64依赖项的可用性以及如果这些依赖项具有特定于平台的优化，则会产生的任何性能影响。在某些情况下，您可以在失去某些功能的情况下进行迁移，而在其他情况下，迁移可能需要工程工作才能适应Arm64架构的优化。

在Arm64上构建和测试软件

云服务提供商(CSP)上Arm64计算资源的可用性最近有所扩展，并且仍在不断增长。正如您从Ampere Computing网站上的“在哪里尝试”和“在哪里购买”页面中看到的那样，无论是在您的数据中心还是在云平台上，Arm64硬件的可用性都不是问题。

一旦您可以访问Ampere实例（裸机或虚拟机），您就可以开始迁移的构建和测试阶段。正如我们上面所说，大多数现代语言现在都完全支持Arm64作为一级平台。对于许多项目而言，构建过程就像重新编译您的二进制文件或将您的Java代码部署到Arm64原生JVM一样简单。

但是，有时软件开发过程中的问题可能会导致一些“技术债务”，团队可能必须在迁移过程中偿还这些债务。这可以采取多种形式。例如，开发人员可以对某些硬件功能的可用性或未在标准中定义的特定于实现的行为做出假设。例如，char数据类型可以根据实现定义为有符号字符或无符号字符，在x86上的Linux中，它是带符号的（即，其范围从-128到127）。但是，在使用相同编译器的Arm64上，它是无符号的（范围为0到255）。因此，依赖于char数据类型符号的代码将无法正常工作。

但是，总的来说，符合标准的代码以及不依赖于x86特定硬件功能（如SSE）的代码可以在Ampere处理器上轻松构建。大多数持续集成工具（管理跨支持平台矩阵的自动化构建和测试的工具），如Jenkins、CircleCI、Travis、GitHub Actions等，都支持Arm64构建节点。

管理生产中的应用程序部署

我们现在可以看看在将您的云原生应用程序部署到生产环境时，您的基础设施管理将会发生什么变化。首先要注意的是，您不必一次移动整个应用程序——您可以选择最能从迁移到Arm64中受益的应用程序部分，并从这些部分开始。大多数托管的Kubernetes服务支持单个集群中的异构基础设施。令人讨厌的是，不同的CSP对在单个Kubernetes集群中混合不同类型计算节点的机制有不同的名称，但所有主要的CSP现在都支持此功能。一旦您的Kubernetes集群中有了Ampere计算池，您可以使用“污点”和“容忍度”来定义容器的节点亲和性——要求它们在arch=arm64的节点上运行。

如果您一直在为Arm64架构构建项目容器，则创建将是多架构容器的清单非常简单。这本质上是一个包含指向多个容器映像的指针的清单文件，容器运行时根据主机架构选择映像。

人们在部署阶段通常遇到的主要问题再次可以归类为“技术债务”。部署和自动化脚本可以假设某些特定于平台的路径名，或者被硬编码为依赖于仅限x86的二进制工件。此外，不同Linux发行版返回的架构字符串可能因发行版而异。您可能会遇到x86、x86-64、x86_64、arm64、aarch64。规范化这些平台差异可能是您过去从未做过的事情，但作为平台转换的一部分，这将非常重要。

平台转换的最后一个组成部分是应用程序的运行。云原生应用程序在生产中包含大量脚手架，以确保它们能够正常运行。这些包括日志管理以集中事件、监控以允许管理员验证事情是否按预期工作、警报以在发生异常情况时发出警报、入侵检测工具、应用程序防火墙或其他安全工具以保护您的应用程序免受恶意行为者的攻击。这些将需要一些时间投资来确保为应用程序节点激活适当的代理和基础设施，但是由于所有主要的监控和安全平台现在都支持Arm64作为平台，因此确保您可以查看应用程序的内部工作通常不会构成大问题。事实上，许多最大的可观察性软件即服务平台正越来越多地将其应用程序平台迁移到Ampere和其他Arm64平台，以利用该平台提供的成本节约。

改善您的底线

向云原生处理器的转变可能是巨大的，使迁移投资非常值得付出努力。通过这种方法，您还能够评估和验证您的组织随着时间的推移可以预期获得的运营节省。

请注意，提高性能的最大障碍之一是惯性，以及组织倾向于继续做他们一直在做的事情，即使它不再是最有效或最具成本效益的途径。这就是为什么我们建议采取第一步来证明云原生技术对您的组织的价值。通过这种方式，您将拥有真实的成果与利益相关者分享，并向他们展示云原生计算如何在没有大量投资或风险的情况下提高应用程序性能和响应能力。

云原生处理器已经出现。问题不在于是否转向云原生，而在于您何时进行转换。那些更早拥抱未来的组织将从今天开始受益，这将使他们比那些受传统束缚的竞争对手拥有巨大的优势。

在Ampere开发者中心了解更多关于以云的速度进行开发的信息，其中包含用于设计、构建和部署云应用程序的资源。当您准备好亲身体验云原生计算的好处时，请向您的CSP询问他们基于Ampere Altra系列和AmpereOne技术的云原生选项。

以上是加速云：最后一步的详细内容。更多信息请关注PHP中文网其他相关文章！