作者 | 夙言
今年阿里云函数计算服务 FC 开始进入阿里集团内部支撑业务，并且和我们的函数研发平台完成了对接，今年大促 Serverless 云研发平台 中多BU 租户进行了函数应用落地，包含淘系、飞猪、高德等业务，并且在部分场景下也通过弹性模式抗住了大规模的流量洪峰。应该有很多同学比较好奇在这背后都发生了什么，今天我们来通过一次函数业务需求初探阿里集团 Severless 体系。
业务需求
双十二有这么一个典型的业务需求，天猫V榜 双十二需要上一个猜你喜欢模块，服务用函数进行开发。
业务需求：展示给用户个性化的商品 feeds 流。
稳定性要求：无运维的承接双促当天的流量洪峰。
安全运维要求：函数上线前需要预发测试、需要有灰度流程、需要有完整的函数权限管控、上线后函数可观测。
接下来我们分析一下业务需求，个性化商品数据我们可以通过集团内部个性化服务获取，商品信息我们可以调用内部补全服务进行补全，招商商品字段可以在提前跑好数据的 Redis 中拉取。ok 感觉需求很简单。但接下来我们进一步思考就会发现这其中还是有不少问题的。
实现需求遇到的问题
第一个问题：我们的函数跑在弹外阿里云 FC 上，需要调用弹内个性化服务拉取个性化数据和调用内部补全服务进行通用补全。众所周知集团网络弹内弹外网络是隔离的，函数运行在弹外云机房内的是访问不到弹内服务的，那么流量数如何在云上云下流转的呢？
第二个问题：函数体系数如何在无运维的情况下顺利承接双促当天的流量洪峰，我们需要做些什么？
第三个问题：函数如何满足上述提到的安全运维要求呢？
问题解答
第一个问题：数据互通
要解释这个问题就不得不介绍一下集团的云部署模式，目前集团 IDC 跟 阿里云 通过 混合云专线方案 组成了上述混合云的部署模式，实现弹内弹外的互通，内部业务可以使用公有云上的弹性资源服务。为了我们更好的介绍混合云专线方案 ，在这之前我们先介绍几个概念。
混合云
混合云：简单来说是结合公有云和私有云的优势，通过专线或 VPN网关 等方式连接公有云和企业私有云，允许在不同的云环境之间共享数据和应用程序。拥有以下几个特点。
- 高控制力：企业可以根据业务需求在不通云环境中分配工作负载，可以把企业核心服务和数据，比如交易、运营服务运行在私有云和存储本地 IDC 当中，其他低安全性要求的服务运行在公有云上。
- 高灵活性：面对私有云中比较棘手的超出预期的大流量场景时，可以将部分工作自动传输到公有云，按需付费的使用公有云近乎无限的资源。
- 高可靠性：云服务商也会承诺一系列 SLA 来保障服务的稳定性
- 无厂商锁定问题：一个私有云可以连接多个公有云服务变成多云混合部署，比如企业 A 通过专线将本地 IDC 同时连接了阿里云和腾讯云，服务可灵活的在两个云厂商之间移动，通过这种方式解决厂商锁定问题。
VPC
- 专有网络 VPC：（Virtual Private Cloud）自定义私有网络，不同的专有网络之前二层逻辑隔离，由路由器、交换机、私有网段组。用户可以配置 IP 地址范围、配置路由表和网关。可以在专有网络内使用云上产品（ECS、RDS、LB）
混合云专线
了解了混合云、VPC 之后我们再来介绍一下 混合云专线方案 是什么：云上各 Region（地域） 资源通过一个或多个集团 VPC 进行私有网络隔离。集团使用的云上资源都必须部署在集团 VPC 内。但是集团 IDC 和集团 VPC 无法直接通信，云上的资源都访问不到，这时就需要通过云专线（租用一条运营商的专线，可以绕过公网，快速安全连接阿里云与本地数据中心）来链接云上集团 VPC 和云下集团 IDC ，达到流量互通。
弄清楚集团 VPC 和集团 IDC 是如何流量互通之后，我们再来延展一下，VPC 是 Region 级别隔离的，也就是意味着中心的 VPC 是没法直接访问上海的 VPC 那么如果我们自身部署了双单元，但是我们依赖的一个下游服务只部署了中心单元，那么我们部署在上海 VPC 的服务如何访问部署在中心 VPC 的下游服务呢，这时候就要引出另一个概念了云骨干网（构建多地域全球网络，并和混合云连成一体，打造具有企业级规模和通信能力的智能云上骨干网络）。各 Region 集团 VPC 之间的流量，先要通过云专线回到云下集团数据中心，再通过骨干网实现跨 Region 互通。
小结
通过 混合云专线方案，让我们跑在弹外云机房上的 天猫V榜 函数可以请求到集团内部的 TPP 服务 ，我们看下上述的业务流程图具体在网络中是如何流转的。
第二个问题：如何无运维的承接双促当天的流量洪峰
本次大促 天猫V榜 流量来源包括两部分：主互动、榜单会场，其中主互动流量较大且有明显峰值，流量的波峰和波谷 QPS 相差10倍。那面对这种情况我们应该如何应对洪峰流量，已经我们如何对自身和下游服务进行保护？以往传统应用模式有两种处理方式，第一种是按照峰顶流量评估机器数，提前扩好，缺点是在日常状态下机器利用率力较低比较废机器。第二种方式是到了流量高峰的时候手动扩容机器，需要人工操作，有一定的风险。并且传统应用启动一般不是那么快，所以可能会在一开始流量上涨的时候出现大量失败。接下来让我们看下在 Serverless 体系下我们是如何解决这个问题。
FC 的容器类型
首先我们先来了解一下阿里云函数计算 FC 的容器类型，大致分为两种，预留容器和弹性容器。
- 预留容器：预留容器比较好理解可以类比于传统应用，启动一定数量的机器一直放在那里处理请求，函数预留容器与之类似，就是启动多个一定规则的容器（单容器规格一般是 1C2G ）不管有没有流量一直放在那里处理请求，不同的是函数容器每 5 小时会强制轮转一次，所以做不到固定 IP 。
- 弹性容器：预留容器可以应对日常流量需求，但是假设业务忽然导了一波流量进来，目前的容器数量已经无法处理这批额外的请求，那服务岂不是会出现大量的请求失败呢，这时候就要使用我们的弹性容器了，弹性容器顾名思义，会根据一定规则弹起或缩容，目前 FC 支持的规则就是并发，当请求某一时间内出现增加，势必会导致函数各容器的并发增加（tips: 并发 = qps rt，例如 qps = 100，rt = 500ms，并发 = 1000.5 ），FC 检测到并发达到了用户设置的单容器最大并发值，就会弹起弹性容器来进行分流，一直到单容器并发降低到预设最大并发值，才会停止新的弹性容器弹起。当这波流量高峰过去并发下降到预设最大并发值后，这部分弹性容器就会自动缩容。
淘系大促业务使用的就是上述预留容器加弹性容器组合部署模式，日常流量通过预留容器承接，突发流量通过弹性容器承接。除此以外我们进行了限流，防止自身流量过高导致下游服务压力过大。接下来我们介绍一下我们的限流策略。
函数限流
起初我们认为针对函数级别限流配置限制住函数的最大 QPS 就可以了，比如淘系大促 极有家 业务的函数，整体流量属于中等，于是我们直接让 FC 的同学针对函数在 sentinel （流量控制组件）上配置了对应流量的限流，但是经过单链路压测，我们发现流量还不到指定限流值就会出现一些不正常的限流，通过和 FC 同学一起问题定位，发现了问题所在，因为承接 HSF Trigger 的 HSF Gateway 是一个集群，sentinel 上的限流是根据单机配置的，所以具体配置到某一台 HSF Trigger 机器上的限流其实只有几 QPS，这时只要流量负载出现一点倾斜，那么单机很容器就会触发限流，所以这里的限流是不准确的。既然函数级别限流不准确，那么我们就瞄上了单机限流，我们根据日常整体流量配置好单机并发限流，通过研发平台配套的单容器限流组件进行单机限流。并且在函数级别（HSF Gateway 单机限流）的配置进行一定系数的放大，使之不会轻易触发限流，并且多级限流也一定程度上减少了因为某一级限流失效对业务的影响。通过这种组合拳的方式实现了我们双促业务限流保障。
小结
天猫V榜单 函数大促期间通过在研发平台上进行了如下容器和限流配置，日常流量通过预留容器承接，突发流量通过弹性容器承接。并通过函数和单容器级别的限流防止自身流量过高导致自身和下游服务压力过大出现问题。让业务函数在无运维的情况下顺利承接双促当天的流量洪峰。
第三个问题：权限管控、灰度等安全保障
说到第三个问题，就不得不提起这次双促支撑淘系、飞猪、高德等多个BU函数业务研发、发布、运维的 Serverless 云研发平台 了 ，下面我们来介绍一下它的几个特点看看它是如何解答第三个问题的。
面向业务应用
不同于传统函数计算平台，开发维护单个函数，研发平台提供给开发者面向业务应用开发模式，每个应用权限相互隔离，一个业务应用中的所有函数维护在一个 git repo 中，达到同一业务代码统一开发维护和最大程度的业务逻辑代码复用。用户开发时就像开发传统应用一样，平台会在发布的时候根据 fyml 中的信息，自动拆分构建成一个一个独立的函数zip包进行独立灰度部署。
面向解决方案
平台对解决方案的定义：解决某一横向或纵向领域的，贯穿创建、研发、交付、运维阶段的一系列能力的集合。
到目前为止，平台提供了3种通用解决方案，分别是面向接口服务开发的纯函数解决方案、面向中后台开发的 ICE 全栈解决方案、面向C端 RAX 全栈 SSR 解决方案，以及近20种各租户定制的各自业务领域的租户定制解决方案。
例如平台提供的面向中后台开发的 ICE 全栈解决方案，本地提供前后端代码同一 git repo 开发的开发体验并通过 hooks 方式让用户便捷的请求函数接口，发布构建时自动拆分出前端 assets 资源和函数服务部署 zip 包，并且通过定制发布流程做到 assets 和函数有序部署。部署时分配应用泛域名，自动绑定函数，省去用户域名申请和统一接入复杂的流程，做到1分钟创建项目5分钟发布线上，发布即可访问。发布后提供新旧版本灰度机制，并且可以在灰度界面实时看到新旧版本的 QPS、RT、错误率等指标。
平台梳理的用户平台侧的使用路径，将平台创建、研发、交付、运维阶段具体功能模块化。并且提供解决方案定制能力，通过解决方案元信息将解决方案中的各部分能力配置化，以供其他租户同学可以方便的在平台上定制自己租户所需要的函数解决方案，并且沉淀可复用的通用解决方案供所有同学选择使用。有兴趣的话可以联系本人了解一下~
灰度流程
我们通过函数别名机制（Alias）实现新老版本的灰度能力，目前弹内每个函数研发平台都默认按照统一的规则创建了一个访问别名，成为函数所有 Trigger 的默认绑定别名，所有流量都指定这个别名。并且别名可以配置各版本流量配比，我们的灰度就是以这种机制为基础实现的。
{
"metadata": {
"name": "fc-interaction-index2__stable", // 平台生成的默认 Alias Name
"description": ""
},
"apiVersion": "core/v1",
"kind": "FuncAliasMeta",
"spec": {
"routing": {
"2": 50
},
"functionVersion": "1",
"functionName": "fc-interaction-index2",
"functionGroupName": "fc-rank-v-ald"
},
"status": {
"phase": "active"
}
}除了别名机制我们还要了解 FC 的灰度部署方式，函数灰度采用的是滚动部署方式，相比较于蓝绿发布这种方式更加省机器，但是也会有一些其他问题，没有办法保证灰度比例的实时性，因为新版本是逐步滚动部署出来的，灰度比例调整后，需要等待新版本滚动部署出来。（例如版本2从开始灰度到转正会经历下图过程）
自动分配域名
对于在平台上使用 HTTP Trigger 的函数部署后，会发现平台已经帮你创建出了一个域名，你不需要在自己去申请域名，慢慢的等生效了。接下来介绍一下研发平台是如何做到上述便捷申请的呢。
其实研发平台并没有新增域名，而是平台统一申请了 日常、预发、线上的泛域名。用户在发布构建过程中，会生成应用下函数的router信息（即应用中每个函数对应的 path 、method 等信息），并且研发平台会在部署的时候根据函数应用名分配给函数应用一个唯一的三级域名。
小结
研发平台提供了完整的函数权限管控，灰度流程等能力支持了 天猫V榜 等业务的开发、部署、灰度、容器限流配置相关工作，也通过 Alinode 的监控报警功能提供函数运维能力。由于篇幅限制更多平台能力我们下篇再述。
总结
Serverless 在集团前端范围还是属于新生事物，肯定有一些同学想尝试但是在流量稍大一点的业务落地的时候有一些顾虑。本文通过一次简单的业务需求，从网络、开发、灰度、容器、限流等几方面介绍了这个体系。想让大家能进一步了解这个体系，可以更便捷、安全的使用这个体系。
电子书免费下载
《2021前端热门技术解读》
阿里巴巴前端委员会重磅推荐！阿里巴巴前端技术专家为你解读前端技术新趋势以及2021你需要关注的技术热点，覆盖前端安全生产、跨端技术、Node.js(Serverless)以及多样化的前端技术四大方向，是2021不容错过的前端学习手册。
关注 Alibaba F2E 公众号
回复 电子书 马上下载
