通过对权益玩法平台现有业务应用的Serverless化改造，权益团队在双十一期间完美地支撑了业务需求，在研发效率、运维保障等方面都体现出了很高的价值和收益。
项目背景
淘宝权益平台是负责淘宝权益营销的核心团队，团队除了负责拉菲权益平台外，也越来越多地承接营销IP和轻互动营销等需求，这类需求除了内容上非常多样外、交付上也是又多又急，对技术的挑战性非常大。有别于平台型应用，营销IP类需求对业务模型和架构的要求相对不高，但是对开发产研的效率要求非常高，所以我们急需一套可靠的产研体系去支撑营销IP和轻互动的需求。
权益玩法平台就是在这样的背景下诞生的，其设计目标是通过对营销和玩法通用能力的沉淀和复用，构建出一整套营销玩法能力体系，来降低业务需求的开发成本，提升业务的交付效率。
基于Ring容器化的尝试
为了实现既定的设计目标，权益玩法平台一开始设计了基于Ring容器化能力的方案，Ring是由我们团队自研开发的JVM容器化框架，支持对业务能力进行动态加载，其核心特点是JVM热部署和机器按需部署。Ring框架由一个宿主应用和多个业务容器组成，宿主应用提供整体的基础能力和共享能力，不同业务扩展由各自的容器(farjar载体)实现，通过控制不同的宿主应用分组挂载不同的业务jar包实现业务的隔离效果。借助Ring框架的热部署能力，可以实现秒级部署能力，效率上有极大的优势。
基于机器分组的业务隔离能力：
基于基座应用和容器应用的产研隔离和热部署机制：
- 平台开发同学负责基座应用基础服务和共享服务的开发和运维
- 业务开发同学专注于业务逻辑开发，基于热加载能力部署到基座应用
▐ 权益玩法平台基于Ring的业务形态
权益玩法平台在Ring的支持下，在同一应用内，实现了对核心业务的独立部署和对非核心业务混部方案，既满足了核心业务的稳定性要求，又节省了整体业务的维护成本和资源成本。
▐ Ring架构的优点
效率高：
- 由平台提供中间件和通用服务支持，降低了业务开发成本；
- 支持热部署发布，开发和交付效率高；
隔离性好：
- 基于机器分组的强隔离能力保障业务和流量隔离；
▐ Ring架构的不足
- Ring框架本身是为业务扩展设计的，但权益玩法平台多个业务间并非扩展关系，所以来说Ring并不是最佳的使用场景，使用上也存在系统权限、产研角色等一定的局限性；
- 为支持热部署，Ring框架在应用底层框架上做了很多的改造和定制，除了潜在的内存泄漏等风险外，这些需要业务开发时进行感知的特殊逻辑，也无形中提高了开发和运维的门槛和成本；
▐ 小结
基于Ring架构的权益玩法平台应用已经能很好的支持业务发展，但同时也存在一些的不足和问题。为更好的支持业务发展，我们也在不断探索更好的架构和产研模式。也在这个过程中，刚好遇到Serverless的大范围推广，在经过调研和比较之后，我们决定拥抱Serverless重构我们的产研体系。
初识Serverless
Serverless是个相对比较广义的概念，从不同的角度可以有不同的解释。从我的粗浅的理解来说，Serverless可以简单认为是一种将应用与基础设施进行分离的架构理念，通过指导软件架构和职责分工，使开发者更聚焦在业务逻辑，从而减少对基础设施的关注，其核心要素是架构分层和产研分工：
从计算机发展的角度看，分层一直是永恒的话题，操作系统分层、网络分层、文件系统分层，分层让更多的底层实现得以屏蔽，让上层使用者只需要通过简单的API即可使用计算机复杂的能力，在这一过程中，分层变得越来越多、分工也变得越来越细，除了操作系统层面的分层，我们也看到了云服务提供了计算资源的分层，中间件提供了基础服务的分层，Serverless更进一步提供了业务运行时的分层。有了Serverless，业务开发者不用再关心中间件、机器资源、jvm容器，只需要把业务代码写好，剩下的都交给Serverless。
Serverless的设计目标
- 免运维：应用的运维工作将由Serverless的服务提供方负责，普通业务开发人员不用再关注机器部署、扩缩容等运维的事情；
- 更低成本：借助弹性能力，Serverless会根据应用负载动态进行扩缩容以满足业务的实际需求，避免了资源的浪费情况；
- 快速交付：从普通应用发布要重启整个jvm容器、中间件相比，Serverless发布粒度可以控制在单纯业务代码维度（业务函数），可以获得极致的发布效率体验；
- 统一架构：所有的基础能力都由Serverless基座负责，所以JDK的升级、中间件升级、通用二方包版本维护等不再需要推动每个业务去升级，只需要由专人通过Serverless基座即可完成业务无感升级；
Serverless应用解构
相较于传统应用，Serverless应用对于我们认知中的研发体系挑战还是比较大的，Serverless的整个设计和运作体系都和传统应用发生了很大的变化，这对于技术研发同学来说，了解这其中的原理和思路是必不可少的。所以我试图从一个传统应用出发，通过逐步解构整个过程，粗浅的介绍下Serverless是怎么实现和运作的：
第一层. 普通应用：
我们一般的普通应用都由Pandora容器(隔离容器)加载，其中包括了中间件和业务自己的spring容器
第二层. 业务逻辑拆解
我们日常开发的代码中，除了业务本身的代码，肯定也包括很多通用的代码逻辑，比如对商品、人群等服务的封装和调用，这些大多数应用都会用到的逻辑，我们却一直在多个应用间不断地重复编写这些代码。
第三层. 业务容器分层
通过区分业务代码和通用代码，我们可以进一步对业务的Spring容器进行拆分，区分成通用Spring容器和业务Spring容器，进而就分别控制不同业务容器的加载和销毁。
第四层. Serverless化
通过将业务能力和通用能力分层之后，就可以进一步形成以基座应用和业务应用为概念的独立产品和部署体系，从功能、产研和运维体系上进行了彻底的隔离和分工。
Serverless的产研和交付形式
Serverless对于业务最大的影响就是对原有产研体系的革命，一方面出现了专门的分工人员专职负责Serverless基座的开发和运维角色，另一方面，普通的业务开发不再需要关注机器容器、jvm和中间件等服务，更专注于业务需求实现和交付：
传统应用交付形式：研发负责整个Docker容器内的所有东西
Serverless的全新产研分工：职责分工，专业的人做自己最专业的事情
Serverless的全新应用交付形式：分层独立交付
Serverless全新部署体验
除了能力分层和产研分工，Serverless带来的还有一个重点特性就是飞一般的部署速度。以往可能需要五~十分钟才能完成的部署，Serverless缩短到了一分钟以内，真正让日常的开发体验朝着所写即所得更进一步。
要了解Serverless部署快在哪里，我们要从普通的应用部署流程说起，看看我们平时的部署都慢在哪里：
上面是我们一个普通应用第一次新部署和更新部署的核心节点，镜像构建、中间件及基础服务启动都是耗费了大量时间，而且为了保障服务不中断，我们还要考虑分批部署，将原本已经很长的部署时长Double了一下。
为了解决部署耗时的问题，Serverless设计了一套更高效和敏捷的部署体系，其中通过多种机制加速了我们的整个部署流程：
- 免业务镜像构建：
在Serverless体系下，每次业务交付的只剩下业务代码，已无感知Docker容器，自然也就没了镜像构建的必要，镜像的管理统一交由Serverless基座负责，而且基座内也只会包含中间件和通用业务功能等不频繁更新的内容，业务的变更内容将通过独立的fatjar形式动态加载到运行容器中。
- 缓存服务容器：
在镜像标准化的前提下，镜像的加载和启动就不用再依赖于业务本身的变更发布，在业务发布使用之前，机器就可以提前把Docker、JVM、中间件、Spring容器、通用服务等加载和启动起来，并统一缓存到容器缓存池中，业务真正使用的时候只需要拉取已初始完成的容器加载业务代码，并完成流量切换就可以提供服务。
- 滚动发布：
在普通情况下，为了保证服务不中断，我们至少需要提供两台服务机器，发布的时候还需要分两批平滑发布，除了部署很耗时，测试和调试也是很麻烦。有了Serverless，在预发环境等测试环境我们就可以只部署一台机器，发布的时候，Serverless会从缓存容器中拉起一台新的容器进行加载，在完成快速启动后，进行流量切换就完成了平滑部署，真正让部署起飞。
通过总结以上几个核心的机制，Serverless让一个环境的新部署和更新部署变更非常简单和高效：
Serverless插件-通用能力下沉的利器
在Serverless基座中，除了中间件等基础能力外，更重要的是要承载业务通用能力下沉的重任。一方面，每个业务应用基本都会涉及到需要去对接商品、账号、人群等二方服务，其中有些服务会存在文档不全面、依赖臃肿、协议不规范等问题，极大影响了业务开发的质量和效率；另一方面，业务自身也有很多需要复用的业务逻辑，如何快速共享和接入、统一升级和维护也是大家一直来苦恼的问题。对于业务来说，非常需要那么一个解决方案，既能简单可靠成本低，又能满足以下所有的能力复用诉求：
- 类隔离机制：
不同二方依赖和模块间通过类隔离来解决模块间类冲突问题，同时解耦单模块升级对其他模块的影响来保障稳定性；
- 可控类导出机制：
类隔离机制解决了不同模块之间的类冲突问题，但业务通用模块的存在核心还是给上层页面提供服务，模块和业务之间不可避免需要通信机制（如进程间通信常用到的socket通信），这就需要可控的类导出机制，控制只导出必要的接口类或者API接口等方式，既要实现通信能力，又要避免了通信模块和业务代码之间的类冲突问题和依赖升级问题；
- 生命周期管理机制：
如果共享的业务模块涉及到更复杂的逻辑，就会出现一个模块内不同功能在何时启动和初始化的问题。尤其是在Serverless存在容器缓存机制的情况下，就必然需要生命周期管理机制来控制不同逻辑的初始化和销毁动作，比如在容器缓存时初始化无副作用的逻辑，而在真正使用时再把有其余的功能进行初始化，以满足不同业务的多样化诉求；
- 统一升级维护能力：
类似于二方包这样的共享方案，统一升级维护一直是个大难题，联系人帮忙升级也是常事，所以在Serverless体系下，这也是必然要考虑和解决的问题；
Serverless插件就是给这些问题提出的一个完美解决方案：
- 继承自Pandora的优秀类隔离机制：每个插件独享自己的ClassLoader，多个插件之间依赖互不影响，可以独立升级和切换而不影响其他插件和业务本身；
- 多粒度的类导出能力：可以将类的导出控制在最小粒度，在提供服务的前提下将对业务应用的影响控制在最低水平，也最大幅度降低了插件的修改升级对业务潜在的影响和风险；
- 完善的生命周期管理：满足不同插件在不同阶段执行自定义逻辑的需求，丰富了Serverless插件的使用场景和想象空间；
- 统一的管理和运维能力：借助Serverless的统一基座服务，Serverless插件将由基座维护者统一进行维护，插件的升级等问题都将真正做到业务无感，所有业务应用都可以享受到最新最全的插件带来的业务效率大提升。
Serverless的优势小结
通过对Serverless的初步了解和研究，我们也总结出了Serverless的几个核心优势，这些优势也成了我们决定全面拥抱Serverless的关键：高效的产研效率：
- 深度集成公司产研体系，应用管理和运维成本都非常低；
- 业务开发无需感知和管理中间件和Docker等逻辑，业务开发成本明显降低；
- 基于滚动发布和容器缓存机制，实现了比肩于热部署的发布效率；
完善的隔离和插件机制：
- 完善的类隔离和导出机制，在二方包隔离、插件隔离、冲突规避等方面可以发挥很大的作用；
- 通过插件机制，可以方便地实现业务代码的共享和复用，实现业务能力的有效沉淀
- 开放的插件生命周期扩展能力，给业务提供了非常大的创造和想象空间；
运维成本低：
- 统一维护的Docker、中间件、JDK、依赖包等能力，让应用的基础升级维护变得简单；
- 基于弹性和缓存机器资源池能力的快速动态扩缩容能力，将会降低业务的维护成本；
权益玩法平台的Serverless实现
权益玩法平台在经历了以Ring为基础的运行模式之后，我们开始了全面拥抱Serverless的脚步：
- 创建了统一的权益玩法平台基座，有权益团队统一维护升级，服务于所有的权益玩法平台Serverless应用集；
- 针对常用的账号、商品、人群等二方服务，统一通过Serverless插件进行了封装，业务应用可以开箱即用；
- 针对中间件、日志等服务则进行了二次插件封装，以降低业务的上手成本和使用成本；
同时基于业务扩展型的业务应用，我们通过平台能力下沉、业务扩展Serverless接入的方式来满足平台管控和业务隔离的双向需求：
成果和收益
通过对权益玩法平台现有业务应用的Serverless化改造，权益团队在双十一期间完美地支撑了业务需求，在研发效率、运维保障等方面都体现出了很高的价值和收益：
- 得益于简化的业务研发流程和丰富的插件支持、业务的部署和交付周期相比于之前减少30%，开发成本大幅降低，业务开发效率提升显著；
- 得益于部署流程优化、容器缓存机制和滚动部署加速，部署时长减少80%，极大缩短了需求交付周期；
成果和收益
- Serverless作为公认的未来软件产研体系方向之一，我们也必将持续推进现有业务的Serverless改造，也期望Serverless能给我们的业务技术带来更多的创新力和想象力；
- Serverless作为最新的产研体系，也必然存在着各种问题和挑战，作为使用Serverless的业务之一，我们也是见证了Serverless从初期问题频出到最终完美表现双十一的过程，也期待Serverless能进一步升级优化，提供更强大的能力，助力业务发展。
团队介绍
我们是大淘宝技术权益营销技术团队，是一支以权益优惠为核心的专业营销团队。我们肩负着支撑天猫淘宝双11、618、双十二等大促和各类权益营销活动的使命，是全集团权益营销策略执行和用户优惠触达的主阵地。团队构建了以权益平台为核心、权益玩法和互动相结合的完善权益营销技术体系，实现百万级的业务峰值流量支撑和亿级规模的权益发放能力，为业务打造出覆盖几亿消费者、千万商家的全方位营销解决方案，不断支撑业务创新的持续发展，成就更高的商业价值。
