场景描述：
直播间的客户端把主播和连麦观众的音视频采集发送给函数计算做混流服务，函数计算把数据汇集后交给混流服务进行合成，并把合成画面视频流推送给CDN，终端观众实时拉取直播流，能实时看到混流合成画面。
视频直播应用场景中，有一种场景视频直播的多人连麦，主播可以同时和多个工作进行连麦，把多个观众或者好友画面接入，并把画面合成到一个场景中，供给更多观看直播的观众观看。这个场景中，有几个技术难度需要关注：
- 连麦的观众不固定，需要考虑适度的并发和弹性。
- 直播不可能24小时在线，有较为明显的业务访问高峰期和低谷期。
- 直播是事件或者公众点爆的场景，更新速度较快，版本迭代较快，需要快速完成对新热点的技术升级。
综合以上几个特点，可以通过Serverless这种架构的来完美解决以上痛点。
函数计算作为连麦观众和主播接入的实时音频和视频转发集群，当并发量过来时候，函数计算自动扩容多个执行环境来处理实时数据流，当业务高峰期过去后，会适度缩减资源使用，代码管理部署在云端，代码迭代可以随时进行修改和维护，无需再多管理一套软件运行环境。
视频直播场景常规做法：
- 购买负载均衡应付并发。
- 购买计算资源做数据处理。
- 业务低谷期需要想办法释放硬件资源来节省成本。
- 多版本要维护多套运行环境。
函数计算解法：
1、把负载分发程序写到函数里。
2、多版本迭代无需更换运行环境，仅仅替换代码版本即可。
3、业务访问按需付费，业务低谷期无费用。
整个架构图分成2部分内容：
- 一部分是Web应用，模拟一个社交内容更新和数据处理的流程，Web用户通过API网关把请求转发到函数计算进行处理，函数计算把处理后的内容更新到数据库中，并更新索引，另外一个函数计算把索引更新推送的搜索引擎供给外部客户进行检索，完成整个数据闭环处理。
- 另一部分是智能设备通过IoT网关把设备状态推送到函数计算处理，函数计算通过API接口把消息通过移动推送服务，推送给移动端进行状态确认和管理。在智能设备状态处理的场景中，同样也会碰到几个核心技术问题要解决，当海量设备把状态发送到IoT平台后，如何设计一套高效非轮询的技术框架来处理设备状态数据；如何把处理后的数据高效透传其他产品，例如写数据库或者推送给移动端。
IoT设备状态场景常规做法：
- 设置消息通道接收事件，并编写业务代码。
- 购买服务器资源做后端数据处理。
- 开通多个产品，并调用SDK代码来完成业务交互。
- 维护相关硬件软件环境。
函数计算解法：
- 定制IoT平台的事件通知，直接把业务代码写到函数计算中。
- 不需要维护运行环境，用完即可释放。
- 控制台配置，就可以把信息透传给相关产品。
通过两种方式的对比，能看出函数计算的解法更具备通用性和大量减少维护工作。
共享派单系统详解
客户通过派单平台选着某种商家提供的服务，可能是餐饮、商品、或者服务。派单平台通知最近的骑手到最近的商家拿到服务并派送到客户手里。一个简单的流程图如下：
流程详解：
步骤1、客户通知派单平台下单某商品
步骤2、派单平台通知最新骑手
步骤3、派单平台同时通知商家商品售卖出去
步骤4、骑手到指定的商家获取商品
步骤5、骑手配送到客户所在地
这个派单场景中，要解决几个棘手的技术：
整合多种资源，计算资源会涉及到，骑手位置信息、最优路径规划、车况情况、调度系统等
低延迟：派单系统对订单的响应要求很高，从接单到商家在到客户，整个闭环都需要在段时间内完成。
海量数据：涉及到三方面的数据，客户数据、商家数据、平台骑手数据、位置信息、商品信息等。
请求明显波峰波谷：派单系统在一天中的资源使用非常不均衡，波峰期，例如外卖，在中午和晚饭达到高峰，平时空闲。
通过技术选型转化成阿里云产品的解决方案后，函数计算结合其他产品比较完美的解决上述问题，解决方案图如下图所示：
流程详解：
客户APP把订单请求通过API网关透传给函数计算，函数计算把处理后的数据传输给表格存储，表格存储存放了骑行数据、商家信息、位置信息等，其中骑行日志会存放到日志服务里，便于后续做报表分析。骑行过程中骑手头像、随手拍街景会存放到OSS中，骑手位置可以通过函数计算去拉取第三方地图信息，例如高德地图等。这个方案中，函数计算可以完成动态扩容问题，API网关可以解决鉴权和安全访问问题，函数计算打通了多款产品，可以无缝使用其他资源和内容。所有处理后的数据可以存放到表格存储数据库中，所有日志都可以直接加载到日志服务为后续数据报表服务。
共享派单系统常规做法：
- 购买多台服务器来支持高峰期的访问，访问波谷期自行设置释放原则。
- 通过编程方式完成多个产品的交互。
- 为了保证负载均衡，需要购买相关的产品来支撑。
- 人工维护相关硬件软件环境。
函数计算解法：
- 定制IoT平台的事件通知，直接把业务代码写到函数计算中。
- 不需要维护运行环境，用完即可释放。
- 控制台配置，就可以把信息透传给相关产品。
两种解法都能达到目标，从资源利用率和可维护性来看，使用Serverless架构的方式会更优。
通过上面几个个场景的详解，我们大致可以得出这样的结论，通过事件触发场景、有业务访问高峰和低谷的场景、迭代次数较多、需要快速打通多款产品场景，通过函数计算能完美的解决成本、效率、联通等问题。
表3-1函数计算和传统自建服务器的优劣对比
|
函数计算
|
自建计算环境
|
|
维护性
|
内置打通API网关，OSS，Table Store、IoThub、Log Service、Message Service、Datahub等产品，只需要简单配置。
沙箱执行环境，无需配置。
自动伸缩和负载均衡。
触发条件简单，入口多。
|
多款产品链接需要自己编写代码来实现，有技术门槛。
自建物理环境，需要配置运行环境，消耗人力物力。
需要自行搭建伸缩机制和负载均衡，耗时较多。
|
|
可靠性
|
代码和配置存放在OSS中，自动多重冗余备份。
|
受限于硬件可靠性，易出问题，一旦出现运行环境或者数据损坏，容易出现不可逆转的数据丢失。
人工数据恢复困难、耗时、耗力。
|
|
成本
|
按执行付费，在业务请求波谷期费用低廉
上行流量免费
无需运维人员和托管费用
阿里云产品内部传输无费用
同比计算能力，成本节省1/3
|
业务请求的波峰需要资源扩容，波谷的时候资源浪费。
需要专人维护运行环境和硬件资源，人力成本较高。
产品之间联通如果走公网，需要额外支付流量费用。
|
|
安全
|
沙箱运行在阿里云企业级别安全环境里。
多用户运行是服务器级别隔离机制。
提供多种服务授权和子主账号。
|
需要另外购买清洗和黑洞设备
需要单独实现安全访问机制
|
函数计算虽然适用于很多场景，但也不是覆盖全部应用场景的万金油。例如某些业务在一天中没有明显的请求波峰波谷，请求相对平缓，那么使用函数计算成本不见得会节省多少。Serverless这种框架是新兴的技术，目前相应的支持开发工具较少，整体这个框架还在探索中。另外函数计算的执行环境是不记录状态的，有些耦合性较强的应用也不太适合用Serverless这种框架。受限于资源大小分配，一些大型的应用程序也不太容易能拆分能搬上来。
