京东智联云在 Serverless 的探索

本文整理自 ServerlessDay · China 大会 - 《京东智联云在 Serverless 的探索》的分享，讲师为京东智联云的 PaaS 产品负责⼈朱琅。

本文主要分为三部分：

⾸先会介绍下 Serverless 的概念和定义，期间会讲讲我个⼈对 Serverless 的理解；
第⼆部分，我会着重介绍下 Serverless 在京东智联云的应⽤；
最后，会讲述我对 Serverless 未来的展望。

Serverless 的概念和定义

提到 Serverless，⼤家基本上第⼀时间会想到的就是 AWS lambda，没错，让 Serverless 这个名称真正⽕起来的其实就是 AWS 推出的 FaaS 服务 -- Lambda，它是⼀个平台，允许你在云上允许独⽴的代码段，通过预先设置好的事件触发代码的运⾏。

除了 FaaS 之外，还有BaaS，虽然和 Blockchain as a Service 的缩写⼀样，但它其实是 Backend as a Service - 后端即服务的缩写，⽆需编写/管理所有服务端组件，与虚拟机和容器相⽐，概念上更接近 SaaS（软件即服务），BaaS 服务都是领域通⽤的组件服务，通过 API 调⽤的⽅式来使⽤。

说完了定义，再来看下 Serverless 的发展史。

最早可以追溯到 2006 年，Zimki 推出的代码执⾏平台，它是⾸个提出按使⽤收费的服务；
接着就是 2011 年的 Parse，它提供了 BaaS 框架，⽅便⽤户基于它更快的构建应⽤程序，后来是被 Facebook 收购；
到了 2012 年，相继有 Fribase 和 IronWorker 服务，前者是⼀个针对移动端的应⽤开发平台，后来被 Google 收购了，后者是基于容器的应⽤负载平台；
到了 2014 年，也就是 AWS 推出了 Lambda，⾸个云上的 FaaS 服务，将 Serverless 概念带到了⼤众的视野中；
紧接着在 2016 年，Google，Azure，IBM 分别在他们的云服务上上线了 FaaS 服务。

在过去提到云计算，⼤家⽿熟能详的就是 IaaS，PaaS，SaaS，那么这个 FaaS 和其他三者什么区别？在我的定义⾥⾯，操作系统以上都需要⾃运维的属于 IaaS；PaaS 其实和 FaaS 是⼏乎⼀样的，除了应⽤这⼀层之外，其他都是由云服务提供商来进⾏运维；SaaS 最简单，现成的，直接上⼿使⽤即可。

⼤家可能会好奇，既然你说 FaaS 和 PaaS ⼏乎⼀样，那么为什么不直接称之为 PaaS 呢。不着急，我们先来看看这个：CloudFoundry，可能有⼀些⼈会⽐较陌⽣，但是如果你是属于云计算的⽼兵，那么你肯定不会陌⽣。

AWS 是 2006 年推出的，国内最早的阿⾥云也是在 09 年才成⽴，其实到了 2012 年左右，云计算的概念才慢慢传到国内，我是 2013 年开始涉⾜云计算，那时候其实就已经开始 IaaS，PaaS，SaaS 的竞争，有的公司从 IaaS 做起，有的直接从 PaaS 或者 SaaS 开始做起；那时候提到 PaaS，肯定就会提到 CloudFoundry（业界⾸个开源的 PaaS 平台），很多互联⽹企业基于 CloudFoundry 构建了 PaaS 云服务，⽐如：京东的 JAE，新浪的 SAE，百度的私有云等等。

当我第⼀次接触 FaaS 的时候，我第⼀个感觉就是，咦，这个和 CloudFoundry 很相似啊，在你向 CloudFoundry 发布应⽤的时候，对执⾏环境有要求，明确选择你是基于什么开发语⾔以及版本，如果当前平台不⽀持，那么你其实也是⽆法部署运⾏起来的，其次平台也提供了⾃动弹性伸缩，⾃动服务⾼可⽤，以及⽹关/路由等服务，然后你发现两者的最⼤区别在于， CloudFoundry 平台上提供的是⼀个常驻服务，但是 FaaS 是⼀个事件触发代码运⾏的服务。

为了让⼤家更直观的理解，我们来看下这个。

在裸⾦属时代，从硬件到代码都是需要⾃运维的，到了后来出现了虚拟化，像各家云上的云主机服务，使⽤者只需要关注操作系统以上这⼀层即可，再到后来的容器技术出现，使⽤者是需要关注容器⾃身和业务代码即可，⽬前 CloudFoundry 平台就是提供了容器服务，⽤户将⾃⼰的业务代码部署到容器中，作为⼀个常驻服务运⾏起来。最右边就是 Function 了，⽤户连容器都不需要⾃⼰维护了，只需要关注代码即可。

