百度 Serverless 架构揭秘与应用实践

　　1. 要做到真正的 Serverless 架构，需同时支持 FaaS 和 BaaS，做到快速上线、高弹性的优势，真正达成降本增效。

　　2. 文中提到的函数计算引擎 EasyFaaS 已开源：github.com/baidu/EasyFaaS

　　Distributed Cloud 2021全球分布式云大会·北京站于4月7日召开，在当天下午举办的分布式云报告会上，百度函数计算平台业务负责人史南胜发表了题为《百度Serverless架构揭秘与应用实践》的主题演讲。

　　以下为演讲概要：

　　1. 为什么要引入 Serverless?

　　为什么要做 Serverless?Serverless 能给我们带来什么?为什么要引入 Serverless?我们现在服务化不是做的挺好吗?PaaS 平台不是也做得挺好吗?为什么要用 Serverless呢?对于所有的场景都适用降本增效一说吗?史南胜首先站在客户的角度发出了一连串的提问。

　　金融领域、国有企业这样的领域，对于资源的利用率上不拘小节，没有像中小型客户那样应用资源非常的谨小慎微，所以对于金融领域，或者说一些对资源利用率要求不至于严苛的场景，主要提供人效开发，让开发成本降低。对于中小型客户，尤其是两三个人创业的场景，比如小程序的开发者，需要考虑到他们将产品推向市场的时间，以及业务布局的快速度，推荐他走 Serverless 的场景，这样的场景可以快速的提高他们的开发速度，以及降低运维的成本。

　　哪些场景合适，哪些场景不合适呢?史南胜表示，Serverless 并不是解决方案，并不能短期内替代掉服务化，或者微服务化的技术，它是在服务化或微服务化发展到一定程度以后，基于容器计算的新技术。经常有客户问，我们怎么从一个单边应用，或者从一个微服务架构应用迁移到 Serverless 场景呢?并不是每个场景都能够迁移的。所以说需要区分一些场景，将一些合适的场景我们去探索。

　　史南胜分成三个部分解析这一问题：第一，事件的触发处理;第二，数据处理计算;第三，应用后端服务。

　　探索和应用的场景主要包含如实时文件处理、图片裁剪添加水印等，这种场景为什么适合呢?因为不是时时刻刻都有用户在上传图片，或者不是时时刻刻都有这样的事件在处理，这样的场景是否通过函数计算和 Serverless 场景去解决?还有数据计算场景，比如说像物联网网关和 P2P 里面的计算等，应用后端服务现在大规模使用的是智能小程序的开发，让他们通过 Serverless 的场景快速将自己的技能通过函数计算平台能够快速的开发、上线，将产品推向市场，产生收益。这样的技能又可以在小度音箱上面去产生售卖和调用，在调用支付的时候会给创业者带来一定的收益。

　　哪些场景不太适合呢?像延迟敏感高，对于稳定性级别很高的交易场景、支付场景，还有检索场景，不太推荐在现有的技术发展现状下去使用 Serverless 和函数计算。

　　那么对于涉及隐私的场景适合用 Serverless 的架构方案去解决吗?在这里通过相应的实践和证明，隐私不是考量 Serverless 架构合适和不合适的一个很重要的因素，因为在任何的场景下都会去确保客户的隐私和数据(安全)问题。对于隐私高的场景，比如像金融领域我们都会去做私有化的部署。

　　现在看 Serverless 从广义角度来讲，按功能分为 FaaS 和 BaaS ，大家老生常谈的相对来说是比较狭义的概念，这样狭义的概念指的是 FaaS 上面，就是关注于业务场景的逻辑处理。而对于底层的存储、缓存和对象级别的存储来说，会依托于云上面的资源，或者本身自己的一些传统在微服务化下面的存储来去处理。

　　如果要做到真正的 Serverless 的架构方案，需要将 FaaS 和 BaaS 同时支持，这样支持以后才能真正拥有高弹性、高可扩容/可伸缩的优势，才能真正做到降本增效，不然的话 FaaS 流量上来以后，后台的 BaaS 技术如果跟不上，这样的弹性扩缩容是需要受到挑战的。但是今天史南胜主要从狭义的场景来介绍 FaaS 的基础，通常讲 Serverless 场景的时候指的是函数计算。

　　2. 百度的 Serverless 场景解决方案

　　

 

　　为了满足客户和开发者，或者以及百度内部集团所使用的一些场景，百度提供了五个终端级产品对外输出：

　　CFC(Cloud Backend Development)：面向公有云和集团内部云产品

