当前位置: 乐呵网 > js学习网 > JavaScript教程 >

容器在Spotify、DramaFever、Built.io和IIIEPE的使用案例

时间:2016-10-19 12:11来源:乐呵网提供 作者:乐呵网 点击:
仅仅一年时间,容器已经开始渗透进企业的整体架构里了。


音乐流服务Spotify,视频流公司DramaFever,后台即服务供应商Built.io,以及教育界智库“Instituto de Investigacion, Innovacion y Estudios de Posgrado para la Educacion”(IIIEPE)的共同点是什么呢?它们全都使用容器运行其关键的Web基础架构。

它们的案例体现了使用微服务架构,创建Web应用程序,以及在生产环境运行容器的的优势和挑战。

运行大规模全球应用程序

Spotify有全功能的主机,包括使用社交媒体身份认证登录,基于之前所听的音乐进行推荐,以及共享音乐。但是播放音乐的功能是最为重要的。要让Spotify的6000万用户满意,音乐就必须保持流畅,即使某个开发人员在专辑封面特性上制造了一个bug,或者其4个不同的数据中心里的5000多台生产服务器中的某个宕机了。

要达到这一目的,Spotify将其每个单独特性都打包成一个微服务。随后使用容器协助将其中一些微服务组合在一起,这样单次请求就能够得到所有相关信息,并且展示在用户——以及可能的订阅者——的界面上,而无需执行很多次重复的调用才能匹配上特定信息。这样的设计使得其他微服务可以同时独立地运行。

在旧金山的DockerCon 2014大会上,Spotify软件工程师Rohan Singh介绍了Spotify计划将微服务打包到容器流里,能够在全球根据用户需求进行伸缩。Singh在DockerCon上的演讲正发生在Spotify计划在生产环境里部署容器的第一周。九个月后——2015年三月——Spotify的Evgeny Goldin在Tel Aviv的DevCon现场介绍了独家秘籍,介绍容器如何作为流服务的持续交付文化的中心。

Goldin称Spotify的问题为NxM:“你有‘N’个服务,想将其部署到‘M’台主机上,”他对DevCon的听众说。

NxM问题指的是使用Spotify时会出现的规模化问题,全球用户都以自己的方式使用着Spotify,启用并停用特性,播放音乐,或者在夜间关闭应用程序的使用。因此,Spotify用户的应用程序要求特定的微服务,它发送请求给Spotify的服务器,并且得到所需数据。随着新特性的逐步添加,或者更多用户同时请求启动他们自己的应用程序服务,Spotify需要启动更多的容器来满足这些额外的需求,并且随后在不需要维护这么多服务器的处理能力时销毁掉这些容器。

要满足这样的需求,Spotify创建了开源项目Helios。

“我们称之为Docker编排框架。它解决了一个问题,并且确实解决得很好,”Singh说。“给出主机列表和需要部署的服务列表,它就会直接完成部署,”Goldin说。

从2014年7月份开始,Spotify开始在生产环境上使用容器和Helios模型,这是Spotify可扩展战略的关键一步。“我们已经在生产环境里的上百台机器上使用,”团队在GitHub上的Helios README文件里发表了声明。“但是我们还没有接近容器使用上限,目前还不需要重新审核已有框架。”

DramaFever的视频需求

DramaFever运行白标网站,比如AMC的SundanceNow Doc Club,并且支持流网站Shudder,也有合同义务向其他流服务提供内容。Kromhout,是Pivotal的Cloud Froundry的资深技术人员,之前负责DramaFever的站点可用性,谈及她在DramaFever的经历:“我们不是Netflix,也不是Hulu,但是如果你在Hullu上看韩剧,其实看的是DramaFever拥有版权的流内容。”

在她在DramaFever的工作期间,Kromhout用“cattle, not pets”的理念来实现架构,所有请求路径上的东西都容器化,能够自动扩展和收缩。DramaFever从2013年10月份开始在生产环境使用Docker 0.6版本。使用Docker帮助实现了一致的开发以及可重复的部署过程;容器帮助保证开发人员使用的代码和配置环境是相同的,即使他们将代码从笔记本移动到基于云的QA,预生产以及生产环境上。在架构自动扩展应用程序或者微服务组件的新实例时,容器里的代码是可信任的,因为其和任何测试或者开发的环境拥有相同的操作上下文。

“2014年7月份开始这项工作时,在生产环境使用Docker说明这是令人激动的工作之所,”Kromhout说。

DramaFever在生产环境里要实现高效的自动扩展,最初必须解决的障碍之一是,构建一个健壮的容器registry。Kromhout说,在分布式架构里,经常会遇到多个容器同时启动的情况。这是动态进行的,因此架构会基于使用情况按需启动实例以及启动容器。这些’docker pull’请求发送到私有Docker registry处。registry在大概20个容器同时启动时就面临崩溃。

要解决这个问题,DramaFever在每个地方,每台本地主机上,都运行了registry的容器,这样image pull会在本地完成,同时使用AWS S3作为后台存储。

(责任编辑:admin)
------分隔线----------------------------
栏目列表
推荐内容