应用设计考量：抽象、性能与可移植性探索

# 应用设计考量：抽象、性能与可移植性探索 ## 1. 抽象层次与复杂性 抽象在计算机科学中是一个重要概念，在计算机和软件工程的诸多实例中广泛应用。在软件开发里，抽象用于减少程序中信息的重复。控制抽象的基本机制是函数或子程序，数据抽象则包括各种形式的类型多态。更高级的机制将数据和控制抽象结合，如抽象数据类型（类、多态等），这些是软件开发人员常处理的抽象。 抽象的本质是在更高层次处理问题，关注关键细节，忽略底层的具体实现，并遵循“DRY原则”（不要重复自己）复用底层实现。这导致了整个计算机工程学科的分层架构，例如英特尔快速路径互连（QPI）协议、计算机网络协议的OSI模型、OpenGL库，以及大多数现代操作系统使用的字节流输入/输出（I/O）模型。 历史上，计算机平台在计算机架构中由五个抽象层次构成：硬件、固件、汇编器、操作系统和进程。虚拟化的发展为这个栈增加了更多层次。虽然这些额外的抽象层对于提高生产力是必要的，但栈深度的增加可能会影响应用程序的性能。 ## 2. 云环境中的原生硬件与虚拟化硬件 全硬件虚拟化是企业和云计算中广泛使用的一种抽象方法，在高性能计算（HPC）应用领域存在较大争议。硬件虚拟化（或平台虚拟化）中，虚拟机对操作系统而言就像一台真实的计算机。在这些虚拟机上执行的软件与底层硬件资源分离，并隐藏了具体的实现细节。不同级别的硬件虚拟化使用诸如仿真、二进制翻译和动态代码生成等技术。虚拟机由管理程序或虚拟机监视器（VMM）创建和管理，它们通常以软件形式实现，也可能是固件甚至硬件实现。 虚拟化技术源于大型计算机，在大型机和RISC服务器中早已存在。2005年x86服务器引入对管理程序的硬件支持，引发了x86领域对虚拟化的关注和使用热潮。硬件支持显著降低了性能开销，也消除了对操作系统内核进行二进制修补的需求。多个商业（如VMWare、Parallels等）和开源（Xen、KVM等）管理程序的积极开发，使硬件虚拟化成为企业数据中心和云计算应用的基础技术。它推动了软件定义存储（SDS）和软件定义网络（SDN）等热门方向的发展，最终催生了软件定义数据中心（SDDC）的概念，将虚拟化概念（如抽象、池化和自动化）扩展到数据中心的所有资源和服务，以实现IT即服务。 完整的系统虚拟化带来了一些操作优势，例如简化配置（通过应用程序软件与操作系统环境的更高级集成），为应用程序提供稳定的软件映像，并在VMM级别处理新旧硬件的仿真，这有助于在不修改软件的情况下使遗留软件在现代硬件上运行。对于企业和云应用，虚拟化还提供了额外价值，管理程序允许实现多种可靠性技术（如虚拟机从一台机器迁移到另一台机器、系统级内存快照等），并通过整合提高利用率，即将多个未充分利用的虚拟机放在一台物理服务器上。 然而，硬件虚拟化在HPC用户社区的发展速度较慢。虽然不采用硬件虚拟化的主要原因常被认为是管理程序带来的性能开销，但这可能是最具争议的一点。有研究表明，对于某些工作负载，这种开销相当小，并且按使用付费的作业运行模式可能比购买和管理自己的集群更具成本效益。实际上可能还有其他原因，例如企业和云应用客户认可的虚拟化价值对HPC用户缺乏吸引力。整合在HPC中几乎无用（尽管可以使用流行的HPC批处理作业调度器实现），实时迁移和快照的可扩展性不如HPC中使用的检查点技术。不过，大型云提供商提供的虚拟化硬件成本降低，在某种程度上已经促使人们探索在托管云服务中运行高性能计算应用程序的需求。这一趋势将推动对HPC应用程序（紧密耦合的分布式内存应用程序）在托管虚拟化环境中执行的优化需求，因此迫切需要工具和技术的发展来高效完成这项工作。 ## 3. 应用设计的问题 抽象是不可避免的。有些抽象我们可以选择，如应用程序架构、编程语言，或者是否在虚拟化或“裸机”操作系统下运行；而大多数其他抽象我们只能接受，如现代处理器内部的指令解码或操作系统的虚拟内存管理。无论如何，每个抽象层都会在数据流的队列管道中增加一个阶段，并使控制路径复杂化，这可能会也可能不会成为应用程序性能的瓶颈。随着应用程序复杂性的增加，有必要识别抽象带来的瓶颈，并量化它们对应用程序的影响。 由于不可能编写一本指南或提供一套全面的建议来避免应用程序的所有潜在性能问题，我们建议采用不同的方法。在开发新应用程序或分析现有代码时，需要了解可用的选项和不可避免的限制。实际上，在应用程序性能和生产力之间，以及最终程序的可维护性和质量之间存在权衡。在应用程序或系统设计和优化工作中，考虑以下几个问题有助于在编程和执行环境以及相关中间件方面做出正确决策。回答这些问题将增进对应用程序的了解，同时也能让我们更有条理地理解实现理想特性所需的权衡。 ## 4. 性能和可扩展性设计 HPC关注应用程序的可扩展性以及使用并行计算机解决大型问题的能力。因此，通过实现可扩展性来实现高性能是HPC方法的关键区别。在考虑应用程序扩展相关问题时，需要牢记阿姆达尔定律和古斯塔夫森观察。例如： - 应用程序串行（非并行）运行的最小时间份额是多少？在阿姆达尔定律公式中，我们用f表示这个时间份额。 - 当添加更多计算节点或线程时，串行部分所占的时间份额如何变化？换句话说，考虑f是一个常数还是取决于所使用的处理器数量p。 对这两个问题的实际回答是理解应用程序扩展限制的良好开端。例如，在64个处理器上运行一个应用程序，如果在特定实现中，大约10%的时间是串行执行（即f = 0.1），那么