这是我们真实的选择器推断图。每个节点表示 Stormcrow 中的选择器类型。例如，viewer是一个非常方便的模型，因为我们可以使用它来推断session，team，user和 identity。

　　我们发现选择器推断为开发人员带来了巨大便利，同时易于理解。当然我们也有检查工具来确保开发人员不会传递错误的选择器。请参阅后面的“审核挑战”

　　部署：Web 和内部基础设施

　　如果你有大量生产服务器，如何将功能门控的配置部署到它们上面呢？很显然，我们需要将功能门控相关的数据保存在数据库中，但是那么就需要一次网络调用来检索。dropbox.com 上一次典型的页面加载中可能会涉及大量的功能门控，这会导致对数据库的大量读取。即使使用精心设计的缓存系统（例如使用本地缓存+ memcached）缓解这些问题，数据库也会成为系统的单点故障。

　　相反，我们将一个名为 stormcrow_config.json的 JSON 文件部署到所有的生产服务器上。这个部署仅仅使用我们的内部推送系统，并且在每次对 Stormcrow 配置进行更改时推送。

　　我们所有的服务器都运行一个称为“Stormcrow 加载器”的后台线程，它监视磁盘上的 stormcrow_config.json副本，当它改变时就重新加载它。这让 Stormcrow 不用中断服务器就可以重新加载。

　　如果由于某种原因找不到配置文件，那么 Stormcrow 也能够回退到直接访问数据库，但是对于任何大流量的系统来说，这是非常危险和不推荐的做法。

　　部署：桌面端和移动端

　　对桌面版和移动版的功能开关稍有不同。对于这些客户端，它们通常是批量请求开关相关的信息。比如从后端获得的 Stormcrow：

　　这两种平台上的客户端还会传递一个或多个包含平台特定信息的特殊选择器。移动客户端传递一个选择器，提供关于正在使用的 App 和设备本身的信息。桌面客户端则传递一个带有桌面主机信息的选择器。与其他选择器一样，Stormcrow 有可根据这些平台特殊的选择器来定义规则的数据字段。

　　监控

　　Stormcrow 中所有被开关的功能的每次分配和曝光，都会记录到我们的实时监控系统 Vortex 中。 Stormcrow UI 中嵌入了图表，用户可以利用其来跟踪分配和曝光的速率。例如，下图显示了三种不同的变量（黄色，蓝色和绿色），以及每个变量随时间曝光给用户的数量。 每次修改功能（或功能所依赖的群体）时，图表中会用垂直线注释。这使我们很容易地看到变更的影响。在该图中，我们可以看到绿色和蓝色变量在第一次修改之后收敛（垂直线），j2直播，同时黄色变量上升。

　　用户还可以单击底部的链接，使用我们的 Vortex 或其他数据工具更详细地挖掘数据。

　　性能风险

　　由于 Stormcrow 的模块化数据字段设计，Dropbox 的开发人员可能直接或间接得编写严重影响性能的数据字段。比如：有人创建一个新的数据字段，对于他们的小型业务来说是非常安全的，但这个数据字段也可被其他人使用，这就可能造成小型业务系统无法承载大量的请求流量。

　　这告诉我们一个重要的教训：在功能开关中要避免数据库调用或其他 I/O！

　　相反，调用方应该传递进来尽可能多的信息。这样避免 Stormcrow 因为推断而产生的隐式 I/O ，同时调用方的显式 I/O 也使得调用方更好评估性能的损耗。

　　理想情况下，Stormcrow 应是完全“纯粹的”（以函数式编程而言），并不会执行任何 I/O。目前我们还没有能够做到这一点，因为一些实际的原因：有时为调用方提供一个便捷的 API 意味着 Stormcrow 需要做更多并付出性能代价。

　　审计挑战

　　功能开关有一方面比较棘手，因为它们没有被纳入版本控制中：它们可以独立于使用方代码进行更改。通过我们的“每日推送”系统（对于我们的后端）或通过桌面版或移动版客户端的发布过程，Dropbox 中的代码上线以可预测的方式进行。 但对于功能开关的变更，由于它们的性质，可以发生在白天或晚上的任何时间。因此，拥有完善的审计工具很重要，因为我们可以尽可能快地跟踪功能开关相关的回归。

　　Stormcrow 通过提供完整的审核历史记录，以及静态分析代码库中的功能来解决此问题。

　　审核历史记录很简单：我们对给定功能和群体的所有历史修改显示一个类似 “News Feed” 的视图。