京东智联云在 Serverless 的探索

作者:

发布于: 2020-7-16

归档于:

标签:ServerlessDaysMeetup

本文整理自 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 形态中,还是存在很多的挑战需要去解决:

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

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

我坚信,Serverless 未来可期!



传送门:

欢迎访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!