Serverless AI训练营：课时1：Serverless 解构在线游戏行业痛点（三）
课时1：Serverless 解构在线游戏行业痛点（三）
结合第二个案例，实际上是关于一项策略，用于推动运营升级。对于这个客户而言，这款游戏似乎刚刚发布。
为了推广它，需要进行大规模广告投放，例如，像我们的客户目前在抖音、快手等短视频和其他互联网平台上的广告投放。
由于这款游戏刚刚上线，很难准确预测流量情况。广告投入的时间可能只有一周或半个月。
虽然营销业务在短期内有一些成果，但由于不清楚何时以及哪些用户会触及广告，流量情况仍然不太明确。
尽管广告投放成本高昂，但每次触发广告后，我们希望进入数据库进行网站分析。然而，这个系统本身非常短暂，且需要大量的计算资源来处理。
我们还需要确保系统的可用性，以及数据的完整性。因此，我们需要找出用户需求，特别是开发时间有限的情况下。
我们可以考虑以下架构方案：首先，执行行数计算，通过一个应用程序将信息传递到抖音或快手等平台，触发一个函数。
在这一刻，处理器使用可能很高，特别是在用户活跃的时间段。如果直接写入数据库，可能会给数据库带来巨大压力。
我们可以使用消息队列来削峰填谷，首先，将信息写入消息队列，然后批量处理，将多个消息合并为一个大型消息。然后，异步触发另一个函数，用于将数据写入数据库。
举个例子，假设在上述第一个函数中，我们进行了一次压力测试，同时处理12万个事务。如果直接写入数据库，将对数据库施加巨大压力，但通过Kafka消息队列，我们成功将其处理成了大约25k的消息。
我们可以以一个例子来说明这个流程：当我们批量处理五次时，我们可以将它们合并，从而平滑了处理速率（qps），减轻了对数据库的压力，实现了削峰填谷。最终，数据成功写入数据库，保护了下游系统免受大流量的影响。因此，前端系统需要处理大流量，同时确保不会出现故障。
介绍一下用户采用的方法，他只编写了两个函数。由于这些函数之间的触发流程已经打通，所以他很快就完成了开发和压力测试。
第一次事件启动后，他写了两个函数，一个用于发送消息，另一个用于消费消息。他不需要维护消息队列，也不需要担心生产者和消费者的问题。这节省了时间和精力。
第二次事件启动时，我们看到他的系统具有弹性、高可用性和削峰填谷的能力。这次开发只花费了一天的时间，尽管原本的业务可能需要七天或一周的时间。
但由于这个业务非常重要，因为涉及到大量资金投入，所以这个解决方案完美地解决了他的问题，同时实现了他的目标。
五、实现安卓游戏APK包按渠道分发
让我们再讨论第三个案例：
在讲架构演进时，我们提到了第一个架构，即静态网站架构。在架构演进的过程中，我们最终引入了对象存储和CDN以实现静态网站内容的展示，并对这个架构进行了扩展，使CDN可以回源到计算服务，以实现更多独特的功能。
我们将详细讨论一个常见的情景，即分发应用程序，例如游戏的安卓包。开始，我们只需将母包放入对象存储中。对于我们的客户，他们是小米用户，当他们通过小米应用或其他应用访问时，他们会携带一个参数，例如"uc商店"。
CDN会提取这个参数，如果CDN已经缓存，它将直接返回包。如果CDN中没有缓存，它将直接回源到计算服务，进行一些处理，或者执行其他任务。
用户需要的是一个优化的包，因此我们从内部获取原始的母包，并在处理后将其返回，同时在渠道信息中写入相应的渠道信息。这是因为对于不同渠道，它们可能具有不同的特征，需要在包中添加相应的信息。
母包被拉取并在计算服务中进行处理，最后返回到CDN，其他用户再次访问时，CDN就能够提供缓存的包了。
需要注意的是这个流程中没有涉及到服务器的概念，对于用户而言，他们只需要做两件事情：将版本迭代后的游戏包放入对象存储中，以及编写一个用于处理包的函数。
这个架构具有高度的弹性和可用性，即使有大量用户同时下载，也不会有太大的问题，对于企业来说，用户的下载体验也非常良好。
因此，我们可以看到，CDN回源到计算场景、ES或自建服务、容器服务都没有问题，但直接打通CDN回到计算服务时，就不再涉及服务器的概念了。
不管你使用ECS还是容器服务，你都不需要管理计算资源，因为CDN直接回源到计算服务。此外，这也对流量费用进行了优化，因为回源到其他云产品时，流量费用与之前的流量费用是一致的。
在这个案例中，通过云产品之间的相互打通，我们实现了编程模式的简化，并释放了一些技术上的不同力量，特别是在流量优化方面。
让我们继续研究第四个案例：
在第四个案例中，我们面对的是昨天提到的一个复杂架构，即订单处理系统。当时这个订单处理系统涉及很多方面，其中一些在雷老师的反馈中可能不太容易理解。今天，我们将重新讲述这个案例，并结合另一个实例来解释这个概念。接下来，我们还会演示一个示例以更清晰地说明题干。首先，让我们来看看这个场景：游戏厂商经过艰苦的努力终于完成了游戏的开发。现在，他们需要将游戏推向市场，进入发行阶段。
六、实现快速多渠道游戏打包
我们面对的是昨天提到的一个复杂的架构，即订单处理系统。当时这个订单处理系统涉及多个方面，其中一些在雷老师的反馈中可能较难理解。
以另一个案例来解释这个概念。接下来，我们还将演示一个示例以更清晰地说明题干。首先，让我们来看看这个场景：游戏开发商经过辛勤努力终于完成了游戏的开发。现在，他们需要将游戏推向市场，进行发布。
发布后，他们可能会面临一个问题，即如何为各个渠道创建定制的渠道包。这是因为不同渠道可能需要不同的配置，可能会使用其自己的SDK等。
