作者： 马锐拉
我们的日常工作场景几乎离不开“云文档”。目前，人们对于文档的需求再不仅仅是简单的记录，而扩展到办公协同、信息组织、知识分享等。在国内众多在线文档中，wolai 因为功能新、迭代快、流畅的异地协同体验、高效的信息组织方式以及“信息块”信息整合等特点，作为一个独特的存在进入了人们的视线。人们关注 wolai 独特的功能和舒适的用户的用户体验，更关注实现这些背后的技术架构。在一个晴朗下午，我们邀请了 wolai.com 的创始人马锐拉，跟我们聊聊 wolai 背后的 Serverless 架构。
我为什么选择 Serverless 架构？
在做 「 wolai 」这款产品之初，我们就希望把架构彻底放到 Serverless 上。因此在技术选型阶段，对国内外几款 Serverless 产品进行了细致的调研，我们发现阿里云函数计算（FC）无论在支持上和整体解决方案上，优势都非常突出，并且跟我们的需求非常匹配，因此，我们决定选择 Serverless 架构，全面使用阿里云函数计算（FC）。
作为一个办公协同应用，wolai 具备多人同时在线编辑文档功能。要实现这个功能，一个非常稳定的 Web 服务接口和一个具备伸缩能力、支持高并发写入、读取分离的分布式数据库是非常重要的。因此当我们发现 Serverless 产品能够与分布式数据库进行很好的搭配，就初步确认了 wolai 的主体架构。
接下来我们开始在阿里云上验证使用阿里云函数计算（FC）的可行性。通过验证发现阿里云函数计算（FC）不光能帮助我们解决上述问题，还可以帮助我们大幅度节省人力成本和云资源使用成本的投入。
以一家初创公司为例，聊聊函数计算
接下来我想聊聊，为什么在创立公司之初，我会坚持选择 Serverless 架构。我曾在一家支付公司工作，所以我以一家比较典型的支付公司来举例说明。
不可避免的流量伸缩问题
假设你创立了一家支付公司，它的背后差不多需要 200 多个系统支撑，如果这些系统大部分都基于 Java ，这就意味着支付业务背后的机器是一台一台的集群，每一次发布研发都需要对这些集群进行分组，然后逐个上下线，这需要耗费巨大人力成本。
除了集群分组，研发们还需要关注缓存、日志系统等中间的各个系统是否有瓶颈。一旦发生问题，就需要在整个运维系统上花费巨大的精力去解决。随着公司的发展，你的这家公司的服务量级终于上升了，这时候你又会发现成本也随之大幅度上升了，比如需要部署新的机器，需要花费很多时间去做计算的伸缩工作（确切的说只是“伸”，根本就没有办法去“缩”，对不对？）所以流量伸缩问题会是你遇到的第一个问题，同时也是不可避免的问题。02
流量的波峰波谷问题
接下来，你还会遇到流量的波峰波谷问题。由于支付请求在晚上比较少，而在白天或大促、秒杀期间，支付请求的并发数可能会特别高。如果大批流量在同一时间涌进来，你就需要迅速拨计算资源过去，这需要做非常多的运维工作。
对一家刚创建不久的公司来说，你很难把大量的精力放在运维服务器上。而这时候你可以选择 Serverless ，它能够帮助你解决上述这些问题。你可以把运维服务器的工作放心的“丢”给 Serverless，而你真正需要关注的只有自己的业务逻辑。
我可以只关注代码和客户的需要
过去我们做 Web 服务，开发的工作重点在于在 web 服务器上做各种优化，其实这些工作都是在解决一个问题：当量级上去之后，服务器性能能不能抗住？如果不能要怎样做优化？开发者们做 Nginx 性能调优、负载均衡、反向代理等繁杂的优化工作，耗费了大量的时间，而当我们使用了函数计算之后，相当于把一大部分调优web 服务器的工作去掉了，这极大的节省了人力成本，提高了效率。使用函数计算之后，整个服务从开发到上线过程中，研发可以把绝大部分精力都放在业务代码上，无需关心服务本身是怎么稳定运行的。
自 2020 年 6 月 15 号业务上线以来，我们从来没有遇到服务 down 掉或者是需要下线维护的问题，而这些问题是使用函数计算前的常见问题。以往一旦遇到这样的问题，我们需要耗费很长时间寻找发生问题的原因，可能需要升级 Web 服务，加几台机器，甚至做反向代理和负载均衡……即使这些工作全部做完，再上线的服务还是会有维护时段，我们依然很难做到服务持续在线上。因此函数计算对我来说很重要的一个功能点就是持续服务的能力，通过使用函数计算，我的业务可以稳定地、持续地增量发布。
我在上一家任职时，每两周做一次版本发布，每次发布都有非常详细的发布列表，发布涉及的条件、依赖项非常多，需要运维去跑的脚本非常复杂，可以说只要出现一丁点错误，整个发布可能就会演变成一个小事故，甚至是大事故。当我们把整个架构放在 Serverless 上，把所有的功能进行拆分之后，发生事故的概率大大降低。即便发生问题，我可以通过快速回滚来解决问题。现在我们的研发习惯每天至少发布一个版本，当天所有解决的问题都会发布，相比传统的软件公司来说，部署在 Serverless 架构上我们的迭代速度会快很多。 01
快照保存系统，解决协同编辑算法问题
对于 wolai 这样的协同办公产品，协同编辑是产品的重中之重，这个功能对于算法的要求很高，通过使用函数计算我们同样很好的解决了这个问题。
wolai 云端笔记功能有一个信息块（Block）的概念，就是将用户所能接触到的最小信息单位从‘文件’缩小到‘信息块’”。“信息块”可容纳文字段落、表格、清单，以及嵌入来自外部的图片、视频等信息，且可被简易编辑、移动，经实时呈现后组成页面。所以接下来我会以“块”来指代信息块。
红底之上都是一个个独立的块
用户每次按键操作后，我们的前端都会有类似快照的保存机制。如果用户按键非常快，那他的多次按键操作可能在某一个时间切片中组成一个 transaction ，发回这个函数计算。然后我们就会记录下这些操作。当第二个用户同时进行按键操作时，如果他也针对同一个块做按键操作的话，他也会触发同样的操作。
我们会在函数里面去计算这些操作用户对这个块实际影响先后的顺序，最后得出它应该变成了一个什么样子，然后函数计算还会发出一个队列的请求，当有任何一个块，或者说它所属的页面发生过这个变化的事件之后，它会丢到这个 redis 里面，5 分钟之内一旦有一个块或者一个页面有过更新之后，我们会再调一个函数，把整个页面和整个块去生成一个一个快照。所以我们把函数和队列调用结合在一起做成了一个自动化的系统。
用户一旦在页面或者块上有编辑，我们都会在固定时间段生成一个快照。我们现在针对单个块（相当于单段文字或者说一个图片这样的一个最小单元）一分钟保存一张快照。相当于在1分钟之内，用户只要有过更新，我们都会把它整体变成一个快照，然后放到 OSS 上面去。如果每一个块是频繁更新，那么 OSS 上针对这个块会有特别多的一分钟的快照，目前我们 OSS 上差不多都已经有 10 亿多个文件了。如果是页面级别的编辑，wolai 5 分钟去保存快照，频率会低一点，通过函数计算和队列结合，我们制作了一个快照保存系统。
wolai 的 Serverless 架构图
使用 Serverless 解决的问题
通过研究 wolai 的用户行为会发现，我们的用户一般会在每天早上上班时打开 wolai 文档，然后他/她会在一天之中持续使用直至下班关闭。我们的用户并不会像小程序用户那样，需要快速打开应用，然后即用即走。相反，他们对于应用的初始加载速度没有特别高的要求，因此我们关注的重点并不是服务器端的渲染问题。通过研究用户习惯，我们更关注用户在打开应用后，操作的每一步是否能够快速响应的问题，这里面涉及到两个点：
1、用户把数据发到我的服务器上，服务器是否能快速、稳定的接收数据？
2、当有大量并发出现时，会不会让响应速度变慢
函数解耦，让小团队发挥大能量
通过使用函数计算，wolai 的前端工程师们就可以把从前到后的一整套开发流程负责起来，我们的研发迭代速度非常快。
为了实现快速迭代，节省人力，我们把应用的每一个小的功能点拆分的非常散，在函数计算上部署了非常多的服务，同时每个服务下又会有多个函数，通过人为拆散的方式实现了函数解耦。这样做的优势是当我们需要发布时，如果只针对一个函数做了某些优化或者 bug 修复的话，那就只需要发布这个函数，完全不需要做整体发布。因此我们可以每天快速累积发布，大部分函数完全解耦，互不影响。我们尽量把所有的函数完全独立开，变成独立的业务逻辑。这样可以保研发迭代的速度。
目前我们团队研发工程师有 10 个人。其中 8 位都是前端工程师，大大提高了团队人效。
小型企业使用函数计算，成本将节省 50%
在进行选型的时候，我们曾经对使用函数计算的成本问题进行过粗略的测算。我们测算的结果是，使用函数计算能比使用传统框架节省一半以上计算费用，人力的投入能够节省一半甚至更多。
我们可以算一笔账，如果选择传统架构，以目前系统的复杂度，我们的应用至少需要两个运维工程师。而现在前端工程师完全可以对系统进行从头到尾开发及维护。按照月均 3 万块钱的人力成本计算，算上场地、硬件的费用，对于小型公司来说一年至少可以节省 70-80 万的运维成本，同时计算资源成本也会同步增加，也就是说如果使用传统框架一年要花费 100 万的话，使用函数计算至少可以变成 50 万 。
从 2020 年 6 月上线至今，wolai 使用函数计算的过程非常顺滑，从选型到完成项目上线用了非常短的时间。我非常感谢阿里云做出了这样一款产品。时至今日，人与云计算的分工越来越明确了，相信在计算这个层面，特别是资源调度层面有了 Serverless 技术的加持，越来越多的企业可以不再关注资源，而是更加专注于如何为客户提供更好的服务。期待未来 wolai 能够与阿里云函数计算一道做更好的产品。
作者简介
马锐拉：wolai.com 创始人
