Netflix API优化之路

美国在线视频商Netflix近些年引领着技术潮流,尤其是他们的一系列开源框架Netflix OSS,被整合入Spring Cloud成为新一代开源解决方案Pivotal的分布式系统开发框架。Netflix也是最早成功采用Microservice架构的公司之一,他们的架构演进来自于API平台部门(Netflix API Platform)的不断优化;这篇文章根据Netflix的技术博客,来讲一讲这段演进过程。

与许多互联网应用一样,Netflix采用了面向接口或服务的架构分离了界面层与数据层,API逐渐发展为了整个Netflix最核心的系统。2010年以后,Netflix的在线用户不断攀升,在2011年初已达到了200亿日请求量;通过架构评估,很明显,2008年的设计已经不再合适,Netflix需要一套新的API来适应他们的未来。

netflix-api-request-growth

全新的业务目标

Netflix梳理了他们的业务方向,发现,与这些年API开发需求的变化一致的是,Netflix的业务也改变了。过去,Netflix主要为用户提供DVD租赁,现在,虽然DVD业务还保留着,但流媒体业务在迅速增长;另外,Netflix不再只是向美国用户提供服务,而是打开了加拿大甚至面向着整个国际市场。这些业务的转变都意味着API功能的随之应变。

更高的性能要求

首先是降低已高达200亿的日请求数量。Netflix有大量的推荐算法,通过一系列的API调用最后渲染出最合适的用户界面。优化方式可以是,比如通过数据分析发现某类设备的请求占据了50%的请求比例,那么是否可能在API层封装一些“用户体验”,通过复用算法而减少API的调用计算步骤,从而大量减少请求数量?另外,如果把一切资源尽可能变成静态,是否可以降低25%左右的请求数量?Netflix事先做了大量的假设。

优化之前的架构

request-multi_1252

 

优化之后的架构

request-single_1252

其次是降低API的负载压力。Netflix的一项重要功能是对用户的使用体验进行了数据收集,在流媒体模式下,用户数量和停留时间上去后,这类请求也变得非常庞大。对此Netflix设计了支持Partial响应的API,从而降低了服务的负载。

分布式API开发

通常我们理解的分布式(Distribute)开发是指异地开发模式,而Netflix的Distribute意味着分权。通常一个企业会选择一类技术架构作为企业级技术架构选型,一种产品或一个系统在架构设计时也会确定其技术栈,目的都是通过一致性技术积累降低学习成本和开发难度。而Netflix彻彻底底改变了这个观点。

早期的Netflix是单一技术架构

netflix-api-pre-redesign-v2

到2013年,Netflix的流媒体已经支持了超过800种设备类型。用户和客户端的多样化,以及大数据等新技术的兴起,导致了Netflix必须招纳各类语言的人才,包括Javascript、Objective-C、Java、C、C#、Ruby、Python等等,拥有这些不同编程背景,但在其领域都能称之为专家的人才,Netflix必须考虑在API开发上做到分权决策,并在技术层面添加一层Functional Reactive Programming Model支持多语言开发调用。

微服务架构

上面提到,Netflix已经支持超过800种设备。多样的用户特征和需求以及频繁的改动让他们认识到,一套解决方案(One Size Fits All API)甚至一个公共平台式的团队(如API Team、UI Team)已不再适用于Netflix的业务,因为:

  1. API的通用性变得越来越差;
  2. 针对每一类设备,即每一类用户群体的创新速度都被拖慢了,因为他们所需要的任何客户端功能都涉及到跨团队沟通;
  3. 所有的创新速度都被拖慢了,因为API团队成为了效率瓶颈,他们疲于对各种待实现的功能特性进行优先级排序,并不断地延期;
  4. 导致越来越复杂和超负荷的请求,响应效率越来越低下;
  5. 系统里堆满了各种难以理解的特性标记来区分路由不同客户端的功能以及数据。

这一切,已经严重影响到了Netflix的用户需求实现、性能甚至创新。这就引出了现在被称为微服务(Microservcie)的架构方案,除了团队和架构上的分权自治,语言层面的兼容,因为服务的依赖复杂性,Netflix增加Hystrix回路熔断,这一套架构解决了以下问题:

  1. 某个API的停止服务不会破坏用户的使用体验;
  2. API在调用依赖失败时能够自动作出正确的选择判断;
  3. API能够报告它自己的状态,以及过去15~30分钟发生的事情。

architecture-overview_1252

在2014年,再演进了一层Script以简化服务的调用,被称之为Dynamic Script Platform.

scriptplatform_apiserver2_25

 

它通过部署流水线来保证Script的正确性。

scriptpipelineforblogv1

API部署流程

Netflix采用的代码分支策略包含Test/Release/Prod三种固定分支。

  • 开发人员平时工作在Test分支上,它的提交可以触发测试环境的自动部署;
  • Release分支用于每周自动部署,只需要把代码提交到Release分支上,它会触发自动化测试及集成测试,后续过程会由某个特定成员或部署团队启动,所有的动作都是自动化的。部署完成之后,代码会自动Push到Prod分支上;
  • 如果某个特性需要立即发布而不是通过每周固定发布流程;开发人员可以向Prod分支提交,这次提交会自动触发Release分支的合并并触发自动部署流程,如果审核人员通过,它将被立即部署。

Basic Build Test Deploy Flow

参考

http://www.infoq.com/news/2013/02/netflix-api-optimization/

http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html

http://techblog.netflix.com/2013/08/deploying-netflix-api.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>