/tags/guest-checkout/ Recent content in guest-checkout on Hugo -- gohugo.io en Wed, 08 Apr 2026 10:00:00 +0800 /posts/shop-guest-first-shopping/ Wed, 08 Apr 2026 10:00:00 +0800 /posts/shop-guest-first-shopping/ 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 2026-04 实践更新 当前主线代码里，游客购物车已经从 StringRedisTemplate 统一切到 RedissonClient 的 RBucket<String>，但仍然保留“JSON 可读 + TTL 续期”的设计。下面示例已按当前实现同步。 在电商平台中，注册/登录常常是转化链路里的明显阻力之一。Baymard 长期跟踪 checkout 可用性时，也一直把“被迫注册账号”列为常见流失原因之一。Baymard Institute, Cart Abandonment Rate Shop Platform 目前已经在 buyer-portal 这条链路上初步支持 Guest-First（游客优先）：用户可以不注册先创建游客订单、保存 order_token 并回查状态。需要补充说明的是，KMP buyer-app 目前仍要求登录后再触发结账，所以这里更接近“逐步 guest-first”，而不是所有前端入口都已经完全等价。 整体流程 flowchart TD Visit["访问网站"] Browse["浏览商品"] AddCart["加入购物车"] Checkout["结账"] Pay{"支付"} Guest["auth-server 签发 guest JWT"] RedisCart["Redis 购物车TTL 48 小时"] GuestOrder["创建 GUEST 订单带 order_token"] Track["通过 order_token 追踪订单"] Login["注册/登录"] Merge["购物车合并Redis → DB"] SignedIn["登录态购物车"] Visit --> Browse --> AddCart --> Checkout --> Pay Pay -->|" /posts/shop-platform-bff-aggregation/ Thu, 02 Apr 2026 10:00:00 +0800 /posts/shop-platform-bff-aggregation/ 在上一篇中，我们看了 API Gateway 如何作为统一入口处理 JWT 校验和路由分发。请求经过 Gateway 后，到达的就是本文的主角——BFF（Backend for Frontend）聚合层。 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 上一篇：（二）API Gateway 架构 2026-04 实践更新 当前主线代码里，buyer-bff / seller-bff 都已经完成了 typed @HttpExchange 客户端改造；BuyerAggregationService / SellerAggregationService 不再直接持有一堆 raw RestClient 调用链，而是通过 HttpServiceProxyFactory 注入声明式客户端。本文下面与客户端装配相关的表述已按当前实现校正。 BFF 模式：为什么需要聚合层 在微服务架构中，前端页面往往需要从多个领域服务获取数据。如果没有 BFF，前端直接调用每个领域服务会面临： 前端 ←→ profile-service (获取用户档案) ←→ wallet-service (获取钱包余额) ←→ promotion-service (获取可用优惠) ←→ marketplace-service (获取推荐商品) ←→ loyalty-service (获取积分账户) 问题显而易见：前端需要知道每个服务的地址、认证方式、数据格式；任何服务变动都会影响前端代码；更重要的是，前端暴露了内部服务拓扑，安全和治理成本都会明显上升。 graph LR FE1["前端"] P["profile-service"] W["wallet-service"] PM["promotion-service"] M["marketplace-service"] L["loyalty-service"] FE1 -.-> P FE1 -.-> W FE1 -.-> PM FE1 -.