Spotify如何对ApacheStorm进行规模扩展.docxVIP

Spotify如何对Apache Storm进行规模扩展【编者的话】Spotify是一家音乐流媒体服务商，必威体育精装版的数据显示他们已经有6000万用户。Spotify内部使用Apache Storm来构建实时类系统，包括广告定位、音乐推荐以及数据可视化等。本文来自Spotify官方技术博客，介绍了Spotify公司如何使用Apache Storm来构建可扩展的个性化系统的。Spotify已经在很多业务中使用Apache Storm来构建多种实时系统，包括https://www.hakkalabs.co/articles/spotifys-ad-targeting-infrastructure广告定位、https://www.hakkalabs.co/articles/storm-spotify-deployment-use-cases音乐推荐以及/us/arts/serendipity/数据可视化等。其中每一种实时系统都将Apache Storm与其它不同系统加以结合，例如Kafka、Cassandra、Zookeeper以及其它数据输入和输出的系统。Spotify在全球范围内拥有/us/information/超过五千万的活跃用户，所以在应用构建时需要考虑可扩展性以保证应用的性能以及高可用性。Thinking Scalability面对资源线性增长所带来的负载压力提升，可扩展性已经成为软件保持理想性能表现的前提。不过要真正实现可扩展目标，单靠添加资源并对性能进行调整还远远不够。具体而言，可扩展性要求大家对软件方案的设计、质量、可维护性以及性能等方面整体考量。当我们构建应用程序时，首先应该从以下几个方面对可扩展性进行规划（保证应用可扩展性的必要条件）：软件具备良好的架构与较高的质量。软件应该易于发布、监控与修改。软件性能可以跟得上资源线性提升所带来的额外负载增长。Storm中的可扩展性那么对Storm流程加以扩展需要在哪些方面做出努力？下面我将通过自己的实时个性化Storm系统作为实例，向大家阐述可扩展能力中的方方面面。在我们的个性化系统中，使用Kafka集群的Topic（译者注：一个Topic可以认为是一类消息，每个Topic将被分成多个partition）来处理不同类型的事件，比如歌曲完成与广告曝光。我们的个性化Storm拓扑可以订阅不同的用户事件，并将这些事件与读取自Cassandra的实体元数据（例如歌曲流派）相结合，然后将每位用户的事件进行分组，进而通过某种包含聚合与推导机制的算法计算出用户属性。这些用户属性会被写入Canssandra，最后会被多种后端服务使用以提供个性化的用户体验。设计与质量当我们将随着时间推移将更多新功能添加到以上个性化流程当中时，我们的拓扑结构开始变得复杂，并直接导致性能调整与事件流调试的难度越来越高。不过较高的测试覆盖率让我们对自身的代码质量充满信心，因此我们认为自己有能力对拓扑进行快速重构并使其投入正常运作。拓扑架构在将复杂拓扑转化为小型可维护拓扑的整个转换周期当中，我们通过实际操作得到了以下启示：为不同任务流创建小型逻辑拓扑通过共享库而非共享逻辑的方式提高代码的可重复使用度保证方法容易被测试并行与批量处理会降低IO操作质量我们已经使用Java开发了自己的流程，并借助JUnit对不同计算Bolt内的业务逻辑进行了测试。我们还利用backtype.storm.testing并通过集群模拟进行了端到端的测试。可维护性为了将软件轻松部署在集群内的新主机中并对其运行状况进行监控，我们采取了一系列措施来简化维护。配置对外暴露所有可调参数，这可以让我们在不变更任何代码的前提下实现软件调整，同时也让我们能够更轻松地实现小型增量变更并观察其实际影响。我们将bolt parallelism、source endpoints、sink endpoints以及其它拓扑性能参数映射到了一个配置文件中。指标可视化我们为拓扑指标创建了一套仪表板（dashboard），旨在整体评估其运作状态并进行问题排查。我们采用高级度量指标（详见下图）对整套系统的运行状态加以汇总，因为在面对一套充满了各类指标，但又缺乏重点倾向性的仪表板时，大家往往很难从中找到真正值得关注的信息。拓扑部署我们这套个性化流程中的全部计算任务都是幂等的，我们还设计出了自己的部署方案，在事件处理中允许少量的重复以确保部署过程中不会丢失消息。这套方案并不适用于全部用例，特别是在计算任务以事务形式存在的情况下。在以上图表中，各事件由左至右依次排列，其中t1到t8代表着不同时间戳。在我们的部署方案当中，我们需要确保Storm集群可以同时运行两套个性化拓扑。在t1时间点上，集群运行的是个性化拓扑的v1版本。当我们准备好发布该个性化拓扑的v2版本时，我们会构建并将v2提交