作者： 马锐拉
咱们的日常作业场景几乎离不开“云文档”。现在，人们关于文档的需求再不仅仅是简略的记载，而扩展到作业协同、信息安排、知识分享等。在国内许多在线文档中，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 创始人
