ZStack--查询API

IaaS软件用户面临的共同挑战是如何快速、准确地找到一个想要的资源；例如，从10,000台虚拟机中发现有EIP（16.16.16.16）的虚拟机。大多数IaaS软件通过API中的特定查询逻辑解决这个问题。ZStack不用特定查询，而是配备了一个框架，这个框架可以自动为每个资源的每个字段生成查询，并联合跨越了多个资源的查询，帮助用户管理云端数量庞大的资源。

动机

一个中型的云可以管理几百台物理主机和成千上万台虚拟机，因为IaaS软件很少有全部的查询API，导致寻找想要的资源成为挑战。大多数IaaS软件只允许用户使用少量条件（如name，UUID）查询资源，这些条件硬编码在查询API中。如果用户想要使用硬编码之外的条件做一个查询，例如，通过创建日期查询虚拟机，他们可能不得不最终列出所有虚拟机，然后用for…loop来过滤结果。使用任意字段查询资源至今在大多数IaaS软件都不被完全支持，更不用说联合查询；例如，如果用户想要找到一个虚拟机，这个虚拟机的网卡应用了特定的安全组规则，他们可能不得不列出所有资源（虚拟机，安全组），然后做两次for…loop。

另一方面，相比类似JIRA的软件，大多数IaaS软件的UI是最粗糙简陋的。许多开发人员可能并没有意识到糟糕UI的根源不是因为UI开发人员缺乏CSS/HTML/JavaScript的技能，而是软件本身并不能提供强大的API来支持复杂的UI；例如，为了实现一个类似JIRA过滤器的功能，即只显示满足指定条件的资源，UI可能需要做很多的需要listing all
then filtering by for…loop的后置处理工作，这些后置处理工作将把大量的资源拧在一起。

IaaS软件因此饱受折磨了一段时间；对此的解药就是要提供一种机制，这种机制可以自动为每个资源的每个字段都生成查询，而且可以处理join查询。

问题

大多数IaaS软件使用关系型数据库（如MySQL）作为后台数据库，在这种数据库中资源通常被安排在单独的表中，比如虚拟机表，主机表，云盘表。对于每一个资源，都有一个API用来获取该资源的单独的一条，它可能被命名为describe API、list API或query API；这些API通常有硬编码的参数，用来暴露一部分数据库表的列，允许用户通过少量的查询条件查询资源；这些参数是精心选择的，通常是对API设计者自身非常重要的列，例如，name、UUID。然而，由于并不是所有的列都被暴露，用户经常遇到他们想查询的列不存在的情况，这样他们就必须检索所有的资源，然后使用一个或多个for…loop进行后置处理。