*作者：* *黄备、洛浩*

深圳鱼传科技有限公司是专注以精准营销和互联网生态产品运营为核心的综合互联网营销推广服务商。通过整合全网优质媒体资源，并结合智能数据模型和 AI 标签算法，向企业提供包括流量矩阵搭建运营、媒介流量采买、投放模型设计、产品营销策划、数据监控分析、效果运营等多层次服务。作为函数计算的资深用户，鱼传科技的 CTO 和技术负责人跟我们聊了鱼传科技的 Serverless 旅程。

目前鱼传科技的业务主要基于支付宝小程序进行承载，小程序具有轻量、打开方便、内容可以快速更新等特点，为了适应市场的快速变化和多变的客户诉求，对敏捷开发提出了更高的要求。鱼传科技的业务特点，还具有访问量波动大、流量突发预测难等特点，尤其是活动期间访问突增对小程序后端服务的稳定和弹性也是一个很大的考验。

而阿里云函数计算是典型的 Serverless 计算平台，具备极强的弹性能力，可以做到百毫秒弹性扩缩，可以很好的支撑业务弹性扩展。同时对函数计算，用户上传代码即可运行，无需关注和维护服务器，也极大地提高了后端开发效率。这些特点使得函数计算成为很多企业支撑小程序/移动 APP 的优先选择，尤其是有突发流量或者流量波动较大的业务场景。

如下是基于鱼传科技的第一视角呈现的 Serverless 落地实践。

## 复杂交互小程序如何应对访问量激增？

2018 年底，我们开始尝试使用函数计算。当时，公司的核心业务是在支付宝上制作一些小程序。“多多有礼”小程序就是在那个时候上线的，“多多有礼”是一款主打互动领奖的小程序，当前已经积累了百万日活的规模，是一款非常受用户欢迎的产品。然而在 2018 年， **“多多有礼”最初上线时，我们遇到了已有业务系统难以承载突增流量的难题。**

那时我们的业务都跑在服务器上面，为了能抗住高并发流量，我们准备了大概三、四台高配服务器做负载均衡，然而在业务并发高峰期，服务崩掉的情况还是经常发生。因为这个小程序涉及到的业务逻辑，和应用后端交互比较多，有很多复杂流程，比如打卡、签到、庄园运营等，所以遇到突增流量，单纯增加服务器数量很难扛住。

**另外我们还遇到了资源利用率低的问题。** “多多有礼”在初期上线的时候，业务高峰期并发大概在 1000-2000，但业务低峰期可能也就几十，这是因为小程序设计的用户打卡、签到等动作，使得用户量非常容易在早上、晚上，或者某一个特定时间暴增。在这种情况下我们再用 ECS 的话，不仅需要按照峰值流量预留足够的 ECS 资源，维护起来也会变的非常复杂，资源利用率很难做上去，费用也会成倍的增加。

所以我们当时非常迫切地想把这个事情从我们系统里解耦，如果能简化我们的运维复杂度，还能引入弹性能力就好了。经过调研我们发现当时阿里云，只有函数计算 FC 这款产品具备相应的特点，所以我们就开始尝试把整个业务都迁到阿里云函数计算上来。经过这 3 年多的使用，我们把新的应用、可以迁移的旧应用、内部应用/外部应用等都陆续迁移上函数计算了。可以这么说，如果函数计算崩了，我们公司的业务基本也就瘫了。但是经过这 3 年来的使用，发现函数计算的稳定性还是超预期的，比我们维护使用服务器的时候，业务稳定性和性能都有大幅提升，现在峰值可以达到数万 QPS、数千函数并发同时稳定运行。而且我们和函数计算也建立了专门的技术支持群，有任何技术问题，都能很快得到响应，这也是为啥我们敢把公司所有的业务都基于函数计算来部署的原因。**使用函数计算，真正帮助我们解决了很多稳定性和性能问题。**

**![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d9b229a10204782b47b8c443c4e234e~tplv-k3u1fbpfcp-zoom-1.image "1.png")**

“多多有礼”小程序页面

### 最佳实践

再来分享下我们使用函数计算的一些最佳实践，希望也能帮助到其他用户使用函数计算。

#### 1. 开发流程

