阿里经验：Serverless化让服务部署和回滚更快乐
Posted 架构头条
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了阿里经验：Serverless化让服务部署和回滚更快乐相关的知识，希望对你有一定的参考价值。
林帆： 我是在 2017 年末时候加入的阿里巴巴研发效能部，也就是现在的云研发部，我们主要面向阿里集团内部以及阿里云上的用户提供开发者相关的产品。阿里的工作节奏很快，工作内容变化也频繁。我刚进到团队的时候在做一个云上环境隔离相关的探索性项目，项目没做多久，团队就发现了一个更大的机会，然后整体转向去做了云上的 IDE。后来这款 IDE 产品做得很成功，不仅公司里很多部门在使用，还做了公有云版本，和天池竞赛平台也做过合作。这个 IDE 项目我参与了 1 年，之后开始有了自己的小团队，负责云研发部的创新方向。
团队现在聚焦在云原生和智能研发这两个领域，其中云原生这部分主要和 Serverless 相关，在集团里面我们是阿里研发用户的入口。其实我们还做过一些比较有意思的事，比如在组建新团队之后，我们又抽空把最早没完成的那个探索项目重新做了，而且还开源了，现在在 Github 的 alibaba 仓库组里面，名字是 virtual-environment。背后其实还有很多小故事，不过今天我们先聊 Serverless 吧。
林帆： 之前阿里是自研的调度系统，用的容器技术也是自研的，就是现在已经开源的 Pouch，所以整个体系上蛮特殊，其实是把容器当做虚拟机在用，同时又支持 Dockerfile 这样的社区实践。后来集团服务上云被提上议程，差不多 2018 年就开始有苗头了。阿里云上都是走的社区 Docker 这一套容器玩法，所以就出现了技术栈整合的诉求。各方商议的结果就是全部统一到 Kubernetes 这套社区标准上来，基于这个标准阿里再向开源社区进行技术输出。集团里 Serverless、ServiceMesh、Kubernetes 的团队差不多都是这个时候开始成立的。
单从 Serverless 这条线来看，在阿里这种业务种类非常丰富的企业里，不同业务的流量高峰时间差异很大，以前虽然容器化了，但因为基本上当做虚拟机的方式来用，每个业务线各自屯一批容器实例来扛峰值流量，很多资源在业务空闲时段里都是闲置的。这块有听调度团队的同学说过一些数据，但也是未经官方证实的，我就不公布了。
不过总的来说阿里的资源平均负载率在整个行业同等规模量级的企业里，算比较靠前的，但还是非常低。这两年做了很多离线 + 在线业务混排之类的优化，最新的数据应该会更好一点。但要从根本的解决，必须要把整个资源池全部打通，集团业务上云这件事就提供了这种契机。
林帆： 推 Serverless 这件事算是整体战略性的一个决定，落地相对走得比较谨慎，2018 年基本是纯粹投入研发，去年开始业务试点，目前看起来今年还是一个扩大业务试点的阶段。
林帆： 分两部分来看吧。一部分业务是走的 FaaS 这条线，也就是函数即服务。阿里 Egg 框架的团队在集团里做了一款基于函数运行时的移植版本，我们叫 Egg as a Service，简称 EaaS，这样许多用了 Egg 框架的 Nodejs 应用就可以直接 Serverless 化。手淘导购的团队也做了一款更轻量的函数框架，推广效果也比较好。现在函数的总数目有差不多上万了。另外一部分业务走的是应用 Serverless 化的线路，主要是中后台服务，这个难度比较大，特别是 Java 的应用启动速度本来就慢，集团的云原生应用平台团队在这方面下了很大功夫去优化。目前供应链事业部已经在比较大规模的使用，其他还有一些电商部门也在试点，但规模相对没那么大。
林帆： 初期确实会有一些阻力。阿里是一个业务和技术共同驱动的公司，在业务这一侧最关心的问题是稳定性，只要能保障稳定，成本反而是相对次要的。因此像社区大力宣传的 Serverless 节省资源、削峰填谷这些事情，基础设施技术部门的同学很关心，但一线业务未必会买账。因此我们就需要一方面尽可能的降低业务侧的感知和改造，另一方面提供更好的技术价值点来说服业务参与试点。目前比较成功的两种推广模式，一种是供应链事业部在用的模式，从底层的基础框架进行改造，上层业务无缝切换到 Serverless 运行时，另一种是由于阿里的 Serverless 运行时支持通过镜像快照来加速业务扩容和回滚，尤其是快速回滚这个价值点是业务侧非常认可的。
林帆： 提效是非常明显的。而且即使不看底层资源的节约情况，单是服务通过函数化或者 Serverless 化改造后的流程简化和部署速度带来的效率提升就已经非常可观。过去一个应用创建出来以后每个环境都要单独去申请容器资源，应用的每次构建、发布时间也比较长。Serverless 化以后资源不用单独申请了，也不用时刻关注容量报警和手工扩容。函数这部分因为本身粒度比较小，所以构建和部署起来比过去的整个应用一起打包要快很多。应用 Serverless 化要得益于云原生应用平台团队开发的容器快照技术，使得过去要几十分钟才能做完的扩容和回滚，现在几秒钟就能完成。函数和应用的 Serverless 化建设这两部分我们团队都有同学参与共建，并且因为我们是集团研发用户的主入口，也是用户答疑的重灾区，有很多用户的一手反馈信息。具体数据我会在今年 QCon 的时候整理一份出来。
林帆： 最主要的问题是传统应用兼容性。函数这种就不用说了，除了 Node.js 的 Egg 框架做了专门的兼容版本，普通 Java 应用想改造成函数方式发布成本相当高。即使是应用 Serverless 化这种方式，目前还是要对应用的代码和镜像有所改造。主要因为容器快照技术的局限性，阿里的许多现有中间件，甚至 JVM 都需要进行改造，才能够适配这种能够实现秒级扩容的黑科技，当前云原生应用平台的同学对集团很多中间件都做了定制版本，需要应用切换到这些定制版本的中间件和 JVM 才行。另一种情况就是老生常谈的有状态服务，这类服务需要先改造成状态外置的才能 Serverless 化。中间件和 JVM 版本的问题目前需要推动相关团队去实现即兼容传统模式又兼容 Serverless 模式的版本，这件事现在已经在进行中了，这些问题一旦解决，我相信 Serverless 的春天很快就会到来。
林帆： 在推进应用侧 Serverless 的同时，我们现在也在和云原生应用平台合作推动集团统一 BaaS 和 GitOps 的建设，BaaS 化会将开发者需要的内部基础服务变得像云上的产品一样好用，这样上云过后的服务也可以同样方便的使用云上和内部的资源依赖，GitOps 则会让基础设施和运维参数能够和业务逻辑一起通过向仓库提交代码的方式进行变更，两者结合将大大提升开发者使用云资源的效率。今年阿里巴巴和微软共同推出了 Open Application Model 这样一个云原生应用发布的模型，现在已经在阿里内部的 Serverless 平台产品上被充分运用了，而且它本质是一种厂商无关的开源标准，在云上的产品里我们也会去推广。我们期望今年能够将 OAM 模型、统一 BaaS 和 GitOps 进行结合，将开发者效能的提升做到极致。
林帆，阿里巴巴研发效能部技术专家，花名金戟，现为研发效能部创新产品方向负责人。前 ThoughtWorks 资深 DevOps 技术咨询师，著有《CoreOS 实践之路》和《容器即服务: 从零构建企业级容器集群》两本书籍。具有丰富的一线架构和运维经验，目前主要专注于函数即服务和 Serverless 相关产品的一线研发和推广。
点个在看少个 bug 以上是关于阿里经验：Serverless化让服务部署和回滚更快乐的主要内容，如果未能解决你的问题，请参考以下文章 再战 k8s（12）：Deployment 指导下 Pod 的升级和回滚 阿里云宣布推出Serverless Kubernetes服务 30秒即可完成应用部署 k8s中helm安装部署，升级和回滚（chart，helm，tiller，StorageClass）