タオバオ権益ゲームプラットフォームのサーバーレス実践

エクイティゲームプラットフォームの既存のビジネスアプリケーションのサーバーレス変革を通じて、エクイティチームはダブルイレブン期間中のビジネスニーズを完全にサポートし、研究開発の効率性と運用保守保証の面で高い価値とメリットを実証しました。

プロジェクトの背景

淘宝株式プラットフォームは、淘宝株式マーケティングを担当する中核チームです。Lafite 株式プラットフォームの責任に加えて、このチームはマーケティング IP やライトインタラクティブマーケティングのニーズもますます引き受けています。チームはコンテンツが非常に多様であることに加えて、配送も担当していますが、緊急性の高い仕事が多く、技術的にも大変です。プラットフォームベースのアプリケーションとは異なり、マーケティング知財の要件は、ビジネスモデルやアーキテクチャに関する要件が比較的低いものの、開発や生産研究の効率性に対する要件が非常に高いため、マーケティング知財と生産研究をサポートする信頼性の高い生産および研究システムが緊急に必要です。軽いインタラクションが必要です。

エクイティゲームプレイプラットフォームはこのような背景のもとに誕生し、その設計目標は、一般的なマーケティングおよびゲームプレイ機能の蓄積と再利用を通じて、マーケティングゲームプレイ機能システムの完全なセットを構築し、ビジネスニーズの開発コストを削減し、ビジネス配信効率を向上させることです。

Ringをベースにしたコンテナ化の試み

確立された設計目標を達成するために、Equity Game Platform は当初、Ring のコンテナ化機能に基づいたソリューションを設計しました。Ring は、ビジネス機能の動的な読み込みをサポートする、当社のチームによって独自に開発された JVM コンテナ化フレームワークです。その中心的な機能は、JVM のホットネスです。 . オンデマンドでの展開とマシンの展開。Ring フレームワークは、ホストアプリケーションと複数のビジネスコンテナで構成されます。ホストアプリケーションは、全体的な基本機能と共有機能を提供します。さまざまなビジネス拡張機能は、独自のコンテナ (Farjar キャリア) によって実装されます。さまざまなビジネス jar は、さまざまなホストアプリケーショングループを制御することによってマウントされます。パッケージにより事業分離効果を実現します。リングフレームワークのホットデプロイメント機能を利用すると、第 2 レベルのデプロイメント機能を実現でき、効率の点で大きな利点があります。

マシンのグループ化に基づくビジネス分離機能:

ベースアプリケーションとコンテナアプリケーションに基づく、運用と研究の分離およびホットデプロイメントメカニズム:

プラットフォーム開発学生は、基本サービスとベースアプリケーションの共有サービスの開発、運用、保守を担当します。
ビジネス開発の学生は、ビジネスロジックの開発に重点を置き、それをホットロード機能に基づいてベースアプリケーションに展開します。

▐株式ゲームプレイプラットフォームはRingのビジネスフォームに基づいています

Ring のサポートにより、エクイティプレイプラットフォームは、同じアプリケーション内でコアビジネスの独立した展開と非コアビジネスの混合展開を実現します。これにより、コアビジネスの安定性要件を満たすだけでなく、全体的なビジネス維持コストとコストも節約されます。リソースコスト。

▐リングアーキテクチャの利点

効率的：

このプラットフォームはミドルウェアと一般的なサービスサポートを提供し、ビジネス開発コストを削減します。
高い開発効率と配信効率により、ホットデプロイメントとリリースをサポートします。

良好な分離:

マシンのグループ化に基づく強力な分離機能により、ビジネスとトラフィックの分離が保証されます。

▐リングアーキテクチャの欠点

Ring フレームワーク自体は事業拡大を目的として設計されていますが、株式ゲームプレイプラットフォームの複数の事業は拡大関係にないため、Ring は最適な利用シナリオとは言えません。役割;
ホットデプロイメントをサポートするために、Ring フレームワークは基盤となるアプリケーションフレームワークに多くの変更とカスタマイズを加えています。メモリリークなどの潜在的なリスクに加えて、ビジネス開発中に認識する必要があるこれらの特殊なロジックも実質的に効率を向上させます。開発と運用と保守のしきい値とコスト。

▐まとめ_

リングアーキテクチャに基づく株式ゲームプレイプラットフォームアプリケーションは、すでにビジネス開発を非常にうまくサポートできますが、いくつかの欠点や問題もあります。事業開発をより適切にサポートするために、私たちはより良い構造と生産および研究モデルを常に模索しています。その過程でたまたまサーバーレスの大規模推進に遭遇し、検討・比較した結果、サーバーレスを採用し、生産・研究体制を再構築することにしました。

サーバーレスの最初の紹介

