Netflix是如何使用Node.js杀死整体单片Monolith?

17-03-28 banq
         

Netflix的订阅用户越来越多--与Node.js互动对话的时间接近8500万,产生了许多具有挑战性的规模问题。Yunong Xiao,Netflix首席软件工程师介绍了这些挑战,并解释公司如何从内容提供商发展为一个不断增长的全球平台,该平台支持所有现代浏览器,游戏机,智能电视甚至更多。他还着眼于介绍如何改变交付框架从根本上提升了灵活和弹性的。

Netflix应付其不断膨胀的用户第一步是他们将所有的基础设施迁移到云。这并不意味着一旦迁移完成,开发者可以“坐着看电视节目。“,云毕竟是使用别人的电脑,如何扩展用户数规模仅仅是问题的一部分。随着用户数量的增长,需要交付的平台数量也增加。在第一次迭代时,Netflix只能工作在浏览器和一个简单的java web服务器托管。服务器也或多或少都能呈现用户界面和访问数据。

Netflix依托微服务提供多样化的特点。每个微服务有一个开发团队,或多或少拥有服务,并提供一个客户端调用java服务器。java服务器--这个故事中的庞然大物——遭遇几个问题。首先,它推动创新非常缓慢。每当一个新的节目推出,他们希望用户界面添加新的滚动字幕,他们不得不发布新服务。如果一个开发团队推出了一个新的和改进的客户端版本,他们不得不再发布服务。当一个新的微服务被添加时,他们不得不又要发布服务。此外,增加支持设备的数量几乎是不可能的。

所以,在下一次迭代中,开发团队迁移到REST API。这下解锁就支持更多设备的能力了。新的框架分离了UI渲染和数据访问过程。然而,REST API也有其缺点。一是不灵活,它最初为一种设备装置而设计,增加新的设备是痛苦的。同时,当不同团队拥有REST API时,微服务团队经常等待API改变以支持新的服务。

它也被证明是低效的,REST时基于资源,而Netflix的UI很少是基于资源的,例如,为了抓取客户所有喜爱的电影,服务必须多次往返到后端。最终,它被证明是难以维持,因为API变得更加复杂和臃肿,开发者试图改造它以实现更多的功能。

不同的开发团队需要灵活性以支持他们为平台所做的创新,由此发现REST API太笨重,限制了灵活性,因此需要另一个进化的Netflix的框架。

API.NEXT是允许上传自定义API到其中的专门服务器。团队可以在不影响彼此的情况下改变脚本(Groovy编写)。API服务本身也可以独立更新,问题是,z整体单片Monolith架构又回来了,并导致规模扩展问题。Netflix有数以千计的脚本共享相同的空间,数以百万计的客户端,内存,CPU或I/O带宽经常会耗尽,这导致了昂贵的升级。如果一个脚本有内存泄漏,它会发生停机。

另一个问题“开发者工效。”API.NEXT服务器是一个非常复杂的具有多个运动部件的软件。脚本不可以进行本地测试,测试脚本时,团队必须上传到一个测试的网站,运行它,测试它,并且,如果有任何问题再解决问题。这个过程是缓慢和不便的,导致Netflix当前框架的迭代,需要考虑可扩展性和可用性,以及开发人员的工作效率。

当设计新的框架时,需要基于可扩展性/可用性方面,其中一个目标是实现进程隔离以避免问题。它还要求数据访问脚本和API服务器分离,降低基础设施维护成本。设计师也要降低启动时间和不可变得部署配置,这将允许产生不同版本的构建。

为开发者的生产力考虑,大多数开发者想在服务器和客户端使用相同的语言(最好是JavaScript),而不是前后端有两种不同的技术栈。他们还需要能够局部运行测试,有更快的增量构建,以及环境尽可能更紧密反映生产现场。

新的框架被称为新一代的数据访问API,已经把所有的数据访问API变为Node.js的独立应用程序。每个应用程序现在被隔离在Docker容器中运行。后端服务都包含在一个基于java的服务器中,Netflix开发团队通过远程服务层调用。RSL集成后端服务在一个一致的API,当开发者要部署一个新的API,他们把JavaScript以Node.js容器发布到服务器。

总的来说,Netflix当前结合Java/Node平台,允许更快和更容易部署,减少了现有单片monolithic架构的问题和困扰。

更多视频见:

Slaying Monoliths at Netflix with Node.js | Linux.

         

4