在本系列的第一部分中，我们向您介绍了黑暗发射的概念。在一个黑暗的启动中，您需要一个传入流量的副本并将其发送到新服务，然后丢弃结果。当你想启动现有服务的新版本时，暗启动是很有用的，但是当你打开它时，你不想看到令人讨厌的惊喜。在这篇博文中，我们将介绍一些可能给您带来困难的情况，并教您如何解决这些问题。

寻找流量来源

例如，假设您是一家在线目录公司，允许用户浏览实体店库存中的商品。该系统运行良好，但现在您希望用户能够购买其中一个项目。你将如何在黑暗中启动这一功能？当没有用户看到购买商品的选项时，您如何估计实际使用量？

一种方法是为每个用户对原始组件的查询启动对新组件的暗启动查询。在我们的示例中，每当用户发送某个项目的"查看"请求时，我们可能会发送该项目的后台"购买"请求。实际上，并不是每一个浏览某个项目的用户都会继续购买它，因此我们可能会通过每五次浏览中只发送一次"购买"请求来随机进行暗启动。

这将有希望为您提供一个关于流量和模式的活流量近似值。请注意，当服务启动时，对于实时流量而言，这并不是完全准确的。但是，这总比什么都没有好。

暗启动变异服务

除非您正在进行存储迁移，否则您需要在为变异查询进行暗启动时付出巨大的努力/付出巨大的代价。最简单的选择是为暗启动流量禁用变种，在变种准备好之后但在发送之前返回一个虚拟响应。这是安全的，但这确实意味着您没有获得对暗启动服务的完整度量—如果它有一个bug导致10%的mutate请求被错误地指定，该怎么办？

或者，您可以选择将突变发送到现有存储的临时副本。这对于测试的保真度来说要好得多，但是需要非常小心，以避免向真实用户发送来自临时副本的响应。如果在您的黑暗发布结束时，您在新服务仍然向临时重复存储发送突变的情况下使其生效，这对每个人来说都是非常不幸的。

存储迁移

一个好的原则是，在这个迁移过程中，如果新的存储系统出现问题，您应该始终确保可以恢复到旧的存储系统。您应该知道哪一个系统（旧的和新的）是给定查询集的主系统，并因此保持规范状态。主控权通常需要易于更改，并且能够在不丢失数据的情况下将责任恢复到原始存储系统。

存储迁移的普遍要求是一个详细的书面计划，不仅由您的系统利益相关者审核，而且还由相关系统的技术专家审核。不可避免地，您的计划将错过一些东西，并且在迁移过程中必须进行调整。在存储系统之间移动可能是一个非常大的冒险-希望我们在未来的博客文章中解决这个问题。

重复流量成本

在某些情况下，服务流量非常大，100%的暗启动是不现实的。在这些情况下，我们建议您确定实际可行的最大发射百分比，并进行相应的计划，以便在黑暗发射中获得最具代表性的流量选择。在谷歌内部，我们倾向于先向谷歌用户推出一项新服务，然后再公开这项服务。然而，经验告诉我们，googler在如何使用服务方面往往不能代表世界其他地方。

如果您的服务大量使用缓存，一个重要的考虑因素是，低于50%的暗启动不太可能看到缓存带来的实质性好处，因此可能会大大高估估计负载在100%。

您也可以选择在当前流量的100%以上通过复制一些流量来测试加载您的新服务-例如，为每个原始查询向新服务启动两个查询。这很好，但是你应该相应地调整你的配额增加。如果您的服务是缓存敏感的，那么这种方法可能不会有用，因为您的缓存命中率将被人为地提高。

由于重复流量的负载影响，您应该仔细考虑如何在这个实验中使用减载。特别是，所有暗启动流量都应标记为"sheddable"，因此是系统在负载情况下第一个丢弃的请求。

在任何情况下，如果您的呼叫服务发现CPU/内存/延迟意外增加，他们应将暗启动降低到0%，看看这是否有帮助。

摘要

可能您没有在你的生活中有足够的惊喜或兴奋；在这种情况下，你不需要担心黑暗的发射。但是如果你觉得你的服务已经给了你足够的肾上腺素，那么暗黑启动是一个很好的技术，可以让服务启动变得非常非常无聊。