短视频|成本节省 50%，10 人团队使用函数计算开发 wolai 在线文档应用带货|家居

文章图片

我们的日常工作场景几乎离不开“云文档” 。目前，人们对于文档的需求再不仅仅是简单的记录，而扩展到办公协同、信息组织、知识分享等。在国内众多在线文档中， wolai 因为功能新、迭代快、流畅的异地协同体验、高效的信息组织方式以及“信息块”信息整合等特点，作为一个独特的存在进入了人们的视线。人们关注 wolai 独特的功能和舒适的用户的用户体验，更关注实现这些背后的技术架构。在一个晴朗下午，我们邀请了 http://wolai.com 的创始人马锐拉，跟我们聊聊 wolai 背后的 Serverless 架构。
我为什么选择 Serverless 架构？在做「 wolai 」这款产品之初，我们就希望把架构彻底放到 Serverless 上。因此在技术选型阶段，对国内外几款 Serverless 产品进行了细致的调研，我们发现阿里云函数计算（FC）无论在支持上和整体解决方案上，优势都非常突出，并且跟我们的需求非常匹配，因此，我们决定选择 Serverless 架构，全面使用阿里云函数计算（FC）。
作为一个办公协同应用， wolai 具备多人同时在线编辑文档功能。要实现这个功能，一个非常稳定的 Web 服务接口和一个具备伸缩能力、支持高并发写入、读取分离的分布式数据库是非常重要的。因此当我们发现 Serverless 产品能够与分布式数据库进行很好的搭配，就初步确认了 wolai 的主体架构。
接下来我们开始在阿里云上验证使用阿里云函数计算（FC）的可行性。通过验证发现阿里云函数计算（FC）不光能帮助我们解决上述问题，还可以帮助我们大幅度节省人力成本和云资源使用成本的投入。
以一家初创公司为例，聊聊函数计算接下来我想聊聊，为什么在创立公司之初，我会坚持选择 Serverless 架构。我曾在一家支付公司工作，所以我以一家比较典型的支付公司来举例说明。
不可避免的流量伸缩问题假设你创立了一家支付公司，它的背后差不多需要 200 多个系统支撑，如果这些系统大部分都基于 Java，这就意味着支付业务背后的机器是一台一台的集群，每一次发布研发都需要对这些集群进行分组，然后逐个上下线，这需要耗费巨大人力成本。
除了集群分组，研发们还需要关注缓存、日志系统等中间的各个系统是否有瓶颈。一旦发生问题，就需要在整个运维系统上花费巨大的精力去解决。随着公司的发展，你的这家公司的服务量级终于上升了，这时候你又会发现成本也随之大幅度上升了，比如需要部署新的机器，需要花费很多时间去做计算的伸缩工作（确切的说只是“伸” ，根本就没有办法去“缩” ，对不对？）所以流量伸缩问题会是你遇到的第一个问题，同时也是不可避免的问题。
流量的波峰波谷问题接下来，你还会遇到流量的波峰波谷问题。由于支付请求在晚上比较少，而在白天或大促、秒杀期间，支付请求的并发数可能会特别高。如果大批流量在同一时间涌进来，你就需要迅速拨计算资源过去，这需要做非常多的运维工作。
对一家刚创建不久的公司来说，你很难把大量的精力放在运维服务器上。而这时候你可以选择 Serverless，它能够帮助你解决上述这些问题。你可以把运维服务器的工作放心的“丢”给 Serverless ，而你真正需要关注的只有自己的业务逻辑。
我可以只关注代码和客户的需要过去我们做 Web 服务，开发的工作重点在于在 web 服务器上做各种优化，其实这些工作都是在解决一个问题：当量级上去之后，服务器性能能不能抗住？如果不能要怎样做优化？开发者们做 Nginx 性能调优、负载均衡、反向代理等繁杂的优化工作，耗费了大量的时间，而当我们使用了函数计算之后，相当于把一大部分调优web 服务器的工作去掉了，这极大的节省了人力成本，提高了效率。使用函数计算之后，整个服务从开发到上线过程中，研发可以把绝大部分精力都放在业务代码上，无需关心服务本身是怎么稳定运行的。