改善十年应用的部署体验( 三 )

结果
我们设计Switchboard是为了改善我们Search系统的资源消耗，它已经做到了这一点。然而，分步部署的方法也给开发者带来了许多不错的工作流程改进。
Switchboard使我们能够将搜索虚拟机的总容量控制在或接近100% ，而非我们以前所支持的200%的容量，随着Search流量的增加，我们再也不必提供双倍的容量了。如今，适应流量的不安华变得更加容易，因为任何额外的的被动（自动）或主动（手动）扩展只需要为我们的真实容量保留计算服务，而不是两倍。所以，我们在发布Switchboard期间，云虚拟机的利用率有了明显的提高。

文章图片
几个月来，每个搜索请求的云成本（云计费总额/请求数）显示，我们在Switchboard之后，利用效率有所提高。
Switchboard的第二大成功在于，它使得我们在Staging环境中的部署速度不断提高。我们第一次尝试放弃传统的双重配置方法，就是在两次部署之间完全缩减未使用的搜索集群，然后预先对其进行重新配置，作为下一个部署的第一步。这种方法的一个问题就是，开发人员必须等待我们的Search系统内的所有服务被扩展到足以接受流量，然后他们才能在我们的Staging环境中进行测试。

文章图片
每个Staging环境部署所用的时间。每个单独的行是一个单独的部署。
总的来说，在实施Switchboard后，我们看到利用率的提高与中间解决方案相似，但却不必在较慢的部署时间上做出妥协。 Switchboard甚至还提高了中间解决方案的利用效率。
现在，在部署过程中发现和响应问题也变得更加容易。从技术上讲， Search部署的时间比我们维护两个完全扩展的集群时要长，但是这个额外的时间是由于自动流量滚动发布过程的渐进性造成的。人类搜索部署人员通常是被动地监控滚动发布阶段，根本没有交互。但是，如果他们需要的话，可以暂停滚动发布，检查当前的结果。 Search部署人员至少每月使用一次Switchboard来暂停滚动发布。我们以前根本就没有这个选项。由于Switchboard个别部署变得更加安全和可靠。
最后，重新架构我们的蓝绿部署流程，包括通过Switchboard进行金丝雀式的逐步流量提升，使我们的系统更具可扩展性和效率，同时也为开发者提供了更好的体验设计。为了充分利用Kubernetes和云环境的灵活性，我们成功地调整了搜索应用的架构。