截至 2019 年 7 月份,盒马鲜生累计开了 177 家店,几乎每三天开一家店,支撑盒马鲜生对外输出能力背后的框架就是新零售服务开放框架 NBF(New-Retail Business Framework),其中最核心的能力则是 Serverless 的架构设计和深度实践。在近期召开的QCon 上海 2019大会现场,InfoQ 采访了阿里巴巴高级技术专家冯微峰(诸葛瑾),了解支持了盒马、天猫超市、阿里健康等 10 个 BU,30 天调用百亿次的 NBF 框架的 Serverless 核心能力。
2009 年,伯克利以独特的视角发布了一篇文献,定义了云计算,十年过去了,这篇文章被引用无数,其中的观点更是当下最好的见证,比如按需计算的表现形式、消除云用户的前期承诺、根据需要在短期内支付使用计算资源的能力等。
2019 年,伯克利又以新的视角发布了一篇文献: 将云中的编程变得简单:伯克利视角下的 Serverless 计算。 观点同样让人眼前一亮:
Serverless 所提供的接口,简化了云计算的编程,其代表了程序员生产力的又一次的变革,一如编程语言从汇编时代演变为高级语言时代。
伯克利对 Serverless的预言是什么?伯克利认为:Serverless 将会在接下来的十年迅速被采用,这将会得到飞速发展。然而, 国内目前真正将Serverless 应用实践的开发者并不多,有些甚至收到了不太好的反馈,比如 CardGames.io 的开发者想更改下 API,同时尝试一下 Serverless 框架,结果发现费用贵了八倍,运行效率还慢了 15%,最后承认 Serverless 不适合自己的用例。
那么,Serverless 到底有没有价值?应该如何理解呢?
“Serverless 不是一种技术,而是一种架构”,冯微峰在采访中如是说道。他表示,目前的 NBF 框架使用的是阿里内部容器提供的弹性扩缩容能力,换句话说,Serverless 不是一个具体的技术,不是通过一个框架和底层能力就可以轻松实现的,它是一种架构,一种可以提升研发效能和降低开发门槛的架构,而不仅仅是提供快速弹性扩缩容能力,但是具体如何实现要看各自的业务特点。
在冯微峰看来,Serverless 架构是一个很好的方向。因为其带来的技术红利非常明显了。首先,从原来的 DevOps 到之后的 NoOps,研发可以更加关注写代码本身,容器稳定性和中间件通讯等都可以通过底层基础设施平台搞定;其次,资源也得到了极大释放;最后,基于 Serverless 的研发模式和交互模式将会更加简单,当技术体系从 Kubernetes 到 ServiceMesh,再发展到 Serverless 的过程中,底层很多基础设施都一层层封装起来了,比如把一些中间件的能力以 Sidecar 的形式下沉到了容器里面。
虽然 Serverless 对不少问题提出了很好的解决方案,但也要看基于什么样的维度来理解这一概念,如果单纯基于 CPU、内存等系统维度来理解这一概念,可能会导致一些业务场景的不适用,毕竟很多业务场景是有状态的,其资源的瓶颈可能并不在机器上,而是在 DB 上,那机器扩容的越多,DB 可能挂得越快,因为更多的请求流量打到 DB 上了,因此 Serverless 也是要区分场景使用的,否则不会得到很好的效果,反而提升了整个的使用成本。
在目前关于 Serverless 的探索中,FaaS 基本被认为是最佳范例,这与其自身特点有关。FaaS 非常轻量级,且无状态,运行很快,对于纯粹的无状态应用特别合适,虽然在冷启动层面存在一些瓶颈,但这种架构带来的红利还是解决了很多问题。
采访中,冯微峰表示,关于冷启动问题,在 NBF 中,FaaS 的主要功能是实现极速的服务发布。FaaS 引擎本身常驻在容器中,快速启动时只需要加载一个 Jar 包就可以了,服务发布时间就等于 Bundle 的加载时间(Bundle 是 OSGI 的概念,以 Jar 包形式存在的模块单元),这比传统的发布方式要快很多,传统发布方式需要容器启动和镜像加载等。而且 NBF-FaaS 也在准备与阿里 JVM 团队合作,尝试使用 JIT 和 AOT 的相关技术,进一步减少冷启动时间。以最简单的 Hello World 程序为例,NBF-FaaS 的发布时间可以做到毫秒级别。
此外,FaaS 的启动时间也与代码编写息息相关,如果启动代码中有大量的外部依赖,调用一个远程服务就需要几秒钟,整体启动时间也会被延长,当然这不是一个技术框架可以解决的问题,而是代码设计的问题了。
2016 年初,盒马在北京开了第一家店,用了大半年的时间,当时对于盒马最核心的诉求就是标准化定义一个新零售自动化开店的链路流程,然后基于这个链路流程做快速复制,最终保证门店的开店速度。截至 2019 年 7 月份,盒马已经开了 177 家店,几乎可以做到每三天一家店,这背后的技术能力就是基于 NBF(New-Retail Business Framework)——新零售服务开放框架实现的。
冯微峰表示,传统应用要解决的问题是研发流程复杂,整个研发过程需要创建应用、构建、打包和部署,NBF 的 Serverless 能力可以做到沉浸式开发,提供了一整套的 idea 插件,研发人员基本感知不到运维平台的存在;其次,传统研发的运维流程复杂,要关注容器的健康状况和容量规划,NBF 的目标是做到 NoOps;最后,服务资源隔离和机器资源的合理利用其实是 Serverless 的典型优势,这也非常适用于盒马的错峰场景。
如上图所示,NBF 的云原生 Serverless 架构底层是容器服务,借助了阿里集团的底层基础设施。其上的 Serverless 又分为两部分,一部分是 Serverless 容器,另一部分是容器里的 OSGI 框架,管理 Bundle 的生命周期。再往上一层是沙箱环境,Bundle 运行在沙箱环境中,彼此隔离。NBF 容器是一个云原生的容器,实现了对 Bundle 沙箱容器的托管,在沙箱容器中可以使用阿里的内部容器 (pandora,sofa,webx 等),也可以用业界标准容器 (springboot、tomcat 等)。也就是说 Bundle 无论代码怎么写,NBF 容器都可以充分支持。最后,NBF 正在打造一套云研发平台和云原生 SDK,统一对外输出 NBF 的云原生能力。
在此基础上构建出的 Serverless 架构主要提供三大服务能力:
1. 极速发布能力
2. 灵活的服务路由能力:可实现多态路由和降级路由。
3. 强大的服务运维能力:可实现毫秒级弹性扩容和极速回滚。
其中,服务路由主要解决了开放问题,得以让大润发等合作伙伴的 Bundle 服务能快速接入到新零售体系中来,其核心功能分为三部分:服务发现、服务路由和流量管控。服务路由主要有两个典型场景:多态路由和降级路由。
举例来说,一个业务系统需要基于业务身份调用其中一个采配服务,常见的方法是通过 Gateway 实现,这其实会让原来的两层架构变为三层,稳定性会变差,Gateway 很可能成为单点或者瓶颈,代码复杂度变高,可能还要做代码发布和变更。NBF 的 Broker 是一个 SDK,与业务在一起,完全可视化配置就可以实现服务发现和服务路由,整个过程是低代码和配置化的方式。
另一种是降级路由,盒马履约从最开始生成订单,到调用集单算法再到生成履约批次,一共需要经历这三个过程。其中,调用集单算法主要目的是降低整个配送成本,可以基于配送时间片和用户地址等来实现。由于盒马履约是 C 端链路上非常核心的节点,大促期间需要对集单算法进行容灾降级,原来的降级代码需要通过开关方式完成,降级代码和业务代码深度耦合、代码复杂度很高,现在可以通过 NBF-Broker 完成,一个降级 bundle 就可以实现被动降级和主动熔断,具体场景如下:
在服务运维方面,NBF 通过 Fast Cold Start、Fast Auto-Scaling 和 Fast Hot Start 实现毫秒级弹性扩容和保障服务可用。
NBF 进行了一系列 Serverless 深度实践,在今年女王节的时候,秒杀的 QPS 从 4000 飙到了 12 万,机器数从 2 台到 5 台、10 台再回降到 2 台。冯微峰表示,在未来 NBF-Serverless 对于长尾应用和非核心应用可以缩容到 0 台,当第一次请求过来的时候再进行机器扩容,如果业务方可以接受第一次机器扩容的延迟 (几十毫秒)。
如今,NBF 支持了 10 个 BU,运行在 NBF 上有 1137 个 SPI,1555 个 Bundle 和 5655 个方法,一共托管了 3570 台机器,12000 核 CPU,在 30 天内调用已达百亿次,未来计划帮助业务实现无缝上云和出海,支持一份代码发布多个环境。
冯微峰(诸葛瑾),阿里巴巴高级技术专家。2014 年加入阿里巴巴集团,2015 年作为技术初创员工加入盒马,负责订单履约等中台系统架构设计和研发,作为核心研发人员深度参与了盒马中台体系从 0 到 1 的架构演进。从 2016 年开始基于盒马的复杂业务场景架构设计新零售服务开放框架—NBF(New-Retail Business Framework),从最开始的流程中心衍生到目前 NBF 的六大中心体系,形成了一整套比较完整的服务开放能力。2019 年带领 NBF 团队回归阿里巴巴供应链中台,向包括盒马在内的 25 个新零售 BU 及合作伙伴统一输出 NBF 生态开放的能力。
更多国内外一线技术大咖分享请持续关注 QCon 全球软件开发大会,访问官网与技术大咖面对面交流实践心得。