介绍：人们更关注我来独特的功能和舒适的用户体验，更关注这些背后的技术架构实施。在一个阳光明媚的午后，我们请到了窝来网创始人马瑞拉，和我们聊聊窝来背后的Serverless架构。作者：马瑞拉|我来网创始人我们日常的工作场景几乎离不开“云文档”。目前人们对文档的需求不仅仅是简单的记录，还延伸到办公协作、信息整理、知识共享等方面。在国内众多的在线文档中，我来以其新的功能、快捷的特点，作为一个独特的存在进入了人们的视线。迭代、流畅的远程协同体验、高效的信息组织、“信息块”信息集成。人们更加关注我来独特的功能和舒适的用户体验，更加关注这些实现背后的技术架构。在一个阳光明媚的午后，我们请到了窝来网创始人马瑞拉，和我们聊聊窝来背后的Serverless架构。我为什么选择无服务器架构？在做“我来”这个产品之初，我们希望把架构完全放在Serverless上。因此，在技术选型阶段，我们对国内外几款Serverless产品进行了详细的调研。我们发现阿里云函数计算（FC）在支持和整体解决方案方面优势突出，非常适合我们的需求。因此，我们决定选择Serverless架构，充分利用阿里云函数计算（FC）。作为一款办公协同应用，我来拥有多人同时在线编辑文档的功能。要实现这个功能，一个非常稳定的web服务接口和一个具有可扩展性、支持高并发写、读分离的分布式数据库是非常重要的。所以，当我们发现Serverless产品可以很好的和分布式数据库匹配的时候，我们就初步确定了wolai的主要架构。接下来，我们开始验证在阿里云上使用阿里云函数计算（FC）的可行性。通过验证发现，阿里云函数计算（FC）不仅可以帮助我们解决上述问题，还可以帮助我们大大节省人力成本和云资源使用成本。以一家创业公司为例，我们来谈谈函数计算。接下来，我想谈谈为什么我在创立公司时坚持选择无服务器架构。我之前在支付公司工作过，所以我就拿一个比较典型的支付公司来举例。无法回避的流量扩容问题假设你创办了一家支付公司，需要200多个系统来支撑。如果这些系统大部分都是基于Java的，那就意味着支付业务背后的机器是一个接一个地集群，每次发布研发都需要将这些集群进行分组，然后一个一个下线，需要巨大的人力成本。除了集群分组，开发者还需要关注缓存、日志系统等中间系统是否存在瓶颈。一旦出现问题，需要在整个运维系统上花费大量的精力去解决。随着公司的发展，贵司的服务水平终于提高了。这时候你会发现成本也明显增加了。比如你要部署新机器，做计算伸缩需要花很多时间。工作（准确的说就是“拉伸”而已，没办法“收缩”，对吧？）所以流量伸缩的问题会是你遇到的第一个问题，也是不可避免的问题。流量的峰谷问题接下来，你还会遇到流量的峰谷问题。由于晚上的支付请求较少，白天或促销、闪购期间，并发支付请求的数量可能会特别高。如果同时有大量流量流入，需要快速分配计算资源，需要大量的运维工作。对于一个新成立的公司来说，你很难投入大量的精力去运维服务器。这时候你可以选择Serverless，它可以帮你解决上面的问题。你可以放心地将运维服务器的工作“丢”给Serverless，真正需要关注的只是自己的业务逻辑。我只能专注于代码和客户的需求。以前我们在做web服务的时候，开发工作的重点都是在web服务器上做各种优化。其实这些任务都是为了解决一个问题：当量级提升后，服务器性能能否承受住？如果不是怎么优化呢？开发者花费大量时间做Nginx性能调优、负载均衡、反向代理等复杂的优化工作。当我们使用函数计算时，相当于去掉了很大一部分调优Web服务器的工作，大大节省了人工成本，提高了效率。使用函数计算后，在服务从开发到上线的整个过程中，研发可以将大部分精力放在业务代码上，而无需关心服务本身如何稳定运行。自2020年6月15日业务上线以来，我们从未遇到过服务宕机或离线维护的问题，这些问题都是使用函数计算之前的常见问题。以往，一旦遇到这样的问题，我们需要花很长时间去寻找问题的原因。我们可能需要升级web服务，加几台机器，甚至做反向代理和负载均衡……即使这些都完成了，我们上线服务还是会有维护期的，而且它我们仍然很难保持服务在线。因此，函数计算对我来说最重要的特性之一就是持续服务的能力。通过使用函数计算，我的业务可以稳定持续的增量发布。我在之前的公司工作时，每两周发布一个版本。每个版本都有一个非常详细的版本列表。发布涉及许多条件和依赖项。需要运维的脚本非常复杂。可以说，只要一个失误，整个发行版就可以变成小毛病，甚至大毛病。当我们把整个架构放到Serverless上，把所有的功能拆分开来，出事故的概率就大大降低了。即使出现问题，我也可以通过快速回滚来修复它。现在我们的研发习惯是每天至少发布一个版本，所有解决的问题当天都会发布。与传统软件公司相比，部署在Serverless架构上，我们的迭代速度会快很多。快照保存系统解决了协同编辑算法问题。对于我来这样的协同办公产品，协同编辑是产品的重中之重。这个功能对算法要求很高。我们也通过使用函数计算很好地解决了这个问题。我来云笔记功能有一个信息块（Block）的概念，就是将用户可访问的最小信息单元从“文件”缩减为“信息块”。“信息块”可以容纳文本段落、表格、列表，并从外部嵌入图片、视频等信息，并可以方便地实时编辑、移动、渲染，形成一个页面。所以接下来我会用“块”来指代信息块。上面红色背景都是独立的，用户每次按键操作后，我们的前端都会有一个类似于快照的存储机制。如果用户按键的速度非常快，那么他的多次按键操作可能会在某个时间片内形成一个事务，返回给这个函数进行计算。然后我们将记录这些操作。当第二个用户同时按下该键时，如果他也按下同一个方块，他也会触发同样的操作。我们会在函数user中计算这些操作对这个块的实际影响的顺序，最后应该是什么样子，然后函数计算也会发送一个队列请求，当任何一个块或者它所属的页面有这个变化时event之后会丢到这个redis中。一旦一个块或一个页面在5分钟内更新，我们将调用另一个函数来生成整个页面和整个块的快照。所以我们结合函数和队列调用来制作一个自动化系统。一旦用户编辑页面或块，我们将在固定时间段内生成快照。我们现在每分钟为单个块保存一次快照（相当于一段文字或图片等最小单位）。相当于在1分钟之内，只要用户有更新，我们就把它做成一个整体的快照，然后放到OSS上。如果每个区块都频繁更新，OSS上就会有很多这个区块的一分钟快照。目前，我们的OSS上有近10亿个文件。如果是页面级编辑，wolai保存快照需要5分钟，频率会低一些。通过函数计算和队列的结合，我们打造了一个快照保存系统。我来的Serverless架构图使用Serverless解决的问题通过研究我来的用户行为，我们可以发现，我们的用户一般每天早上上班的时候都会打开我来文档，然后他/她会持续使用一整天，直到下班后关闭。我们的用户不需要像小程序的用户那样快速打开应用然后使用。相反，他们对应用程序的初始加载速度没有特别高的要求，所以我们的重点不在服务端渲染问题上。通过研究用户习惯，我们更加关注用户在打开应用后能否快速响应每一步操作。涉及到两点：1、当用户向我的服务器发送数据时，服务器是否能够快速、稳定地接收数据？2、并发量大的时候，响应速度会变慢吗？功能解耦，让小团队发挥能量通过使用功能计算，我来的前端工程师可以负责从前到后的一整套开发流程，我们的研发迭代速度非常快。为了实现快速迭代和节省人力，我们将应用的每个小功能点拆分成一个个的小块，在函数计算上部署了很多服务。同时，每个服务下会有多个功能。实现功能解耦的方式。这样做的好处是，当我们需要发布的时候，如果我们只是对一个功能做一些优化或者bug修复，那么我们只需要发布这个功能，根本不需要做一个整体的发布。因此，我们可以每天快速积累release，而且大部分功能完全解耦，互不影响。我们尽量把所有功能完全分离，变成独立的业务逻辑。这样可以保证研发迭代的速度。目前，我们团队有10名研发工程师。其中八位是前端工程师，大大提高了团队的效率。小型企业将通过使用函数计算节省50%的成本。在选择模型时，我们对使用函数计算的成本做了一个粗略的估算。我们的计算结果是，使用函数计算比使用传统框架可以节省一半以上的计算成本，人力投入可以节省一半甚至更多。我们可以算一笔账。如果我们选择传统架构，以目前系统的复杂性，我们的应用至少需要两个运维工程师。现在前端工程师可以对系统进行自始至终的开发和维护。按照平均每月3万元的人工成本计算，包括场地和硬件成本，对于小公司来说，一年至少可以节省70万到80万元的运维成本，计算资源的成本也会增加同时，也就是说，如果说用传统框架一年要100万，用函数计算至少可以变成50万。自2020年6月上线以来，我来使用函数计算的过程非常顺利，从选型到完成项目上线用时非常短。非常感谢阿里云做出这样的产品。如今，人与云计算之间的分工越来越明确。相信有了Serverless技术在计算层面，尤其是在资源调度层面的支持，可以让越来越多的企业不再关注资源，而是更加关注如何为客户提供更好的服务。展望未来，窝来可以和阿里云函数计算一起做出更好的产品。原文链接本文为阿里云原创内容，未经许可不得转载。
