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

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架构的问题和困扰。