网站开发高级工程师专业建邺区住房 建设 网站

网站开发高级工程师专业,建邺区住房 建设 网站,评测网站做的那些条形图,永久免费erp去年和朋友创业搞社区团购#xff0c;惨淡收场#xff0c;但技术架构沉淀了下来。这套基于SpringCloud Alibaba的微服务方案#xff0c;经历过晚高峰的并发考验#xff0c;今天拿出来复盘一下#xff0c;重点聊聊我们当时如何划分服务#xff0c;以及怎么搞定最头疼的分布…去年和朋友创业搞社区团购惨淡收场但技术架构沉淀了下来。这套基于SpringCloud Alibaba的微服务方案经历过晚高峰的并发考验今天拿出来复盘一下重点聊聊我们当时如何划分服务以及怎么搞定最头疼的分布式事务问题。创业失败了但代码是无辜的。当时我们几个技术合伙人对微服务摩拳擦掌觉得不用微服务都不好意思叫互联网项目。现在看有些设计过度了但也有不少值得坚持的地方。一、微服务怎么拆我们走过的弯路最初我们按标准电商维度拆用户、商品、订单、支付、库存。跑起来就出问题了。社区团购有个核心特征“今日下单明日自提”所有业务都围绕“团”和“提货点”展开。最终我们的服务划分是user-service (用户服务)基础不说了。product-service (商品服务)特别注意商品价格和库存是按“团”维度管理的。同一个苹果A小区团和B小区团价格、库存独立。group-service (核心)这是我们的业务中台管理“开团”、“参团”、“成团”状态以及“提货点”信息。所有其他服务都重度依赖它。order-service (订单服务)生成订单、状态流转。inventory-service (库存服务)最复杂的服务之一。要处理下单预扣、支付后真实扣减、次日未提货自动返还、团长手动核销等一系列操作。我们把它独立出来用RedisLua脚本保证原子性。payment-service (支付服务)对接微信支付成功后发消息。delivery-service (核销/履约服务)处理团长扫码核销。operation-service (运营后台)供内部使用。教训别为了拆而拆。“团”这个强业务概念必须有一个核心服务来承载和协调它就是group-service。二、分布式事务跨服务下单的最终一致性方案用户下单涉及group-service校验团状态、inventory-service扣库存、order-service生成订单。怎么保证要么一起成功要么一起失败我们放弃了Seata的AT模式性能和维护成本考虑采用了“本地消息表最终一致性”这是当时我们小团队最能把握的方案。下单入口order-service在一个本地事务中①生成“待支付”订单②向本地消息表插入一条“扣库存”消息。事务保证这两步原子性。定时任务扫描消息表将消息通过RocketMQ发送出去。inventory-service消费消息执行预扣库存。如果失败比如库存不足则回发一条“扣库存失败”消息。order-service消费“扣库存失败”消息将订单状态改为“无效”。同时我们还有个“兜底对账”的Job每小时跑一次对比订单状态和库存流水对状态不一致的进行补偿或告警。三、高并发场景下的应对晚高峰抢菜核心是读多写少。写扣库存用Redis Lua扛住瞬时压力。读商品详情、团信息全部上Redis缓存。注意团状态是否已成团这种高频变化的数据我们用了Redis Hash 本地缓存Caffeine两级缓存本地缓存设短时间如2秒极大减轻Redis压力。网关用Spring Cloud Gateway做统一限流和熔断特别是对“查询团长今日订单”这类接口。四、复盘与反思如果用现在的眼光看inventory-service和group-service耦合有点紧部分逻辑可以下沉为领域能力。但整体架构经受住了考验。微服务拆分的边界不是技术而是业务能力与变更频率。社区团购的业务变化像风一样快独立的operation-service让我们能快速迭代运营功能而不影响核心交易链路。