　　CFC-Stack：以私有化部署为主的一站式解决方案

　　CFC@Edge：旨在将函数计算能力放在离用户更近的边缘侧，从而提高性能，降低延迟。目前我们实现了集群版和单机版，用于满足不同的场景。

　　EasyFaaS：是一个依赖轻、适配性强、资源占用少、无状态且高性能的函数计算服务引擎，目前正式对外开源，地址是https://github.com/baidu/EasyFaaS

　　CBD(Cloud Backend Development)：面向开发而设计的平台，比如小程序开发场景

　　百度经过数年的打磨，在私有化和公有化领域里面，将开源和公有、私有，以及面向百度其他内部云支持的产品打磨成统一的公共的底层函数服务支持，这个能够满足整个函数计算的编写、上线、开发和运营，在大部分场景下能够提供相应的技术支持，并且百度还开发相应的工作链，提供了相应的 SDK 和插件，以及运行时能够供定制化的业务团队做二次开发。

　　

 

　　史南胜对百度函数计算的整体架构进行了介绍，基于整个云端实践进行触发，整个函数计算的触发场景包含很多种，此处列举了6种：：HTTP服务请求、消息队列、定时任务、BOS存储事件、DuerOS技能、CDN事件。

　　这些技能触发器都可以以同步或者异步的方式调用函数计算，这样的函数计算遵循 CFC 的租赁格式，而且跟 AWS 进行对标没有障碍。如果有客户在 AWS 上面去做的函数计算，也可以很方便的去做迁移和使用。右侧部分的配置服务，配置服务是离线管控模块，这组模块用来可以支撑代码的管控、包的上传，以及包括相应的原数据的管理。

　　函数的触发服务是我们的一个关键录用模块，用来监听事件的请求、权限的管理、资源的调度申请、路由等等，资源的调度服务用来管控整个函数的运行资源池，函数的整个运行资源池是我们第二大核心部分，函数运行引擎就是刚才的开源重要的代码模块，函数计算引擎提供了我们在运行代码生命周期的管理。用户的空间会按照我们在函数代码功能的执行和空间的大小会动态的调配相应的内存 CPU 占用空间。

　　左侧是做资源的释放，资源池的维护会通过相应的服务模块架构对资源进行管控。资源的调度服务就是用来去响应事件触发服务，对整个资源池的管理。函数计算的核心就是基于事件的处理调度，将用户的代码和函数的核心功能进行动态的加载空间容器，并且进行动态销毁的过程。

　　史南胜就百度近期开源的一个函数引擎——EasyFaaS 分三部分进行了介绍，这是一个依赖轻、适配性强、资源占用少、无状态且高性能的函数计算服务引擎。

　　

 

　　第一部分是产品功能，EasyFaaS 提供了核心的函数信息管理、代码包管理、版本管理、灰度发布功能，满足了大部分场景下函数计算的核心诉求，用户拿到 EasyFaaS 就可以快速的去搭建一个基于百度函数计算引擎的计算平台，能够满足他在部分的业务场景下定制化的开发。这样的开发通过开源的方式能够让大家提交相应的功能，将这些功能能够共建起来;第二部分是请求控制与容器调度;第三部分是容器与网络技术，进一步将容器的利用资源最大化，并且提供多元的运行池。

　　

 

　　EasyFaaS 开源的核心请求模式中，函数在请求的时候，冷启动是需要时间的，黄色的图标标识了整个事件请求以后过来的响应过程，可以支持用户自己主动的请求，以及通过云端事件触发的方式，原数据的管理对数据的代码包和信息权限验证进行管控，通过funclet 模块进行二次容器初始化和管控。

　　EasyFaaS 以单 Pod为最小服务单位，每个Pod中包含3个容器，分别为 controller、funclet 和 runner-runtime。controller 负责流量调度及容器池状态管理，runtime 是用来加载多语言运行时的一些镜像环境，这些镜像和环境初始化以后它便退出了，所以核心部分是通过 funclet 管控资源，合理的调配函数计算能力。绿色的部分是热启动的，为了考虑在高并发场景下能够支撑业务场景的请求，所以支持热加载的模式，热加载的模式现在可以做到1毫秒以内。

　　3. 百度的 Serverless 场景解决方案

　　基于这样的核心引擎，可以在哪些地方去落地?又产生了哪些经验和教训呢?史南胜主要举了三个重要的案例场景。

