CSDN|语雀的技术架构演进之路( 四 )

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

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

本文插图
为什么要特别把 Serverless 单独拿出来说呢？还记得之前说 Node.js 是单线程，不适合 CPU 密集型任务么？由于 Serverless 的出现，我们可以将这些存在安全风险的，消耗大量 CPU 计算的任务都迁移到函数计算上。它运行在沙箱环境中，不用担心用户的恶意代码造成安全风险，同时将这些 CPU 密集型的任务从主服务中剥离，避免出现并发时阻塞主服务。按需付费的方式也可以大大节约成本，不需要为低频功能场景部署一个常驻服务。所以我们会尽量的把这类服务都迁移到 Serverless 上（如阿里云函数计算）。
结语 | 语雀的技术栈选择语雀这几年一步步发展过来，背后的技术一直在演进，但是始终遵循了几条原则：

技术栈选型要匹配产品发展阶段。产品在不同的阶段对技术提出的要求是不一样的，越前期，对迭代效率的要求越高，商业化规模化之后，对稳定性、性能的要求就会变高。不需要一上来就用最先进的技术方案，而是需要和产品阶段一起考虑和权衡。
技术栈选型要结合团队成员的技术背景。语雀选择 JavaScript 全栈的原因是孵化语雀的团队，大部分都是 JavaScript 背景的程序员，同时 Node.js 在蚂蚁也算是一等公民，配套的设施相对完善。
【CSDN|语雀的技术架构演进之路】最重要的一点是，不论选择什么技术栈，安全、稳定、可维护（扩展）都是要考虑清楚的。用什么语言、用什么服务会变化，但是这些基础的安全意识、稳定性意识，如何编写可维护的代码，都是决定项目能否长期发展下去的重要因素。

本文作者：何翊宇，花名不四，高级前端技术专家，现就职于蚂蚁金服体验技术部，语雀产品技术负责人。 2011 年开始专注在 Node.js 与 Web 研发领域，负责过内部的 Node.js 的模块管理系统和中间件服务等基础设施，也做过 Node.js Web 框架的研发和开源。同时持续在使用 Node.js 进行产品研发，先后负责过淘宝时光机、天猫搭建渲染服务以及语雀等产品。开源爱好者， Koa.js 和 Egg.js 核心开发者， cnpm 中国镜像维护者。点分享点点赞点在看