每⼀项新技术的出现即是为了解决当前的技术遇到的问题，同时新技术的采⽤也必然会引⼊新的问题。⾸先说下 Serverless 的优势：

优势⼀：降低成本，这⾥的成本既包括了运营成本，也包括了开发成本，这个很好理解，由于你不需要维护像操作系统，硬件等相关的组件，所以也就不需要雇佣相应领域的⼈员，从⽽降低了成本；
优势⼆：加速创新，当开发完业务代码，配合和现成的 Serverless 第三⽅服务（⽐如认证服务，⽂件存储服务等），可以快速的把业务部署并运⾏起来，⼤⼤缩短了过去业务开发的周期；
优势三：可扩展性，在没有 FaaS 之前，要解决业务的弹性伸缩功能，需要购买云⼚商提供的弹性伸缩服务，并且进⾏相应的条件配置之后，才能实现业务的⾃动弹性伸缩；在 FaaS 服务中，⾃动弹性伸缩的功能是默认就⽀持的。

接着说下 Serverless 的劣势：

劣势⼀：延迟，由于采⽤了 Serverless 的⽅式部署服务，所以服务之间的调⽤都需要经过⽹络传输，⽽不能是原先的本地调⽤，所以相对⽽⾔延迟肯定会增加；
劣势⼆：集成测试，由于采⽤了 Serverless 技术，那么当你开发完代码想在本地环境中进⾏测试验证，就⽐较麻烦，因为你本地不存在和云上的⼀样环境；
劣势三：供应商绑定，由于 Serverless 技术是⼀个新兴的技术，每⼀个供应商的提供技术和标准并不⼀致，所以⼀旦你基于某⼀个云⼚商的 Serverless 服务部署你的业务，如果再想搬迁到其他云上，那么难免对你的业务会有改造成本；

Serverless 在京东智联云的应⽤和实践

介绍完 Serverless 的概念和定义，接下来看看 Serverless 在京东智联云的应⽤和实践。

⾸先我们来看下⽬前在京东智联云上已经提供的 Serverless 服务列表都分别有哪些：

在 16 年的 2 ⽉份，京东智联云上线了对象存储服务，第⼀个采⽤ serverless 架构的云上系统；
在 18 年的 9 ⽉份，我们推出了 Faas 服务，是⼀款事件驱动的计算服务，通过函数服务，⽤户⽆需配置和管理服务器等基础设施，即可弹性、可靠地运⾏业务代码，快速构建应⽤与服务，且只需为代码实际消耗的资源付费；
在 18 年的 12 ⽉份，我们推出了 API ⽹关，提供API的全⽣命周期管理；⽤户可通过 API ⽹关实现⾃身系统集成和服务聚合，还能便捷安全地开放其业务功能和数据，并实现与开发者或合作伙伴的连接；
在 19 年的 1 ⽉份，我们推出了队列服务，是⼀款基于 serverless 架构的全托管消息队列服务，它可以提供⾼可靠并且⼏乎⽆限扩展的托管消息队列；
在 20 年的 1 ⽉份，我们推出了通知服务，是⼀款基于 serverless 架构实现发布订阅模式的消息通知服务，提供了⾼可靠、⾼可⽤、可动态扩展的消息推送主题。

接下来详细看下京东智联云的 FaaS 服务技术架构图。

中间粉⾊框起来的这部分属于 Faas 的内部系统模块；

⾸先我们来看下函数事件注册流程，API 会接收从 web 端传过来的事件注册请求，将事件触发条件等元数据信息存储到 MySQL 关系型数据库中，将函数的运⾏代码存储到 BaaS 服务，即 OSS 对象存储服务中，这样就完成了事件注册过程；
接着我们来看下函数事件的触发流程，trigger 是⼀个主从⾼可⽤服务，当有外部的 event 发送事件到 trigger 的时候，如果是⼀个同步事件，会直接将事件发送给 dispatcher 服务，如果是异步事件，会先发送到 queue ⾥⾯，再由 queue 将事件传递给 dispatcher 服务，dispatcher 会采⽤集群的部署模式，dispatcher 会判断当前 event 对应的函数代码是否已经处于运⾏态，如果是，那么直接会调⽤container ⾥⾯的函数代码；否则会发送请求到 scheduler 服务。scheduler 是⼀个主从⾼可⽤服务，scheduler 服务会负责启动⼀个 container 服务，在启动 container 的过程中会从 oss 服务中拉取这个 event 对应的函数代码并运⾏起来。

在整个系统中，trigger、dispatcher、scheduler 服务都会和 etcd 服务进⾏交互，通过 etcd 来确保数据的⼀致性以及进⾏⼀些选主操作。