我们公司的主要技术栈是基于 PHP 语言，也会使用一些 Web 框架，像 Lavaral，针对 Web 框架，为了能在函数计算上运行起来，我们也对框架做了些适配，一个项目拆成一个或多个文件，对应多个函数，单个文件有的1万行代码，基础文件一百行左右。但是现在函数计算配合 Serverless Devs 工具支持了多语言 Web 框架的“0”改造迁移，我们也在尝试使用。目前我们每个开发会独立负责一个函数服务，服务下面每个函数会作为一个小的应用，部分项目会跨服务依赖一些功能函数，但是我们都会尽可能都独立开。函数计算也支持了层功能，后面会用层来部署公共函数、依赖，比如给用户发红包，代码只用写一份。另外对新招进来的开发来讲，函数计算上手门槛还是很低的，不用管理服务器搭环境，可以直接在线编辑代码、部署、测试。

#### 2. 流水线和灰度发布

我们本地一直采用的 SVN 存储代码，SVN 提交代码支持触发 Action，我们封装了函数计算的 API 接口，可以通过关键字触发函数和服务的发布。为了避免发布影响线上服务，我们还使用了函数计算的版本和别名的功能。正常线上业务会发布成新的版本，同时把 HTTP 流量入口绑定的 release 别名指向新的版本，这样就完成了发布过程，如果最新的代码出现问题，可以更改别名的指向，就能达到一键回滚到上个版本。同时我们也会创建一个测试别名，会先完成版本的测试后，才会把承载现网流量的 release 别名指向到新版本。这样通过别名的能力就区分出了线上环境和测试环境，非常方便。

#### 3. 运维管理

对函数计算来讲，基本是不需要关心资源维护的，像我们最依赖的弹性能力。但是对于业务运维来讲，监控日志就成了非常关键的手段。函数计算集成了 SLS，每次请求都会生成一条日志，可以比较方便的过滤出错误日志，对线上问题排查还是比较方便的。另外函数计算也提供了比较全的监控视图，我们最常用的就是请求量、错误次数、并发、执行耗时等指标，针对错误次数也加了告警，这样开发就可以直接兼业务运维，效率成倍增加。

### 效果对比

对比之前使用服务器，函数计算确实给我们带来了很大的便利性，我们也是最早吃螃蟹的人，基本伴随着函数计算一路成长，我们也非常高兴的看到，函数计算的功能越来越丰富，体验也越来越好。总结下来：

**1. 稳定性增强**

**开发不需要去关心后端服务的搭建运维，只需要编写函数就能够为小程序提供稳定可靠并且弹性伸缩的服务。** 并且随着小程序访问量增加，函数计算能够支持更大的并发配额，即使应对大促活动流量高峰也能够如丝般顺滑。对于稳定性的提升，这个是对我们最大的帮助。

**2. 开发上手快，不用维护服务器**

使用函数计算“上手快，不用维护服务器”也是很吸引我们的一个点。很多人对于 “Serverless”技术有一些误解，认为这个火热的技术可能会难以学习、理解，其实不然。**在实际使用过程中，我们曾经尝试让一些开发新人在生产过程中直接使用函数计算，在实操的过程中，这些开发上手非常快，他们只需要关心自己的代码就可以了，也非常乐于使用。**

**3. 价格低服务好，想买技术支持**

之前我们对于函数计算的使用费用没有做过细致的统计，刚发现支撑一个日活超过 50 万人的小程序，使用函数计算费用大约在 200 元/日左右，对我们的业务来讲，这个费用还是很便宜的。我们日常使用也会遇到一些问题，函数计算团队能及时、耐心的给予技术支持，**我曾与团队的同学开玩笑说，特别想在函数计算上多花点钱，想买技术支持。**

## 云计算时代真正的弹性计算

Serverless 技术最大的优势就是免运维，同时提供弹性能力和按需付费。我们选择使用 Serverless 就是觉得它是真正的弹性计算，是未来的趋势。如果我使用比如像弹性 ECS  这样的产品，如果我的业务发展需要上量，就需要人工去“起”机器，或者执行一些弹性策略。但 Serverless 却能够让我不用考虑后端的所有的运维工作，实现自动的弹性伸缩，所以我们认为 Serverless 是云计算时代真正的弹性计算。

最后，我们也想对函数计算提一些建议：

1. 期望函数计算的调用入口能够支持访问 IP 固定，因为一些政府监管的要求，需要加 IP 黑白名单。

2. 函数的版本发布，能够支持针对单个函数精准发布，更加精准的实现灰度。

*作者介绍：鱼传科技 CTO 黄备、阿里云架构师洛浩*

ITPub博客

鱼传科技：函数计算，只要用上就会觉得香

最新文章