サーバーレスは比較的広い概念であり、さまざまな観点から異なるように解釈できます。私の表面的な理解では、サーバーレスは単にアプリケーションをインフラストラクチャから分離するアーキテクチャ上の概念であると考えることができます。ソフトウェアアーキテクチャと責任分担をガイドすることで、開発者はビジネスロジックにより集中できるようになり、インフラストラクチャの負担が軽減されます。アーキテクチャの階層化と生産と研究の分業です。

コンピュータ開発の観点から見ると、階層化は常に永遠のテーマです。オペレーティングシステムの階層化、ネットワークの階層化、およびファイルシステムの階層化により、より多くの基礎となる実装が保護され、上位層のユーザーは単純な API のみを使用できるようになります。その過程で、OSレベルでの階層化に加え、クラウドサービスによるコンピューティングリソースの提供など、階層化・分業化が進んでいます。ミドルウェアは基本サービスの階層化を提供し、サーバーレスはさらにビジネスランタイムの階層化を提供します。サーバーレスを使用すると、ビジネス開発者はミドルウェア、マシンリソース、JVM コンテナについて心配する必要がなくなり、ビジネスコードを記述するだけで済み、残りはサーバーレスに任せることができます。

サーバーレス設計の目標

運用保守無料：アプリケーションの運用保守はサーバーレスサービスプロバイダーが行うため、一般のビジネス開発者はマシンの導入や容量の拡張・縮小などの運用保守を意識する必要がなく、
低コスト:サーバーレスは、弾力性機能により、アプリケーションの負荷に応じて容量を動的に拡張および縮小し、ビジネスの実際のニーズを満たし、リソースの無駄を回避します。
迅速な配信: JVM コンテナーとミドルウェア全体を再起動する必要がある通常のアプリケーション公開と比較して、サーバーレス公開の粒度は純粋なビジネスコード次元 (ビジネス機能) で制御でき、究極の公開効率を実現できます。
統合アーキテクチャ:すべての基本機能はサーバーレスベースによって処理されます。そのため、JDK のアップグレード、ミドルウェアのアップグレード、一般的なセカンドパーティパッケージのバージョンのメンテナンスなどは、各企業にアップグレードを強制する必要はなくなりました。それらは、サーバーレスベースによって処理されるだけで済みます。サーバーレスベースによる専任スタッフによる完全なビジネスアップグレード。

サーバーレスアプリケーションの分解

従来のアプリケーションと比較して、サーバーレスアプリケーションは、コグニティブ研究開発システムにとって比較的大きな課題となっています。サーバーレスの全体的な設計と運用システムは、従来のアプリケーションから大きく変更されています。技術研究開発の学生にとって、これを理解することが重要です。原則と考え方が不可欠です。そこで、従来のアプリケーションから始めて、プロセス全体を徐々に分解して、サーバーレスがどのように実装され、運用されるかを簡単に紹介しようとしました。

第 1 層一般的なアプリケーション:

当社の一般的なアプリケーションは、ミドルウェアとビジネス独自の Spring コンテナを含む Pandora コンテナ (分離コンテナ) によってロードされます。

第 2 レベルビジネスロジックの分解

私たちが毎日開発するコードには、ビジネス自体のコードに加えて、商品や人などのサービスのカプセル化や呼び出しなど、多くの一般的なコードロジックも含める必要があります。これらのロジックはほとんどのアプリケーションで使用されますが、このコードはアプリケーションごとに常に書き直されています。

3層目業務コンテナの階層化

業務コードと一般コードを区別することで、業務Springコンテナをさらに一般Springコンテナと業務Springコンテナに分割し、それぞれ異なる業務コンテナのロードと破棄を制御することができる。

4 番目の層。サーバーレス

ビジネス機能と一般的な機能を階層化することで、ベースアプリケーションとビジネスアプリケーションの概念に基づいた独立した製品および導入システムをさらに形成でき、機能、生産研究、運用および保守システムの面で完全に分離および分業することができます。

サーバーレス本番の調査・納品フォーム

サーバーレスがビジネスに与える最大の影響は、サーバーレス基盤の開発と運用保守を担当する専門分業体制と、一般業務を担う本来の生産・研究体制の変革です。開発はマシンコンテナー、JVM、ミドルウェア、その他のサービスに注意を払う必要がなくなり、ビジネス要件の実現と提供に重点を置くことができます。

従来のアプリケーション配信形式: 研究開発は Docker コンテナ全体内のすべてを担当します

サーバーレスの制作と研究の新しい部門: 責任の分割、プロフェッショナルな人々が最もプロフェッショナルな仕事を行う

サーバーレスの新しいアプリケーション配信形態：階層化された独立した配信

サーバーレスの新しい導入エクスペリエンス

機能の階層化と生産と研究の分業に加えて、サーバーレスによってもたらされるもう 1 つの重要な機能は、非常に速い導入速度です。以前は完了するまでに 5 ～ 10 分かかっていたデプロイメントが、サーバーレスを使用すると 1 分未満に短縮され、日々の開発エクスペリエンスが実際に書いたものと得られるものに一歩近づきました。

要了解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技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。