共计 5097 个字符，预计需要花费 13 分钟才能阅读完成。
作者 | 张曦
一、openfaas 产品背景
在云服务架构倒退之初，这个方向上的思路是使开发者不须要关怀搭建和治理后端应用程序。这里并没有提及无服务器这个概念，而是指后端基础设施由第三方来托管，须要的基础架构组建均以服务的模式提供，比方数据库、音讯队列和认证服务等。
但亚马逊在 2014 年公布 AWS Lambda 时，为在云中运行的应用程序带来了一个新的零碎架构思路，即不须要在服务器上部署期待 HTTP 申请或 API 调用的过程。Lambda 提供了一个事件触发的机制及框架，当收到用户申请时触发一个事件，在一个 AWS server 上执行用户注册的性能（通常只是一个函数，业界个别称这种类型的服务为 FaaS）。
以后，提供 FaaS 服务的云服务厂商除 AWS 外，还有 Google Cloud（alpha）、Microsoft Azuze、IBM OpenWhisk 等。国内的云服务提供商如阿里云 FC、百度云 CFC、腾讯云 SCF。比拟受欢迎的开源架构有 OpenFaaS、Knative、OpenWhisk 等。
二、我的项目业务背景
阿拉丁是百度搜寻平台的产品，个别位于百度搜寻后果页的首位，是百度搜寻满足用户搜寻需要闭环的卡片式产品。离线工作提供高质量的结构化数据，在线 server 优化搜寻出卡策略，从而将高品质的搜寻后果出现给用户，最大水平的满足用户的搜寻体验以及需要。在线 server 部署在百度搜寻业务线的机器上，由百度搜寻业务线对立治理分配资源和保障业务稳定性。离线工作需业务方自行治理。
离线数据源的产出分为两种计划，定时读取数据库进行版本 diff 后，拼接结构化数据发送至搜寻业务线的音讯队列节点，或者 pm 提交物料数据触发建库工作生成全量静态数据，期待搜寻 spider 定时抓取建库，同时，离线计划也提供在线入口用于实时干涉数据、物料治理等性能。原计划是将所有脚本部署在业务方物理机上，定时工作由百度外部 noah 平台托管，反对配置运行工夫距离、运行指令，而后定时触发指令运行。对于手动触发类工作，在同一台物理机上部署了 http server，通过接管 http 申请，而后到脚本目录下执行 cmd 指令实现，这种形式造成了机器资源的节约。原上线计划还存在另一个问题，通过将公布包拷贝到物理机部署的形式，较为繁琐，而且没有上线记录，当呈现问题不利于尽快回滚止损。
三、思路与指标
从业务上来看，须要有两个性能点，定时运行脚本，还能反对传入文件流并触发脚本运行。为了节俭机器估算老本，应用百度智能云 bcc 虚机，为了保障脚本运行的稳定性，防止机器故障导致脚本全副无奈运行的状况产生，容器化部署脚本，基于 faas 的思路，把脚本工作放入函数中封装为一个云函数，反对定时工作、http 申请触发脚本运行。
思考到百度智能云 bcc 虚机上能够部署 cce Kubernetes 集群，调研基于 Kubernetes 的 Faas 开源我的项目用于二次开发。目前支流 Faas 开源架构有 OpenFaaS，Knative，OpenWhisk 等，这三个框架的比照如下：
比照后发现 Knative 更适宜定位于创立、部署和治理无服务器工作负载的平台，须要独立治理容器基础设施，从配置和保护的角度来看，比较复杂且不是面对最终用户，所以临时先不思考。OpenFaaS 和 OpenWhisk 比照，OpenWhisk 利用的底层组件多于 OpenFaas，从运维和部署 OpenWhisk 来看减少了肯定的复杂性，且 OpenWhisk 基于 scale 实现，如果须要二次开发，需从新动手一门新语言。而 openfaas 次要利用了 promethus、alertmanager 用于动静扩缩容，技术栈为与咱们日常开发语言统一，所以最终计划抉择了 openfaas。
而且 openfaas 还反对 event connectors 的调用形式，调用形式如下图所示，和 AWS Lambda 的性能相似，不便与其余生态系统集成。目前官网已反对了 Cron connector、MQTT connector、NATS connector 等连接器，咱们定时工作就依赖于 Cron connector 实现。在应用上先在集群中部署对应的 connector，而后在打包云函数用的 yaml 中 annotations 属性上，加上 connector 指定要加的内容即可依据工夫触发对应的云函数。
四、整体架构
4.1 架构设计
在整体的架构上，工作由事件（http 申请、定时器、faas 客户端操作）触发，openfaas 平台内会依据流量的特色路由到具体任务实例，触发工作执行，工作执行原理是 of-watchdog 将申请参数封装为 stdin 去执行 cmd 指令触发工作运行，期待工作执行实现从 stdout 中取到数据返回后果。
整体架构次要由以下几个外围局部组成：
网关 ：外围能力是负责对接内部触发源，将流量路由到具体任务实例下来执行；网关还负责统计各个工作的流量信息，为弹性伸缩模块提供数据撑持，同时也能够依据配置的工作并发度进行限流解决；网关也会同步工作运行状态、运行历史等信息，在工作执行失败后，告诉到工作负责人。
弹性伸缩 ：外围能力是负责工作实例的弹性伸缩，依据工作运行的流量数据、资源阈值配置计算函数指标实例个数，协调资源，而后借助 Kubernetes 的资源控制能力，调整函数实例的个数。
数据采集 ：采集网关对外裸露的流量数据，以及工作实例的资源使用量，作为弹性伸缩的判断根据。
日志采集 ：采集工作实例中的日志并落盘，不便业务方排查工作运行中呈现的问题。
控制器 ：外围能力是负责 Kubernetes CRD（Custom Resource Definition）的管制逻辑实现。
工作实例 ：当网关流量路由过去，会在工作实例内执行相应的脚本代码逻辑。
上线平台 ：面向用户应用的平台，负责函数的构建、版本、公布以及一些函数元信息的治理，同时反对查看函数运行时日志和执行历史。
4.2 流程设计
脚本整体生命周期如图中所示，有以下四个阶段：公布版本、构建、部署、伸缩。
公布版本 ：公布待上线版本，指定待打包脚本代码目录。
构建 ：将代码还有配置的定时工作等相干信息，一起打包生成镜像，用于后续的部署工作。
部署 ：将镜像部署到 Kubernetes 集群中。
伸缩 ：依据集群中工作实例的流量以及负载等信息，来进行实例的弹性扩缩容。
五、机器资源利用率晋升
晋升机器资源利用率，通过动静的为工作实例分配资源去实现。当离线工作处于不工作的状态下，能够把对应的实例数缩减为 0 调配给其余有须要的实例，对流量超过并发度配置或者资源应用超过阈值限度的工作实例进行扩实例操作，应用尽可能少的机器去承载更多的脚本离线服务。
在离线工作上线前，会对工作进行注册，抉择工作分类，工作可分为同步触发（需期待返回后果）、定时触发、异步调用（不期待脚本后果间接返回）这三种类型。
5.1 同步触发型工作
同步触发型工作次要是用于实时干涉线上数据，或操作物料数据入库，它的特点需期待返回后果确保操作胜利，且可能会有间断屡次操作。在下面三种类型工作中，这种类型的工作优先级是最高的，不会将其缩减到 0 实例。
同步工作弹性伸缩流程如上图所示，在工作监控过程中，通过拉取网关数据获取流量工作状况，pod 资源则是 promethus 配置 cadvisor 数据源获取，如果发现网关收到大量 429 状态码（流量超过并发度配置），或者发现资源应用超过报警阈值（阈值设置为上线平台配置的资源最大值的 80%），会对这些工作实例进行扩容。在扩容过程中如果发现机器资源不够，会依照定时工作、异步调用工作的先后顺序去找未运行的工作缩减实例数，在缩减定时工作时会依据最近一次工作执行工夫，由远及近的将工作实例缩减至 0 节约资源。反之，对同步触发类型的工作资源使用率很低的状况，依据并发度配置去适当的缩减资源。
5.2 定时工作
定时工作次要利用于全量建库场景，在指定的工夫开始运行，属于可预期的工作类型，极其状况下工作实例只须要在指定工夫存在即可。
定时工作的触发基于 cron-connector，然而在规定工夫保障对应的工作实例存在则由后台任务负责，定时运行查看将来的一段时间内对应工作的实例是否存在，如果不存在的话执行部署操作，同时注册回考察看工作实例部署状态，因为机器资源有余等起因导致实例数没有达到预期数，触发报警告诉到零碎运维人员。
5.3 异步调用工作
异步工作次要利用于运行工夫较长、不须要及时获取返回后果的状况，这类工作对失效工夫不敏感，齐全能够提早一分钟用于部署实例再触发工作执行，但因为异步工作由人工触发，不可预测触发工夫，所以在弹性伸缩须要缩容时还是会优先思考定时工作。
异步调用工作，如果实例被缩减到 0 后，触发工作执行，网关内的激活器模块会先将申请信息存储，而后通过裸露 metrics 信息，触发流量大于总并发度（实例数 * 配置并发度）的报警，实现重新部署。网关进行轮训期待实例部署胜利后将申请回放重试，如果规定工夫内实例数仍为 0，报警告诉到零碎运维人员。
六、稳定性保障
6.1 网关稳定性保障
所有的函数流量都须要通过网关服务，因而事件网关的可用性尤为重要。首先对网关做了主备解决，当主节点出问题时立即启用备节点。通过为了加重网关的压力，通过限流和异步化两个伎俩，尽可能减小网关申请上游的资源耗费。网关也能很好的爱护上游业务实例，反对在上线平台配置工作实例降级，间接返回降级数据，也反对干涉限度异样的流量拜访，保障上游工作实例的失常运行。
6.2 资源监控、报警
基于 promethus 对所有的工作实例进行了监控，遇到实例重启、资源超过阈值等状况通过 alertmanager 发消息告诉到零碎运维工作人员。当工作运行失败也会发消息到工作负责人。同时将 promethus 数据输入给 grafana，反对可视化查看实例资源状况，也反对在上线平台查看工作运行历史、运行时长等根本信息。
6.3 日志采集、留存
因为工作实例受弹性伸缩影响，可能会被重新部署，这将导致旧实例的日志会无奈被找回，在工作实例中部署 filebeat 将日志文件导出，实现日志文件的长久化，同时反对在上线平台查看历史日志。在上线平台也能够登录到工作实例中查看实时日志排查问题，通过上线平台实现用户权限治理，限度用户只能登录有权限的工作实例，做到工作实例治理隔离。
6.4 bns 服务稳定性保障
bns 百度命名服务，能够了解为百度外部的 dns 服务，实现原理是在解析 bns 地址时，申请百度机器上的 bns-agent 获取注册的服务地址。思考到节约资源应用，在咱们的工作实例中是没有部署 bns-agent 的，所以个别会申请近程的 bns-agent 服务，但起初发现会偶现连贯超时问题，影响了工作的稳定性。因而思考了三种计划：
计划 1 ，工作实例中挂载 bns 服务，而后在实例启动命令中拉起 bns 服务；
计划 2 ，参考 dns 原理，制订 bns 域规定，在 coredns 遇到 bns 域的域名时，转发给宿主机的 agent 服务，agent 服务须要将 bns-agent 封装一层，能解析 dns 申请，转换为 bns 申请，从 bns-agent 获取机器 ip，封装回 dns 协定格局回包；
计划 3 ，基于百度外部 go 服务架构，反对注入 bns-host 环境变量，指定本地 bns 服务地址。能够利用这种形式将本地服务地址指向宿主机的 bns-agent 服务，遇到 bns 申请时转给宿主机 agent 服务解析。
最终抉择了计划 3，比照其余两个计划，计划 1 稳定性较差，计划 2 工作量较为简单。通过批改 faas-neters 源代码，向 Kubernetes 中写入 env 环境变量实现，解决了 bns 解析不稳固的问题。
七、我的项目总结
通过上线平台治理脚本工作，上线流程更加标准，同时记录了每次上线机器，能更快的定位是否是上线引入的问题，不便疾速回滚。各个脚本工作都是隔离的状态，防止因为批改了公共办法导致大量脚本无奈应用的状况产生，并且一个实例中的日志都由该工作产出，查看日志更具备针对性。
最终搭建上线平台和运行脚本应用的机器资源为原物理机 cpu 资源的 14%、内存资源的 8%，大大节俭了机器资源。如果还想进一步节俭资源，能够将不须要同时启动且低频运行的定时类工作部署在同个实例中，共用机器资源的同时，节约了频繁弹性伸缩带来的性能损耗。
———- END ———-
举荐浏览【技术加油站】系列：
百度工程师挪动开发避坑指南——Swift 语言篇
百度工程师挪动开发避坑指南——内存透露篇
百度工程师教你玩转设计模式（装璜器模式）
揭秘百度智能测试在测试定位畛域实际
百度工程师教你玩转设计模式（适配器模式）
揭秘百度智能测试在测试评估畛域实际