　　单体应用，或者微服务应用怎么迁入到 Serverless?对于一些场景，比如说小程序场景通过 API 网关的模式，然后调度到百度智能云函数计算处理业务，并且发起相应的业务逻辑去调度相应的后端服务，可以将部分的业务代码迁移到函数计算平台。将原来核心的部分业务逻辑代码仍然以微服务这样的方式放在后端服务里面。如果面对中小型企业客户，本来在云上产生了相应的存储和计算资源，可以继续使用云数据库云缓存的方式使用，百度云上的资源可以一站式打通。

　　

 

　　在微服务架构领域，服务与服务之间除了 IDC 方式调用以外，函数计算方式可以通过黄色的箭头去发消息，可以支持和集成，可以提前加载到函数计算平台，以镜像的方式进行加载，这个可以让包降低很多。所以说消息队列可以监听完以后，百度函数计算的另一个板块可以进行相应。大家可以将百度函数计算的方式以微服务化的理念来去开发和运作，并且还可以将这样的处理方式上传到云存储上面去。

　　业务方去处理什么呢?他们只需要聚焦在业务逻辑处理，编写相应的代码，百度的代码和插件层面提供了很好的工具开发，业务方可以在 web id，或者相应的代码 id 上面去开发，开发完了以后通过打包的方式，或者一站式插件集成的方式提交。对于复杂的场景，百度提供了编排方式，只需要编写 Serverless 的压缩文件就可以处理更复杂的分布式的业务处理逻辑。

　　这是一个比较典型的提供给一些相应的私有客户部署的能力，这个能力是用来做什么呢?是用来做整个大数据的处理，客户聚焦在中间这两部分，就是事件触发器定义和函数计算逻辑的编写。百度支持通过流失数据和批量数据镜像挂载的方式，可以支持 afs，并且可以支持消息队列流式数据的监听，通过这样的方式触发调起函数计算，执行业务，支持业务的逻辑计算，将相应的数据分发到其他的业务部门里面去。

　　用户基于百度的 Serverless 平台提交代码就可以定义事件、配置信息了，这样带来的好处架构上面的事情交给了平台方去做，业务平台上面的事情交给了业务方去做。

　　第三个案例，可以通过百度云的函数计算案例体验，这个体验可以给大家包括一些技能的开发者带来很多的一些像公积金的计算，或者天气的查询，史南胜表示自己也通过小程序和 OS 方式同时开发了两个技能，以小程序的方式和 OS 方式发布出来给别人使用，这样的技能可以直接调用天气的方式，比如调用开放接口的墨迹天气自己使用，并且可以将业务逻辑算法集成。这个产生什么收益呢?可以按技能付费，做成三步：云函数创建与自定义、技能创建与绑定技能、运行时请求路由，请求调度的资源统计，以及账号的挂靠。通过这三步可以迅速的将一个新的家庭小度音箱的智能场景能够快速的连接起来。

　　除了这些场景，还可以在哪些场景去使用呢?包括应用分发的场景领域，像游戏包，分渠道的打包和运作过程，小程序的开发，以及在集团内部持续的CICD 和搜索图谱，包括百度的搜索阿拉丁卡片，以及在金融领域私有化部署，还有汽车、教育等领域的新技术联动，以及大数据处理，都可以去用函数计算的方式去处理。

　　4. 未来展望与延伸

　　百度函数计算今后还会围绕哪几个方面去运作呢?Serverless 场景以前大家都处于观望状态，现在开始在小规模场景使用，之后大规模场景使用。

　　百度函数计算重点是帮助客户转型，还是围绕降本增效的理念为大家节省资源，并且提供更稳定的服务。在公有化、私有化和开源生态领域，百度会去形成一个组合拳，开源的部分也希望大家与百度一起来来共建。

　　

 

　　百度的云原生，除了 Serverless 函数计算，还有容器服务和微服务架构的治理，还有容器调度，以及效率云的 DevOps 的计算。百度在今年申请了一站式的技术栈，欢迎大家一起了解一下，不仅提供 Serverless 的解决方案，还提供容器、微服务架构治理的解决方案，包括效率上面的解决方案。

　　近几年，百度在云原生方面获得了一系列的奖项和认证。其中包括：通过了 Kubernetes 一致性认证并且是国内首批 Kubernetes 认证服务提供商(kcsp);生态方面，百度是国内首批 CNCF 黄金会员，多次高级别的 KubeCon 大会赞助，并参与信通院《云原生应用实践白皮书》、《无服务器架构技术白皮书》等文件撰写;上游贡献方面，百度主导了云原生 AI 工程项目 Paddle EDL;共同主导Kubernetes调度项目 Kube Batch等，百度期待与更多伙伴参与进开源社区的建设。