产品背景
image.png
回到 2013 年，那时候淘宝开发平台招开发商，给商家做软件产品。
偶然机会，我做了一个大转盘抽奖的产品放到淘宝服务市场给商家用，不到 2 天，就有很多用户来咨询，我感受到了一丝兴奋，于是快马加鞭的迭代开发，也有很多朋友的帮助，每天编程到午夜 2 点。随之而来的大量用户，我确定了方向，电商平台需要有个性化的营销工具，抽奖就是最简单最清晰的首选工具。
一周后我的新产品抽奖靠手上线了，主要提供帮助商家设置抽奖营销，商家可以服务他们的用户。在 2013 年双 11，通过这个小产品，我挣到了 6 万元。
产品迭代实践
Logo 的变化
大家可以从我们 Logo 变化看出什么嘛！
早期的 LOGO
image.png
现在的 LOGO
image.png
产品版本迭代
2012 年，早期版本 V1.0，不想说什么！现在来看，一个字很菜！
image.png
2013 年，只是电脑端，可配置抽奖背景，布局，奖品，规则，只有大转盘游戏。在那个淘宝商家蛮荒的时代，商家对我们工具是爱不释手，玩的不亦乐乎，甚至带火了一些商家。
（我也应该去卖货，呜呜）
image.png
2014 年，抽奖规则和奖品玩法更丰富，DIY 背景更多样，逐步增加手机端抽奖。
image.png
image.png
2015 年，订购人数到几千人的规模。注重迭代规则种类，奖品种类，游戏多样化。
image.png
2016 年，电脑，手机端标准游戏和模板的扩充，如大转盘，九宫格，砸金蛋，老虎机等等。
image.png
2017 年，抽奖整体布局可以拖拽化，定制功能更强大，手机端抽奖已成为核心。
image.png
2018 年，京东，口碑等平台扩展。
2019 年，产品 UI 体验整体更新，创建抽奖活动从模板角度出发。
image.png
2020 年，淘宝手机 APP 第三方 H5 页面统一升级为小程序。
image.png
image.png
2021 年，商家 PC 千牛端改造，千牛后台类似电脑端小程序。
image.png
2022 年，风云变幻，品牌定制多样化。
image.png
2023-2024 年，淘宝服务市场不在辉煌
直播，短视频内容营销才是商家的重点。
拼多多的玩法更加犀利，淘宝，京东也再转型，让商家操作更简单，让消费者更实惠的买东西。
所以商家服务市场上的工具慢慢减退，我们这种抽奖营销弱需求产品慢慢退出市场，还有一些打单，生产等强需求的也只有淘宝还能生存。
淘宝平台自研的产品变多，尤其是 AIGC 相关。
未来，期望我们的产品还能坚持下来，期望还能研发出更优秀的产品。
技术选型实践
image.png
开发语言实践
2013 年时候，我们从最早.net 平台 c# 开发，因为我之前是做这方面的程序员。
2016 年左右，后来逐步迭代了 PHP 后台，前端采用原生 JavaScript 的模式。
大概这个时候是
2019 年左右，后来迭代成了 PHP 逻辑端，消费者前端采用了淘宝小程序；商家后端和管理员端采用了 VUE 的技术。
2023 年左右，目前逻辑层和后端代码还是采用 PHP 的 thinkphp 框架。前端没有变化。
image.png
数据库实践
数据库方面，早期是 SQL Server 到后来的 MYSQL 和 Redis 的模式。
过程中想换过 MongoDB，但是一方面从商业营收来看，还有开发资源来看，成本比较高，就放弃了，其实这种抽奖类 Node.js + MongoDB 的开发组合是最适合的。大并发是必须的。后面讲采用 MySql 和 Redis 怎样来解决大并发问题。
上面的技术产品，都采用的是阿里云的商家聚石塔的产品。ECS，RDS，Redis，OSS 等。
架构设计实践
架构演变
架构上从早期的 2 层。.net asp.net 页面逻辑+数据库的模式。
后来逐步变成了 PHP 逻辑层 API 模式，前端 VUE，小程序，MySql，云函数等多层组合。
image.png
现在的架构图
image.png
因为前些年淘宝生态发展很繁荣，很多电商平台也都在学习解决，比如京东也再发展自己的生态商家平台，我们当然也直接入驻了。下面是我们针对京东商家平台做的架构设计，大家可以参考了解，欢迎一起交流学习。
其他平台架构图
image.png
产品前端实践
历经迭代，我们产品目前前端技术主要采用手淘小程序的消费者端，千牛小程序的商家电脑活动配置端，VUE 开发的 Web 管理员端。
image.png
手淘小程序
下图为开发手淘小程序的 IDE 工具，左侧是目录，右侧是预览器，中间是代码区，跟微信等小程序开发的 IDE 工具都相似，不多赘述。
image.png
重点讲解下我们组件式设计的模式，其实这里的设计跟 React，VUE 等语言一些思维模式相同，都是强调组件式，通过组件组合成大控件，或者大页面呈现，方便业务需求的使用。
image.png
在 components 中，包含了 base 基础组件如 image,title 等，也有游戏类型的组件，可以看到我们有多种游戏和互动模式，甚至还开发了基于白鹭引擎的高级游戏效果。通过这些互动组件，商家用户可以通过拖拽简单配置，组合成他们需要的店铺营销工具，比如游戏抽奖，关注领券，拉人领奖等等。
用一个砸金蛋的游戏来详细看下代码。下图是砸金蛋的商家配置页面。
image.png
砸金蛋代码 axml 代码如下。
image.png
js 代码如下，因为代码篇幅较长，只做部分代码截图粘贴，代码逻辑也很简单 ，包括了游戏效果和后台抽奖 API 做信息交互。
image.png
我们再看下页面调用这个砸金蛋游戏组件的详细代码。其中结合了一些公共互动的奖品展示组件，其他游戏和互动模板都是类似的形式。看到这里，有的朋友觉得其实也没有什么太高明的创新和创意吧，我们这里重点是给大家展示在淘宝京东这种电商平台上的 SaaS 工具怎样运作的方式，包括一些电商业务的小程序的操作形式。
image.png
utils 中放置了游戏的 js 执行效果代码。这些代码其实很常见，感兴趣的可以网上搜下，一堆一堆的实现效果。
image.png
最后再看下开发淘宝小程序怎样调用官方 SDK 的接口。其中的 my.authorize 就是用户授权的接口，授权后我们可以拿到手淘用户的唯一 ID 等信息，就可以继续后面的操作了。
总结一下，我们通过详解一个砸金蛋的游戏，明白了淘宝小程序的实现过程，了解了我们产品的整体前端实现逻辑，核心点就是游戏组件化，模板组件化。同时也学习到了在淘宝小程序中怎样获取用户授权信息，怎样调用发券的权益接口。
千牛小程序
上面介绍了手淘用户参与抽奖的开发过程和代码详细，接下来我们快速看下淘宝商家使用的页面和千牛小程序的代码。
这个是商家使用的正式后台页面。图中展示了商家配置活动的奖品明细。
image.png
下面是开发的 IDE 工具，和手淘小程序开发是同一个 IDE 工具，但是在开始选择类别时候一定要选对。
image.png
我们选择 PC 小程序项目中第一个小程序 PC 版，然后创建项目即可，这里我选择了我们创建过得项目。主面板如下，左侧代码目录就是千牛小程序代码，我们没有过多使用组件功能，直接用页面形式做开发。
image.png
千牛小程序在 IDE 中的预览如下，可以自己定义展示分辨率等场景信息，便于快速开发。
image.png
因为代码和项目比较庞大，我们这里简单让大家理解下产品的结构，了解下千牛小程序的开发形式，具体开发语言都是类似小程序的语法，不同平台只是个别地方或者接口有些不同。
VUE 管理员端
简单看下管理员页面，代码就不在这里展示了。包括一些活动管理，管理员配置的功能。
image.png
成本优化实践
再展示一些目前云计算的产品场景图，便于大家更好的理解。
云产品技术升级带来的成本优化
这里云计算给我们的成本优化帮助很大。比如从原始的 ECS，到后来的云函数/Serverless 的模式，从原来的 RDS，到后来的云数据库的模式。
云产品订购升级带来的成本优化
从早期我们年购 ECS，RDS，到后来根据不同云产品，进行分期购买，到后来的按量购买。最典型的就是双 11 压力大的时候我们要采买多台，这个时候只需要购买 1 个月即可。包括到现在后期产品使用量变小了，我们变成的按流量购买的形式，这些都是对我们在产品成本上的优化。
下面一些图是淘宝聚石塔提供给我们的 CI/CD 工具，展示了我们针对不同场景的调整，可以做到快速一键切换。
image.png
下图是淘宝聚石塔提供的 Devs 工具，便于产品发布程序包，环境管理，监控。
image.png
淘宝开放平台提供的 Serverless 功能，可以直接云函数部署，不用关心太多服务器的问题。
image.png
云数据库也提供了 MongoDB 和 MYSQL，因为安全问题目前功能性比较简单，适合一些简单的互动小应用。
image.png
总结一下，我们从技术演变可以了解到互联网的技术迭代；从架构设计中我们了解到做一个小产品其实也不是很简单，需要长期对技术和业务的了解；从前端技术中了解到，国内流行平台从普通的 JavaScript 技术，逐步发展到自己 APP 下的小程序，小程序具有更好的体验，更安全。最后，从高并发解决上也看到了云计算发展给我们带来的好处，人工需要的越来越少，硬件成本费用也越来越低，可以让创业者，开发者更专注到业务场景中。
问题解决实践
高并发问题的解决
image.png
讲下高并发的问题，因为其实抽奖，裂变这种互动应用，高 QPS，高并发是一个常见的问题，也是一个棘手的问题，很多新手容易抓瞎，在 2013 年那个时候我们就因为突然的大规模流量导致频繁宕机，淘宝的流量不是盖的。但是在早期，这些高并发都需要自己去解决，伴随着互联网云计算的发展，现在的技术朋友轻松很多，用容器负载技术，Serverless 技术就能轻松解决并发问题，而且费用还便宜，1 个人就能搞定全部。
我们的高并发大概经历的过程是这样的：
● 分表分库，优化 Web Server。我们从早期 SQL Server 迁移到开源 MySQL 中。比如把商家 ID 做分成，根据业务逻辑拆分不同商家编号，不同层次的放入不同的表中，每个表的数据量控制在 15 万条以内。
● 增加 ECS 做负载均衡，加入 Redis，加入队列等。Redis 这里解决了我们很大的问题，比如加载商家抽奖布局和消费者基础信息的，不用直接读 MySQL，先去判断 Redis。
● 使用容器技术，包括轻容器 Docker，到资源池，K8 容器，SLB 等云资源编排。容器方面我们最多扩展到 10 个做负责均衡的处理，这里就是要利用用 CI/CD 的功能，做好灰色发布，分层发布的模式。
● 使用 Serverless 技术，包括云函数，云数据库。其中我们用云函数分布了一些并发量大的功能点，做 API 的处理模式。
未来我们将继续迭代，包括开发运维采用 GitOps 等等。有没有觉得透过这么小的产品迭代，也能清晰看到互联网技术的不断演进。我猜测未来类似我们这种小产品，将会更容易开发和迭代，也许 1 个人从产品开发到部署运维，可以轻松全部搞定。
消费者抽奖问题的快速解决
image.png
● 发送原因
这个问题通常是在消费者进行抽奖后，无非抽取，或者没有中奖等等问题。
但是这里会存在很多原因，我们怎么更好的去排查，比如可能是我们代码问题，可能是淘宝 API 的问题，可能是消费者操作的问题，还可能是商家配置规则的问题等等。
● 曾经解决方式
最开始我们采用原始的测试环节打断点，还有正式环节打日志的方式去排查，但是这种效率低，有时候会影响正式环节运行，还有通常需要消费者和商家高效配合，综合效率很差。
● 最终解决方式
后来我们采用了分业务模块的日志跟踪系统，比如我们在不同的常见原因做单独的日志跟踪模块设计，然后把它分布在对应常发生的业务点上，这样我们管理员可以后台实施跟踪和监控，
很好的解决了实时抽奖的问题排查。
业务开源实践
这里我把我们抽奖规则中经过多次迭代的抽奖规则开源化，做抽奖产品的朋友可以借鉴。
奖品设置里的指定规则解释
场景举例描述
奖品设置有：
一等奖（中奖率 50%），没有设置指定规则；
二等奖（中奖率 20%），设置指定规则（交易额规则 20%，签到规则 30%）；
三等奖（中奖率 20%），没有设置指定规则
1、二等奖不勾选独立计算此奖品规则
小红使用指定的规则：交易额规则，去抽奖，小红的中奖率是
50%+20%*20%+20%=74%
一等奖中奖率 +二等奖中奖率+三等奖中奖率=本次抽奖中奖率
image.png
小红使用指定的规则：签到规则，去抽奖，小红的中奖率是
50%+20%*30%+20%=76%
一等奖中奖率 +二等奖中奖率+三等奖中奖率=本次抽奖中奖率
小红使用不指定规则去抽奖：无门槛抽奖，小红的中奖率是
50%+0%+20%=70%
一等奖中奖率+二等奖中奖率+三等奖中奖率=本次抽奖中奖率
image.png
2、二等奖勾选了独立计算此奖品规则，
小红使用指定的规则：交易额规则去抽奖，（按奖品的设置顺序进行判断）
image.png
小红使用指定的规则：签到规则去抽奖，小红的中奖率是
image.png
小红使用未指定的规则：无门槛规则去抽奖，小红的中奖率是
image.png
产品思考
image.jpeg
一个小小的产品，它的发展会见证很多变革，有行业的，有技术的，但是当你回顾过去，更多印象的反而是一群奋斗的人。
每个人的工作有高峰底估，每个产品也是一样，但是只要你具有信念，坚持不懈，持续迭代，就算不是 ChatGPT 这种划时代产品，一个小而美的小产品也是很赞的，重要的是持续帮助服务一撮人。
