网站的在线支付怎么做,用别人的二级域名做网站,济南旅游网页设计,网页制作与网站建设实验报告通过对权益玩法平台现有业务应用的Serverless化改造#xff0c;权益团队在双十一期间完美地支撑了业务需求#xff0c;在研发效率、运维保障等方面都体现出了很高的价值和收益。 项目背景 淘宝权益平台是负责淘宝权益营销的核心团队#xff0c;团队除了负责拉菲权益平台外权益团队在双十一期间完美地支撑了业务需求在研发效率、运维保障等方面都体现出了很高的价值和收益。 项目背景 淘宝权益平台是负责淘宝权益营销的核心团队团队除了负责拉菲权益平台外也越来越多地承接营销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、双十二等大促和各类权益营销活动的使命是全集团权益营销策略执行和用户优惠触达的主阵地。团队构建了以权益平台为核心、权益玩法和互动相结合的完善权益营销技术体系实现百万级的业务峰值流量支撑和亿级规模的权益发放能力为业务打造出覆盖几亿消费者、千万商家的全方位营销解决方案不断支撑业务创新的持续发展成就更高的商业价值。 ¤ 拓展阅读 ¤ 3DXR技术 | 终端技术 | 音视频技术 服务端技术 | 技术质量 | 数据算法
