在过去的几个月里，我为下一个版本开发的新功能之一是为我们的设备开发新的CLI。虽然对大多数用户来说，CLI是复选框项的缩影，但作为web API的一个完全不同的客户端消费者，它可能会有惊人的维护成本。我们即将发布的版本引入了许多新的概念，这些概念要求我们将web服务从零开始构建起来—改造旧的CLI根本不是一个选择。我们最终建立的是本地的节点.jsCLI采用以编程方式定义的web服务API定义，并动态构造一个结构化环境，以便通过这些API操作状态。用户可以使用他们的Delphix凭据通过SSH或控制台登录，并通过定制PAM集成获得此CLI。但是，每当我向人们描述这一点时，我得到的不仅仅是一些困惑的表情和问题：不是吗节点.js用于编写可大规模扩展的云应用程序？有人关心CLI吗？你兴奋吗？对节点.js现在很热。是的，一群欢乐的人（震中节点.js)都是Fishworks的前同事。但这里的道路，就像德尔菲的所有工程一样，最终都是基于实际问题的数据驱动，而这只是解决这些问题的最佳解决方案。我希望以后有更多关于架构的博客文章，但是当我为我们自己的开发人员写自述时，我认为第一篇文章的内容会是合理的。下面是工程常见问题解答。我希望从这里描述我们的模式和CLI的一些基本结构，敬请关注。为什么是本地CLI？以前的delphixcli是用groovy编写的客户端java应用程序。在客户机上运行CLI既给用户带来了成本（他们需要下载一个manage附加软件），也使跨不同服务器管理不同版本成为一场噩梦。现在几乎每个设备都有SSH接口；做一些不同的事情只会增加客户的困惑。所谓的好处（没有本机的windowssh客户端）在实践中已经被证明是微不足道的，还有其他更具伸缩性的解决方案来解决这个问题（比如分发javassh客户端）。为什么选择Javascript？我们知道我们将需要处理大量的动态状态，而CLI的范围将保持相对较小。动态脚本语言为快速开发提供了一个更具吸引力的开发环境，其代价是需要一个更健壮的单元测试框架来捕捉强类型静态编译语言中的编译时错误。我们明确选择javascript是因为我们的新GUI将用javascript构建，这既将生产中使用的语言和环境的数量保持在最低限度，也允许这些客户机在适用的地方共享代码。为什么？node.js？说到javascript，我们知道v8是最好的运行时，实际上我们是从一个定制的v8包装器开始的。作为单线程环境，这非常简单。但一旦我们开始考虑后台任务，我们就知道我们需要转向异步模型。在构建节点已经提供的基础设施的成本（HTTP请求处理、文件操作等）和支持异步活动的愿望之间节点.js是运行时的明确选择。为什么是自动生成的？从历史上看，在Delphix（和其他地方）维护CLI的成本一直很高。CLI功能落后于GUI，开发人员在将api移植到多个客户端时面临额外的负担。我们希望构建一个几乎完全由共享模式生成的CLI。当开发人员在一个地方更改模式时，我们会自动生成后端基础设施（java对象和常量）、GUI数据模型绑定和完整的CLI体验。为什么是模态层次结构？Delphix CLI的外观和感觉在许多方面都受到Fishworks CLI的启发。作为许多（坏的）CLI的工程师和用户，我们的经验使我们相信，具有集成帮助、选项卡完成和类似文件系统的层次结构的CLI可以促进探索，并且比具有几十个命令（每个命令都有几十个选项）的CLI更自然。它还可以更好地表示实际的web服务API（因此更容易自动生成），用户操作（list、select、update）反映了底层的crudapi操作。