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