共计 2765 个字符，预计需要花费 7 分钟才能阅读完成。
简介： 语雀是一个业余的云端知识库，用于团队的文档合作。当初已是阿里员工进行文档编写和常识积淀的标配，并于 2018 年开始对外提供服务。
客户介绍
语雀是一个业余的云端知识库，用于团队的文档合作。当初已是阿里员工进行文档编写和常识积淀的标配，并于 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 格局的文档内容，咱们须要将其转换成为语雀本人的文档格局。在绝大部分状况下，解析用户输出的内容都很快，然而仍然存在某些无奈预料到的场景会触发解析器的 bug 而导致死循环的呈现，甚至咱们不太敢降级 Markdown 解析库和相干插件免得引入更多的问题。然而随着函数计算的引入，咱们将这个耗费 CPU 的转换逻辑放到函数计算上，语雀的主服务稳定性不会再被影响。”
除了帮忙 Web 零碎分担一些 CPU 密集型操作以外，函数计算还能做什么呢？
语雀反对应用各种代码模式来绘图，包含 Plantuml、公式、Mermaid，还有一些将文档导出成 PDF、图片等性能。这些场景有两个特点：
1、他们依赖于一些简单的应用软件，例如 Puppeteer、Graphviz 等；
2、可能须要执行用户输出的内容；
反对这类场景看似简略，通过 process.exec 子过程调用一下就搞定了。然而当咱们想把它做成一个稳固的对外服务时，问题就呈现了。这些简单的应用软件可能从设计上并没有思考要长期运行，长期运行时的内存占用、稳定性可能会有一些问题，同时在被大并发调用时，对 CPU 的压力十分大。再加上有些场景须要运行用户输出的代码，攻击者通过构建歹意输出，能够在服务器上运行攻打代码，十分危险。
在没有引入函数计算之前，语雀为了反对这些性能，只管独自调配了一个工作集群，在下面运行这些三方服务，承受主服务的申请来防止影响主服务的稳定性。然而为了解决下面提到的一系列问题还须要付出很大的老本：
1、须要维持一个不小的工作集群，只管可能大部分工夫都用不上那么多资源。
2、须要定时对三方应用软件进行重启，防止长时间运行带来的内存泄露，即便如此有些非凡申请也会造成第三方软件的不稳固。
3、对用户的输出进行检测和过滤，避免黑客歹意攻打，而黑客的攻打代码很难齐全防住，平安危险仍旧很大。
最初语雀将所有的第三方服务都别离打包在函数中，将这个工作集群上的性能都拆分成了一系列的函数放到了函数计算上。通过函数计算的特点一下解决了下面的所有问题：
1、函数计算的计费模式是依照代码理论运行的 CPU 工夫计费，不须要长期保护一个工作集群了。
2、函数计算上的函数运行时只管会有一些常驻函数的优化，然而根本不必思考长期运行带来的一系列问题，且每次调用之间都互相独立，不会相互影响。
3、用户的输出代码是运行在一个沙箱容器中，即使不对用户输出做任何过滤，歹意攻击者也拿不到任何敏感信息，同时也无奈进入外部网络执行代码，更加平安。
除了下面提到的这些性能之外，语雀最近还应用 OSS + 函数计算替换了之前应用的阿里云视频点播服务来进行视频和音频的转码。
因为浏览器能够间接反对播放的音视频格局并不多，大量用户上传的视频想要可能间接在语雀上进行播放须要对它们进行转码，业界个别都是通过 FFmpeg 来对音视频进行转码的。转码服务也是一个典型的 CPU 密集型场景，如果要本人搭建视频转码集群会面临大量的资源节约，而应用阿里云视频点播服务，老本也比拟高，而且可能管制的货色也不够多。函数计算间接集成了 FFmpeg 提供音视频解决能力，并集成到利用核心，配合 SLS 欠缺了监控和数据分析。语雀将音视频解决从视频点播服务迁徙到函数计算之后，通过优化压缩率、缩小不必要的转码等优化，将费用升高至之前的 1/5。
应用成果
语雀产品技术负责人不四示意：从语雀的实际来看，语雀并没有像 SFF 一样将 Web 服务迁徙到函数计算之上（SFF 模式并不是当初的函数计算架构所善于的），然而函数计算在语雀整体的架构中对稳定性、安全性和老本管制起到了十分重要的作用。总结下来函数计算非常适合上面几种场景：
1、对于时效性要求不算十分高的 CPU 密集型操作，分担主服务 CPU 压力。
2、当做沙箱环境执行用户提交的代码。
3、运行不稳固的三方应用软件服务。
4、须要很强动静伸缩能力的服务。
在引入函数计算之后，语雀现阶段的架构变成了以一个 Monolith Application 为外围，并将一些独立的功能模块依据应用场景和对能力的要求别离拆分成了 Microservices 和 Serverless 架构。利用架构与团队成员组成、业务状态非亲非故，然而随着各种云服务与基础设施的欠缺，咱们能够更自若的抉择更适合的架构。
因为 Serverless 的呈现，咱们能够将这些存在平安危险的，耗费大量 CPU 计算的工作都迁徙到函数计算上。它运行在沙箱环境中，不必放心用户的恶意代码造成平安危险，同时将这些 CPU 密集型的工作从主服务中剥离，避免出现并发时阻塞主服务。按需付费的形式也能够大大节约老本，不须要为低频性能场景部署一个常驻服务。所以咱们会尽量的把这类服务都迁徙到 Serverless 上。
原文链接
本文为阿里云原创内容，未经容许不得转载。
