秒杀开发历程（二）
source link: http://servicecomb.apache.org/cn/docs/seckill-development-journey-part-II/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
上文 中我们构建了一个仅具有核心功能的秒杀框架，本篇中我们会逐步完善一些功能，使得它具备完整的基础功能。
问题点（完善范围）
回顾设计和参照已完成的部分，我们可以发现：
- 没有提供Promotion实体的服务（Promotion是固定通过Spring注入的）；
- 缺乏一些基本的业务检查和功能，包括：
- 同一个客户在同一个Promotion中只能秒杀一次（不允许重复）
- 同时可以有多个Promotion进行（折扣不同，数量也不同）
- 如果Command微服务故障，再次恢复后，需要恢复未完成正在进行中的秒杀活动。
也许您会说，客户管理和客户登录为什么没有罗列出来？的确，客户在我们的场景中是不可或缺的，但是我们为了简化设计，没有包含登录以及请求认证的内容，如果对这方面感兴趣您可以移步到ServiceComb的Company示例实现了一个简单基于token的认证方式，地址在Company。
对于实体，领域驱动设计（DDD）推荐使用独立接口，因此我们设计一个新的Admin微服务来提供服务：
Admin微服务的实现
Admin微服务紧紧围绕Promotion实体提供服务，我们完全可以映射到对应的REST方式，即：
- 新增Promotion对应Post；
- 修改Promotion对应Put；
- 查询Promotion对应Get；
- 删除Promotion对应Delete。
满足当前的需求只需要完成Post和Put就可以了，另外，考虑到已经开始的秒杀活动不应该能修改，我们增加了对应的检查逻辑。
检查和功能的实现
通过增加一个HashSet检查客户是否重复秒杀成功；
构建SecKillPromotionBootstrap作为Promotion启动的管理器用于支持多个Promotion同时进行，将SecKillCommandService和SecKillPersistentRunner使用集合管理。
Command微服务故障恢复的实现
构建SecKillRecoveryService处理Promotion恢复检查，未完成的Promotion无论是未开始的还是进行中的，都需要它完成检查返回正确的恢复信息，信息包括剩余券数、已秒杀成功的客户列表等。
最后，我们使用PostMan体验完成的功能，请注意Body的填写使用JSON格式，并且类型选择JSON(application/json)：
创建秒杀活动
查询正在进行的秒杀活动
拒绝重复秒杀
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK