I/O密集型应用模型 数据密集型应用 Node对CPU密集型的场景不够友好

语雀 https://help.aliyun.com/document_detail/193189.html

本文介绍如何通过函数计算，解决语雀CPU密集场景下，进程被阻塞等问题。

客户介绍

语雀是一个专业的云端知识库，用于团队的文档协作。现在已经是阿里巴巴员工进行文档编写和知识沉淀的标配，并于2018年开始对外提供服务。

客户痛点

语雀是一个复杂的Web应用，也是一个典型的数据密集型应用（Data-Intensive Application），背后依赖了大量的数据库等云服务。语雀服务端是Node.js技术栈。Node具有单线程（single-threaded）、非阻塞（non-blocking）、异步（asynchronously programming）等特性，这些特性一方面非常适合于构建可扩展的网络应用，用来实现Web服务这类I/O密集型的应用。但是，Node对CPU密集型的场景不够友好，一旦有任何阻塞进程的方法被执行，整个进程就被阻塞。

像语雀这样用Node实现整个服务端逻辑的应用，很难保证不会出现一些场景可能会消耗大量CPU甚至是死循环阻塞进程的，以Markdown转换举例，由于用户的输入无法穷举，总有各种可能让转换代码进入到一个低效甚至是死循环的场景之中。在Node刚出世的年代，很难给这些问题找到完美的解决办法。即便是Java等基于线程并发模型的语言，也无法完美解决这种场景。毕竟CPU对于Web应用来说是非常重要的资源。而随着基础设置越来越完善，当函数计算出现时，Node最大的短板看起来有了一个比较完美的解决方案。

解决方案

引入函数计算之后，语雀将CPU密集型、存在不稳定因素的操作放到函数计算服务中执行，而语雀的主服务再次回归到了I/O密集型应用模型，又可以体验Node给语雀带来的高效研发。

以语雀中遇到的一个实际场景来举例，您上传了一些HTML或者Markdown格式的文档内容，语雀需要将其转换成为语雀自己的文档格式。在绝大部分情况下，解析您输入的内容都很快，然而依然存在某些无法预料到的场景会触发解析器的故障而导致死循环的出现。甚至语雀不太敢升级Markdown解析库和相关插件以免引入更多的问题。但是随着函数计算的引入，语雀将这个消耗CPU的转换逻辑部署到函数计算上，语雀的主服务稳定性不会再被影响。

语雀支持使用各种代码形式来绘图，包括Plantuml、公式、Mermaid，还有一些将文档导出成PDF、图片等功能。这些场景有两个特点：

• 依赖于一些复杂的应用软件，例如Puppeteer、Graphviz等。
• 可能需要执行您输入的内容。

支持这类场景看似简单，通过process.exec子进程调用一下即可。但是当语雀想把它做成一个稳定的对外服务时。这些复杂的应用软件可能从设计上并没有考虑要长时间运行，内存占用、稳定性可能会有一些问题；同时这些应用在被大并发调用时，对CPU的压力非常大。再加上有些场景需要运行用户输入的代码，攻击者通过构建恶意输入，可以在服务器上运行攻击代码，非常危险。

在没有引入函数计算之前，语雀为了支持这些功能，尽管单独分配了一个任务集群，在上面运行这些三方服务，接受主服务的请求来避免影响主服务的稳定性。但是为了解决上面提到的一系列问题还需要付出很大的成本：

• 需要维持一个不小的任务集群，尽管可能大部分时间都用不上那么多资源。
• 需要定时对三方应用软件进行重启，避免长时间运行带来的内存泄漏，即便如此有些特殊请求也会造成第三方软件的不稳定。
• 对您的输入进行检测和过滤，防止黑客恶意攻击，而黑客的攻击代码很难完全防住，安全风险依旧很大。

最后语雀将所有的第三方服务都分别部署在函数计算中，将这个任务集群上的功能都拆分成了一系列的函数部署到函数计算。通过函数计算的特点一下解决了上面的所有问题：

• 函数计算的计费模式是按照代码实际运行的CPU时间计费，不需要长期维护一个任务集群了。
• 函数计算上的函数运行时尽管会有一些常驻函数的优化，但是基本不用考虑长期运行带来的一系列问题，且每次调用之间都相互独立，不会互相影响。
• 用户的输入代码是运行在一个沙箱容器中，即便不对用户输入做任何过滤，恶意攻击者也拿不到任何敏感信息，同时也无法进入内部网络执行代码，更加安全。

除了上面提到的这些功能之外，语雀最近还使用OSS加函数计算替换了之前使用的阿里云视频点播服务来进行视频和音频的转码。

由于浏览器可以直接支持播放的音视频格式并不多，大量用户上传的视频想要能够直接在语雀上进行播放需要对它们进行转码，业界一般都是通过FFmpeg来对音视频进行转码的。转码服务也是一个典型的CPU密集型场景，如果要自己搭建视频转码集群会面临大量的资源浪费，而使用阿里云视频点播服务，成本也比较高，而且能够控制的东西也不够多。函数计算直接集成了FFmpeg提供音视频处理能力，并集成到应用中心，配合SLS完善了监控和数据分析。语雀将音视频处理从视频点播服务迁移到函数计算之后，通过优化压缩率、减少不必要的转码等优化，将费用降低至之前的20%。

使用效果

从语雀的实践来看，语雀并没有像SFF一样将Web服务迁移到函数计算之上（SFF模式并不是现在的函数计算架构所擅长的），但是函数计算在语雀整体的架构中对稳定性、安全性和成本控制起到了非常重要的作用。总结下来函数计算非常适合下面几种场景：

• 对于时效性要求不算非常高的CPU密集型操作，分担主服务CPU压力。
• 当做沙箱环境执行用户提交的代码。
• 运行不稳定的三方应用软件服务。
• 需要很强动态伸缩能力的服务。

在引入函数计算之后，语雀现阶段的架构变成了以一个Monolith Application为核心，并将一些独立的功能模块根据使用场景和对能力的要求分别拆分成了Microservices和Serverless架构。应用架构与团队成员组成、业务形态息息相关，但是随着各种云服务与基础设施的完善，语雀可以更自如地选择更合适的架构。

由于Serverless的出现，语雀可以将这些存在安全风险的，消耗大量CPU计算的任务都迁移到函数计算上。它运行在沙箱环境中，不用担心用户的恶意代码造成安全风险，同时将这些CPU密集型的任务从主服务中剥离，避免出现并发时阻塞主服务。按需付费的方式也可以大大节约成本，不需要为低频功能场景部署一个常驻服务。

翻译

搜索

复制