1.4 底层软硬件挑战
硬件永远面临软件的挑战：无论硬件性能多强劲，都无法满足软件持续快速上升的性能需求。在云计算应用场景中，大规模、多租户、复杂网络等多种需求叠加，这使得底层硬件及相关的底层软件（如驱动程序、固件等）面临更复杂的挑战。
1.4.1 业务异构加速
业务从无到有，再到大规模发展，对云计算主机的需求一直在变化。
·最初的业务特征可能不明显，在这种情况下，宜选用以CPU为计算核心的通用云计算主机。
·随着业务的进一步开展，业务场景逐渐稳定，当用户对自己的业务非常熟悉之后，用户可能会倾向于针对不同的业务选择不同类型的主机。例如，针对HPC选择计算优化型主机，针对大型数据集处理选择内存优化型主机等。
·随着业务的深入开展，业务场景逐渐固定，当云计算资源的规模足够大时，就有了通过硬件进一步加速来提升性能并降低成本的诉求。
随着人工智能技术的蓬勃发展，基于GPU加速的机器学习训练及推理得到大规模应用。GPU加速主要应用于机器/深度学习、高性能计算、计算流体动力学、计算金融学、地震分析、语音识别、无人驾驶汽车、药物发现、推荐引擎、预测、图像和视频分析、高级文本分析、文档分析、语音、对话式代理、翻译、转录和欺诈检测等领域。
FPGA能够为特定应用场景定制加速器，相比GPU，FPGA加速效率更高，缺点在于硬件编程的技术难度和工作量大。因此，基于FPGA的加速主要是以FaaS（FPGA as a Service，FPGA即服务）平台的模式出现，由Xilinx、英特尔或其他供应商提供底层的FPGA软硬件支持，把FPGA封装成标准的加速平台。一些第三方ISV可以基于标准平台开发一些针对主流应用场景的特定加速器。在云计算数据中心大规模服务的支持下，FaaS既具备了硬件加速的高效，也具备了云计算的弹性特征，在一些特定领域得到了广泛的应用。
异构加速的实现架构通常是CPU+GPU/FPGA，主要由CPU完成不可加速部分的计算及整个系统的控制调度，由GPU/FPGA完成特定任务的加速，这种架构面临如下挑战。
·可加速部分占整个系统的比例有限。
·受到数据在CPU和加速器之间来回搬运的影响，有些应用场景综合加速效率不明显。
·额外的CPU/FPGA加速卡导致成本增加。
·异构加速引入了新的实体，使得由一个实体完成的计算变成了由两个或多个实体协作完成，增加了整个系统的复杂度。
·GPU、FPGA 都有多种平台。例如，NVIDIA GPU 的 CUDA（Compute Unified Device Architecture，统一计算架构）、Xilinx FPGA的SDAccel、Intel的Accelerator Stack等。每种平台都需要考虑各自的硬件加速器型号和规格，这给云计算的硬件成本及运维管理带来了挑战。
·虽然底层软硬件供应商已经为自己的硬件平台封装了非常强大且对用户友好的开发和应用框架，但当面对一个新领域的时候，异构加速平台距离业务级的开发者还是太远，用户自己开发底层软硬件的难度依然很大。
1.4.2 工作任务卸载
在虚拟化的架构里，系统可以简单地分为两层：Guest层和Host层。Guest层是用户业务层，Host层是后台管理层。Host层的工作任务主要是虚拟化管理、I/O后台处理，以及相关的监控、操作和管理等。
Host层的多种工作任务中最消耗CPU资源的是I/O后台处理，如网络VPC、分布式存储等。Intel在Xeon CPU上做过网络OVS的性能测试：64B数据包流消耗4个CPU内核，通过DPDK加速的OVS最佳性能是9Mpps的吞吐量4.6Gbit/s的带宽。随着网络带宽的不断升级。如果仍然通过DPDK加速OVS那么CPU开销将无法承受。将10～15个甚至更多的CPU核专门用于数据包处理，意味着没有多少剩余的CPU核可以用于用户业务。在服务器上运行的VM或容器越多，云计算服务商赚到的钱就越多。如果为DPDK-OVS分配大量CPU核，那么在服务器上启动的VM数量将减少，从而减少云计算服务商的收入。
Host层的其他工作任务也都会占用一定的CPU资源，并且存在跟用户业务争抢CPU资源的问题，最好都能够卸载到硬件设备。云计算服务商总希望把尽可能多的CPU资源出售给用户业务，以此来赚取更多的收入。虚拟化的功能非常复杂，包括vCPU的调度、虚拟设备模拟、热迁移、虚拟机管理等。相比虚拟化的功能，虚拟化的卸载更加复杂，除了Hypervisor的功能，还涉及整个云计算体系结构的重构。
工作任务卸载跟业务异构加速有很多异同点，相同点在于两者本质上都通过硬件加速来提升性能，并且都需要软件的协同工作；区别主要有如下几点。
·工作任务卸载不是局部算法加速而是整体卸载，所有的处理都放在硬件中实现（数据面会完全卸载，控制面可能依然在主机侧）。
·业务异构加速是单个工作任务内部的协作，工作任务卸载是卸载的任务和主机侧其他任务的协作。
·工作任务卸载对用户来说是透明无感知的，业务异构加速平台则需要暴露给用户。
工作任务卸载一般不改变现有云计算软件系统，而是做到与其兼容。工作任务卸载的挑战在于如何做好软硬件划分，以及更好地把软硬件接口划分清楚，以实现在不修改硬件数据面处理的情况下，软件能够快速迭代升级。工作任务卸载的目标是由硬件负责数据面，由软件负责控制面，实现硬件的高效和软件的灵活统一。
1.4.3 软硬件接口的标准化和灵活性
狭义的软硬件接口即I/O接口，我们通常把CPU和I/O设备之间的接口扩展到CPU与其他硬件之间的数据交互接口。我们通过I/O接口在软件和硬件之间传输数据，这些数据即在软件中处理，也在硬件中处理，而I/O接口就承担了软件和硬件之间数据通信接口的角色，我们称之为软硬件（数据）接口。
1.软硬件接口的标准化
为了降低数据中心大规模管理及业务迁移的复杂度，同时提高二者的稳定性，需求云计算基于无差别、的硬件平台。通常通过虚拟化技术把底层有差别的硬件特性抹平，为虚拟机提供一个无差别的虚拟硬件服务器。
完全硬件虚拟化技术很难实现无差别的虚拟硬件服务器。我们通过硬件虚拟化技术把CPU里的处理器和内存访问直接暴露给虚拟机，因为主流的服务器架构都是x86，所以我们依然可以认为这些服务器的CPU处理器和内存是无差别的。但是，在通过直通模式和SR-IOV等技术把硬件设备完全暴露给虚拟机的时候，出现了一些问题：不同供应商生产的同一类设备的接口完全不同，需要加载不同的驱动程序；同一个供应商的现代同类产品也可能因为产品升级换代的原因而无法保证二者之间的接口完全兼容。
当前云计算场景的I/O虚拟化技术仍然以类虚拟化技术为主，这不可避免地会影响I/O的性能。随着网络、存储向着大带宽、高性能的方向发展，类虚拟化技术越来越成为影响I/O性能的主要因素。
为了实现在支持标准化接口的同时保证完全硬件虚拟化I/O设备的性能，云计算厂家更倾向于选用公开、高效、标准、广泛使用的I/O接口。例如，AWS的网络设备接口为ENA，存储接口为NVMe。
2.软硬件接口的灵活性
I/O硬件虚拟化虽然可以呈现出很多虚拟设备，但实际上是将物理设备进行了共享，这些物理设备既可以是同类型的，也可以是不同类型的。物理的硬件接口可以根据实际需求进行灵活配置，配置的灵活性体现在如下几方面。
·接口的类型可配置。我们可以根据不同的应用场景，配置每个物理接口上需要虚拟的多个不同类型的接口。例如，网络类型的接口、存储类型的接口、网络类型和存储类型共存的接口，以及其他不同接口类型或接口类型集合。
·接口的可扩展性。每一种类型的虚拟接口还可以灵活地配置同类型虚拟设备的数量。
·接口的性能弹性。如果是网络接口，我们可以灵活配置不同网络虚拟接口的最大带宽、网络包处理的最大PPS值等；如果是存储接口，我们可以灵活配置不同的最大存储吞吐量和IOPS等。
1.4.4 硬件处理的虚拟化和个性化
云计算场景面临的一大挑战是多租户，当我们把Host层的工作任务从软件转移到硬件处理时，硬件就需要实现虚拟化功能来支持多租户。云计算通过PCIe SR-IOV及多队列（Multi-Queue）技术实现了更细粒度的接口完全硬件虚拟化，硬件内部同样需要支持完全硬件虚拟化的多队列，以实现逻辑分离的硬件处理引擎，使每一个队列的处理一一对应。
很多硬件内部支持多通道（Multi-Channel）技术，硬件处理的虚拟化跟多通道类似，但又不完全相同。就像服务器虚拟化可以虚拟出各种不同资源配置、用于不同工作处理的虚拟机一样，硬件处理的虚拟化同样需要在队列粒度的层级上实现不同队列的个性化处理。例如，块存储场景有数据压缩、加密、备份等需求，网络场景有IPSec、新的网络转发协议的需求，但并不是所有用户都有同样的需求，不同用户的需求可能千差万别，甚至同一个用户的不同实例需求也不一样。这就需要实现队列粒度、有状态、虚拟化、个性化的硬件处理。
1.4.5 业务和管理物理分离
后台管理层的工作任务卸载一般只卸载部分后台任务，或者主要卸载工作任务数据面，以此来减少绝大部分的CPU资源消耗，控制面的处理仍然要运行在Host层。而业务和管理物理的分离更加彻底，把后台管理完全转移到了新的硬件设备，把CPU完全交付给用户业务使用。业务和物理管理分离的诉求一是来自后端管理和用户业务之间的相互影响；二是来自安全管理；三是来自用户独占物理服务器。
在云计算基于虚拟化的多租户环境下，用户业务和后台的管理共存于一个服务器软件系统里，用户之间会因为资源抢占而相互影响，后端管理和用户业务之间也会相互影响。
·虚拟化管理可能会对共存于同一个硬件服务器的业务实例造成影响。例如，如果我们不想让热迁移影响业务实例的性能，那么就需要增加整体迁移持续的时间，但这样会降低热迁移的效率，并且影响业务实例高可用的体验；如果尽可能地减少整体迁移持续的时间，那么就会对其他业务实例性能产生影响。
·后台工作负载会占用CPU资源。例如，当某个业务有突发大流量网络访问的时候，由于后台网络VPC工作负载主要进行数据面的处理，因此会等比例地增加CPU资源消耗，这也会对业务实例性能造成影响。
云计算多租户运行于同一个环境里，势必会增加安全风险：一方面，操作系统或虚拟化管理潜在的漏洞可能会被别有用心之人利用；另一方面，云计算运维管理存在人为失误的可能，从而影响用户实例。
一些用户会有物理机实例的需求。例如，一些HPC的场景性能敏感，即使非常少量的性能损耗也不可接受。又如，一些企业用户已经有一套自己的企业级虚拟化环境，大量的虚拟机运行在这些企业级的虚拟化环境中，当用户迁移到云的时候，需要考虑更多的兼容性问题，因此这些企业用户希望服务器是物理机，从而可以不改动底层的虚拟化环境，整体迁移到云计算环境。物理机实例的需求给云计算运行环境带来了非常大的挑战，例如：
·我们很难把网络VPC、分布式存储等后台I/O工作负载添加到用户的业务实例中。
·无法实现物理机实例的高可用（物理机无法迁移）。
·面临很多I/O接口不一致的问题。
1.4.6 硬件的功能扩展
在处理某个任务时，软件处理比硬件处理的灵活性更好；而硬件处理比软件处理的处理性能更好。硬件处理一旦确定就很难更改，也意味着很难再加入新的功能。
传统的SoC芯片上通常会集成有参与数据面处理的高性能处理器，可以通过加入软件处理的方式实现功能扩展，但这种方式存在性能瓶颈问题。云计算场景对处理的带宽、延迟、OPS（Operations Per Second）等非常敏感，基于软件的功能扩展并不是很好的解决办法。PCIe等芯片间总线互连的性能远低于片内总线互连的性能。例如，CPU+GPU等异构加速架构通过片间总线互连，同时加入软件的任务处理，数据要频繁地在两者之间交互，性能很差。
由于硬件处理加入的延迟非常有限，几乎可以忽略，因此带宽、OPS能够保持一致。加入独立的硬件处理来进行功能的扩展会是一种比较好的办法，但硬件功能扩展面临如下几方面的挑战。
·硬件部分可编程。利用FPGA可以支持硬件可编程，但如果完全基于FPGA实现所有的硬件处理，那么又会得不偿失。因为对于同样的硬件逻辑，基于FPGA的实现比基于ASIC的实现性能更差、成本更高。通常我们将ASIC和FPGA配合使用，比如，把80%的硬件功能用ASIC实现，把20%的硬件功能用FPGA实现。
·接口标准化。固定的硬件处理需要为扩展的硬件处理提供标准的数据I/O接口，扩展的硬件处理需要具有标准的配置接口等。
·功能扩展平台化。与基于FPGA实现的硬件加速平台类似，基于FPGA实现的硬件处理需要把支持扩展的整个架构平台化，这样才能比较高效地加入扩展的功能。
1.4.7 让硬件快速迭代
嘀嗒（Tick-Tock）模式是英特尔芯片技术发展的战略模式：在Tick年，设计的微架构不变，通过改进制造工艺来提升CPU的性能；在Tock年，制造工艺不变，通过设计全新的微架构来提升CPU的性能。采用嘀嗒模式，既能稳妥地让制造工艺和微架构设计相互印证，又能够把2年迭代一次CPU变成1年迭代一次CPU。
网络协议栈，通常用硬件实现比较稳定的物理层和数据链路层，用内核态实现通用的TCP/IP层，用用户态实现变化多样的应用层。
上述这些案例为我们提供了一些思路：我们可以把系统实现分为硬件ASIC、可编程FPGA、底层系统栈、上层应用4种类型。我们用硬件ASIC实现一些基础架构和路径，ASIC可以2年左右周期迭代；FPGA可以半年左右周期迭代，这样在以ASIC为基础的硬件整个生命周期，我们大概可以迭代4版硬件。快速的硬件迭代可以最大限度地发挥硬件的价值，并且在新版本ASIC的迭代过程中，我们可以把一些成熟的硬件逻辑从FPGA转移到ASIC，实现硬件到硬件的“卸载”。
硬件快速迭代最大的挑战在于如何像软件系统分层那样，构建分层的硬件体系结构，设计好各个分层的功能，并定义好标准、清晰、简洁的层间接口。
1.4.8 硬件高可用
对于云计算服务来说，可用性是非常重要的指标。例如，AWS的SLA（Service-Level Agreement，服务等级协议）可以保证一个区域内的EC2和EBS月度正常运行时间百分比至少达到99.99%。虽然单点的故障概率很低，但大规模的数据中心每天仍会发生数百起故障。主流的互联网系统都是基于大规模服务器集群构建的，单点的故障会导致非常严重的问题。软件层面通过非常复杂的技术来保证云计算服务的高可用，如采用虚拟机Live Migration、主备切换、负载均衡、分布式存储等技术。更稳妥的做法还是在硬件层面实现高可用。
·提升硬件稳定性。ASIC芯片的初始成本很高，芯片公司只有大规模提升单款ASIC芯片的销售数量才能最大限度地实现销售收入。为了提升单款ASIC芯片的销售数量，就需要让芯片产品适应尽可能多的场景，这增加了ASIC芯片的复杂度。即使ASIC芯片经过充分的验证测试，却仍然很难完全适应各种应用场景。很多互联网公司自己做硬件，并可针对特定应用场景定制，不但不需要应付各种各样的应用场景，还能够用实际业务环境的灰度机制来做好压力测试，效果会好很多。
·多路独立硬件资源。我们可以采用一定的机制把多路独立硬件资源当作一个整体，使它们共同服务于上层软件，当其中部分资源出现故障的时候，仍然可以为上层软件提供一定程度的服务。
·快速故障检测和自重启恢复。受到多租户的影响，云计算服务需要构建基于硬件虚拟化粒度的故障检测和恢复机制。
·硬件可在线可升级。我们可以利用FPGA的可现场编程特性不断地优化硬件设计，提高硬件的稳定性。