⽬前 FaaS 已经接⼊的事件源分别是 API ⽹关，OSS【对象存储】，云事件（有点类似通知服务，可以定义事件源，⽐如是某⼀个资源的监控指标触发了条件之后，会调⽤ FaaS 服务），还有就是 JQS【队列服务】；前三者事件采⽤主动推送的⽅式，JQS 的事件是通过 FaaS 主动去轮询获取的。FaaS 接收到 API ⽹关的事件会采⽤同步处理⽅式，其他三者会采⽤异步处理的⽅式。

在使⽤新技术前的第⼀步⾸先是了解新技术是⼲嘛的，接下来就是如何基于新技术对现有的业务进⾏改造。

下⾯，我们以⼀个简单的单体应⽤为例，这是⼀个 B/S 类型的业务，Server 是⼀个单体应⽤，采⽤ MVC 的架构，涵盖了 HTML，JS，Service，Data Access ⼏个模块，数据采⽤ Database 进⾏存储；除了Database 之外，其他的服务都需要⾃开发和运维。

针对这个应⽤进⾏ Serverless 化之后，就变成了这样的架构，HTML，JS 的静态⽂件通过 OSS 来进⾏存储，⽤户认证采⽤单独的 User Authentication 第三⽅服务，不再需要⾃⼰开发单独的 service 服务来处理⽤户登录认证问题；⽽其他业务逻辑就使⽤ FaaS 来进⾏部署，通过 API Gateway 对外暴露，当浏览器触发业务调⽤的时候，就会触发相应的 FaaS 服务。通过 Serverless 化，真正需要开发的功能就只剩下 FaaS 的业务代码⽽已了，相对传统⽅式便捷了很多。

接下来，看看京东是如何使⽤ Serverless 服务的。

案例⼀，是京⻨消息平台，京⻨是京东给商家提供的⼀个⼯具服务市场，通过这个市场可以下载聊天⼯具，订单推送⼯具，运营分析⼯具等。下⾯这个图是京⻨的消息平台服务，会实时的将订单、商品、售后等信息通过加⼯处理之后，发送到京东智联云的 JQS 当中，JQS是全托管的基于 Serverless 架构的消息队列服务，相应的⼯具会从对应的 JQS 中获取到相应的信息，并把相应的信息展示给对应的商家。由于消息源的消息量是动态变化的，所以对消息队列的集群处理能⼒需求也是动态的，所以 JQS 很好的满⾜了京⻨的诉求，根据真实⽤量付费。

案例⼆，是京喜报警平台，京喜是京东旗下以拼购业务为核⼼的社交电商平台。当平台服务有报警信息进⼊到消息队列，会触发对应的业务线的报警处理的 FaaS 服务，根据 MQ 中的报警内容，做出相应的响应事件，可以是发短信，发邮件，或者是打电话。同时针对固定的报警逻辑，可以执⾏诸如重启服务，清理数据等相关操作。

因为本身报警就不是常态，并且随着业务的增加，如果有⼀个常驻服务来处理报警业务，这样难免会照成资源浪费，采⽤ FaaS 就可以很好的避免资源浪费的情况，当有报警产⽣的时候，再运⾏相应的服务来处理报警。

以上两个是⽐较简单的京东在使⽤ Serverless 服务的场景，当然还有更多的复杂场景也会使⽤到。就像上⾯所讲，Serverless 并⾮万能，不能满⾜所有场景的诉求，但是我还是依然很看好它的未来。

Serverless 的挑战与未来

在未来的 Serverless 形态中，还是存在很多的挑战需要去解决：

新的 BaaS 服务，可以提供临时和持久的存储服务，这样就可以避免购买常驻的存储服务，从⽽降低相关费⽤的开销
在符合 Serverless 理念的情况下，降低服务间的调⽤开销；对于⼀个线上的业务系统⽽⾔，低延迟是永远逃避不了的话题，如何采⽤ Serverless 的情况下，⼜能满⾜业务需求是 serverless ⼤规模使⽤的前提
软硬结合，提供更⾼的处理性能；针对在 FaaS 平台上运⾏的特定语⾔代码，在硬件层⾯进⾏相关的特殊优化，从⽽实现代码运⾏加速，提⾼性能；
Serverless 技术的采⽤降低 IT ⽀出成本；真正的让⼤家意识到 Serverless 的应⽤可以降低对 IT 的⽀出和投⼊；
采⽤ Serverless 可以更便捷、更快速的实现功能；通过周边的⼯具，更⽅便的让⽤户使⽤serverless来构建业务系统，真正实现业务的迭代和创新速度

即使 Serverless 还是有那么多挑战待解决，我对 Serverless 的未来依然充满信息；⽬前在 CNCF 的serverless 版图⾥⾯有越来越多的 Serverless 服务加⼊了进来，相信随着云原⽣的兴起，Serverless 可以搭上这个趟⾼速的列⻋，顺利起⻜。

我坚信，Serverless 未来可期！