做电商项目这些年潮服购物这种偏年轻化、重调性的场景其实比标准B2C商城更有意思。用户画像清晰、上新节奏快、限量发售和社区种草玩法多业务上天然需要一套反应快的系统而不是传统一柱擎天的单体应用。所以当时拿到SpringBootVueSpringCloud微服务分布式的潮服购物服装商城系统这个题目时脑子里第一反应就是技术栈几乎不用纠结SpringBoot Vue SpringCloud这套组合在国内电商、产业互联网领域太成熟了剩下的核心工作在于——如何把微服务分布式从概念变成真正能抗住业务压力的系统。这篇博文就完整复盘一下这个系统的设计思路、技术选型、核心实现和踩坑记录适合正在做毕业设计、或者准备把单体商城改成微服务架构的同学参考也适合面试前想系统梳理SpringCloud分布式知识的人。1. 系统整体设计与架构选型思路1.1 潮服商城业务场景与核心需求拆解潮服商城和普通服饰电商最大的区别在于上新节奏和库存策略。普通商城是海量SKU常驻潮服更接近每周限量发售、售完即止加上尺码、版型、联名款式这些强个性化属性用户对商品详情、穿搭推荐、社区评测的关注度极高。从实际业务拆解来看核心模块大概有这么几个用户中心注册登录、会员等级、收货地址、商品中心类目、SPU/SKU、尺码库存、上下架、购物车与订单中心加购、下单、支付、状态流转、库存中心预占、扣减、回滚、营销中心优惠券、秒杀、限时购、社区内容穿搭分享、评价、后台管理商品管理、订单管理、数据统计、搜索推荐商品检索、热门推荐。这套模块如果全塞进一个SpringBoot单体里前三个月开发确实快但到后期必然出问题商品秒杀和普通查询互相拖累、订单状态机耦合在业务代码里、每次发布都要整个服务重启、团队多人协作天天冲突。所以拆分微服务不是赶时髦是业务复杂度到了一定程度后的必然选择。1.2 技术选型为什么是SpringBootVueSpringCloud这套组合SpringBoot解决的是服务怎么写的问题。微服务架构下每个服务都是一个独立可运行的SpringBoot应用它的自动装配、内嵌Tomcat、Actuator监控让开发者把精力集中在业务代码上而不是反复搭环境。实际项目中我一般用2.7.x版本稳定且和SpringCloud版本配套清晰不建议一上来就追最高的3.x后面会讲到版本坑。SpringCloud解决的是服务之间怎么协作的问题。它不是一个框架而是一套微服务治理全家桶Nacos做注册中心和配置中心、Gateway做统一网关、OpenFeign做声明式服务调用、Sentinel做流量控制和熔断降级、Seata处理分布式事务。这些组件覆盖了服务怎么发现、请求怎么路由、故障怎么隔离、数据怎么一致四个核心问题比自己去造轮子可靠太多。Vue解决的是用户端体验怎么做的问题。商城前端页面交互密集购物车、筛选器、商品详情、订单流程都需要实时反馈。Vue3的组合式API配合Element Plus组件库开发效率很高而且前后端分离后前端团队和后端团队可以并行开发联调时用Mock数据或者直接代理到网关即可。之所以不用PHP单体、不用Dubbo直连、不用Next.js全栈核心原因就一句话这套业务需要清晰的模块边界、独立的伸缩能力和团队并行开发的自由度而SpringBootVueSpringCloud是目前综合成本最低、人才最好找、生态最完整的组合。用生活点的类比单体应用就像一家小店老板收银、炒菜、端盘一肩挑生意大了必然乱微服务就像连锁店后厨、前台、采购分开管各自独立又协同。1.3 微服务拆分逻辑与模块边界划分微服务拆分最怕的是为了拆而拆。我当时定的拆分原则是按业务域拆、按伸缩需求拆、按团队边界拆三者取交集。商品、订单、用户、库存天然隶属于不同的业务域每个域的数据独立性也强所以直接拆成独立的服务共用数据库严禁服务之间只通过接口通信绝不共享表。具体到落地我分了这几个服务tide-user-service用户、会员、地址、积分tide-goods-service商品、类目、SKU、属性、评价tide-order-service购物车、订单、订单状态机、售后tide-stock-service库存预占、扣减、释放tide-marketing-service优惠券、秒杀活动、限时购tide-search-service基于Elasticsearch的商品搜索与推荐tide-gateway统一入口、鉴权、路由、限流tide-auth-service认证、登录、JWT签发这里有个关键思考购物车为什么放在订单服务里因为购物车的生命周期和订单强相关加购、结算、删除这一串动作最终目的就是生成订单拆开反而要多一次远程调用、多一次数据一致性风险。库存单独拆的原因是秒杀场景下库存操作极其频繁必须能独立扩容和加分布式锁放在商品服务里会把商品查询拖垮。每个服务持有自己的数据库模式一般一个服务一个库或一套库中的独立schema库之间零外键关联。这带来一个直接问题跨服务的数据查询怎么做比如我的订单列表需要商品名称和图片、需要用户信息解决方案不是去查别的库而是在订单表冗余商品快照名称、图片、单价订单服务自己就能出列表页商品信息变了也不影响历史订单展示。这个冗余思路贯穿整个系统设计是微服务落地最实用的经验之一。2. 核心技术模块与实现细节2.1 用户认证与网关统一鉴权JWT Spring Security登录认证在微服务架构下不能像单体那样用Session粘滞节点因为请求经过网关后可能负载到任意一个用户服务实例Session在A实例、下次请求落到B实例就丢了。所以选择了无状态的JWT方案用户登录后认证服务校验用户名密码签发一个包含用户ID、角色、过期时间的JWT令牌后续所有请求在Header里携带这个令牌网关统一校验。认证链路是这样设计的用户访问任意业务接口 - Gateway的GlobalFilter拦截请求 - 从Header取出Token - 通过JWT密钥解析校验 - 校验通过后把用户ID放到Header中向下游服务传递 - 下游服务直接从Header里取用户上下文。这样设计的好处是业务服务无需重复写解析逻辑所有服务都共用一个UserContext工具类从RequestContext里拿用户ID即可。Token刷新机制这里容易踩坑。JWT一旦签发在过期前是没法主动失效的强行让用户重新登录体验又差。我的做法是存储层加一层Redis黑名单用户主动退出或修改密码时把Token的唯一标识jti加进黑名单设置有效期为Token剩余过期时间网关每次校验时除了解析JWT本身还要查一下黑名单是否包含这个jti。这样既保留了JWT的无状态优势又能处理强制下线场景。Spring Security的使用上不建议在网关里引入完整的安全过滤器链太重了。网关只做轻量校验解析、查黑名单、时间校验真正的权限控制放到业务服务内。例如后台管理接口要求管理员角色在Controller方法上用PreAuthorize(hasRole(ADMIN))注解配合方法级安全配置即可。2.2 商品中心与搜索设计缓存策略与ES全文检索商品中心是整个商城的门面它的数据特点就是读多写极少——一个商品的详情、图片、销量、评价在一天内可能被看千次但真正修改只有运营上下架或者改价格的时候。因此缓存策略是商品服务的核心优化点。我用的是两级缓存本地Caffeine缓存 Redis缓存。商品详情接口先查Caffeine每个商品服务实例都有一份本地缓存没命中再查RedisRedis没有才查询数据库。Caffeine的过期时间设为60秒Redis设为30分钟商品发布或修改时通过Spring Cloud Stream发一个缓存失效的事件各个实例监听到后主动淘汰本地缓存。这样做的实测效果是商品详情接口的QPS从几千提升到几万数据库基本没有压力。缓存场景逃不开三个经典问题穿透、击穿、雪崩。穿透是查了一个不存在的商品ID绕过缓存直击数据库解决方式是接口入口做参数校验对不存在的ID也缓存一个空值比如NULL对象缓存5分钟或者用布隆过滤器做快速判空。击穿是某个热点商品的缓存刚好过期大量请求同时打到数据库解决方式是对商品详情查询加互斥锁保证同一时刻只有一个线程去查数据库其他线程等待后还是从缓存拿数据。雪崩是大批量key同时失效解决方式就是过期时间加随机值不要让所有商品细节在同一秒内过期。商品搜索这一块直接接入了Elasticsearch商品服务在商品上下架、价格变更时同步数据到ES搜索服务通过RestHighLevelClient执行查询。ES的索引设计里商品名称用IK分词器做中文分词类目、品牌、风格、标签用keyword类型做精确过滤价格、销量用数值类型做排序。搜索接口支持关键词高亮、多字段聚合、分页查询首页的热门推荐上新精选就是调搜索服务聚合出来的。2.3 订单、库存与分布式事务从秒杀场景说起潮服商城最刺激的场景就是限量发售。商品上架时间一到几千人同时点击购买库存可能只有一百件。这时候扣减库存的并发控制就是系统的生死线。我用的方案是Redis分布式锁 库存预扣两步走用户点下单时首先要生成一个分布式锁锁的key设计为stock:lock:{skuId}用Redisson框架获取锁Redisson内部实现了可重入锁和看门狗续期机制默认leaseTime 30秒看门狗每10秒续期一次避免锁在业务执行中途过期被其他线程抢到造成超卖。拿到锁后检查Redis中的库存预占数量如果够就在Redis里扣减一个占用名额然后释放锁异步发送MQ消息创建订单。这个方案在秒杀场景下的优势是锁只存在于Redis不会阻塞数据库扣库存动作是纯内存操作毫秒级完成。如果有人支付成功数据库库存表真正扣减Redis里的预占名额转为实质扣减如果超时未支付订单关闭MQ消息触发预占名额释放Redis里的库存自动加回来。这套预占-确认-释放的流程本质上是把库存这一最关键的资源从数据库层面解耦到了Redis层面数据库只在最终确认时落一次。那订单、库存、营销核销优惠券这三个服务的数据一致性怎么保证我用了Seata的AT模式处理强一致场景。AT模式对业务代码侵入性很低业务SQL照常写Seata通过解析SQL自动生成undolog在事务提交前记录数据快照出现异常时自动回滚。对一般的创建订单扣减库存核销优惠券这种T1级别的事务AT模式完全够用不用手写TCC那种复杂的Confirm/Cancel逻辑。但AT模式性能有限因为事务期间会持有全局锁。高并发的秒杀下单就不适合全程用AT我的做法是秒杀链路走异步最终一致性通过本地消息表 RocketMQ实现。订单服务在本地事务里创建一条订单记录和一条消息记录一起提交消息表的内容通过定时任务扫出未发送的消息投递到MQ库存服务消费MQ消息执行库存扣减如果失败则消息进入重试队列超过重试次数进入死信队列人工介入。这套机制比AT模式更适合高并发场景日志、对账、补偿都清清楚楚。2.4 图片视频资源管理MinIO接入SpringBoot与Vue播放方案潮服商品详情页离不开图片和视频。常规方案是存云厂商的对象存储但很多项目会有私有化部署的需求所以我在这个系统里选了MinIO部署在私有服务器上S3协议完全兼容将来想切云随时可以切。SpringBoot接入MinIO很简单引入minio依赖配置endpoint、accessKey、secretKey封装一个MinioStorageService提供上传、下载、生成预签名URL等方法。需要注意的一点上传商品图片时不能直接把文件流存到业务服务器本地正确姿势是前端直传MinIO或者后端接收文件后流式转存MinIO存储和服务器的存储解耦大视频文件才不会把应用服务器的磁盘打满。上传完成后MinIO返回的对象路径比如goods/2024/10/12/shoe-01.jpg存到商品表里访问时通过预签名URL或者桶策略公共读。预签名URL的好处是可以设置过期时间适合私密资源商品图是公开资源直接配置桶为公共读配合Nginx反向代理MinIO的9000端口域名后面加/minio前缀这样静态资源请求根本不会到后端服务压力全部被Nginx分流了。商品短视频方面直接上传MP4也可以但为了稳定播放实现我沿用了视频切片方案用FFmpeg把视频转成HLS格式m3u8 ts分片文件存储到MinIO的/video/目录下。这样做的原因是长视频流式加载体验更好支持拖动进度条网络差的时候也能流畅播。Vue前端播放m3u8时如果不装额外的播放器直接用原生HTML5的video标签是没法播放的需要引入hls.js库按需加载HLS流转换逻辑Safari以外的浏览器也能稳定播放。2.5 Vue前端设计与联调细节前端侧我用的Vue3 Vite Pinia Vue Router Element Plus。工程结构上按模块拆分了views目录商品列表、商品详情、购物车、订单结算、个人中心、后台管理每个模块独立路由。这里有一个和传统管理后台很不一样的点商城的路由需要根据用户的登录状态和角色动态生成。普通用户看到的是购买、订单、社区管理员登录后台后需要看到商品管理、订单管理、数据看板。所以我用了Vue Router的动态路由功能用户登录后前端根据用户角色动态添加路由表而不是在静态路由里写死全量菜单。跨域问题在开发阶段是必经的坑。前端调试时请求http://localhost:8080/api/user/info后端网关在http://localhost:8081直接请求必然跨域报错。我的解决方式分两层开发环境使用Vite的server.proxy配置把/api前缀代理到网关地址生产环境用Nginx统一配置反向代理前端请求同源后端Gateway再做二次转发。只要代理配置正确前端代码里根本不需要关心后端域名。前后端联调还有一个痛点契约管理。我引入了OpenAPI后端写好接口后生成Swagger文档前端从Swagger UI拿到接口定义直接生成TypeScript类型定义这样字段名不一致的问题大幅减少。后端接口的返回结构也统一包装为ResultTcode、message、data前端在Axios拦截器里统一处理错误码不用每个页面都写一遍错误的弹出提示。3. 实操搭建过程与核心环节实现3.1 环境准备与工程骨架初始化开始动手之前先把环境清单列清楚JDK 8我用的JDK 17、Maven 3.8、Node 16、MySQL 8.0、Redis 6我用的7.x、Nacos 2.2、MinIO私有服务器。这里特别要强调版本兼容SpringBoot和SpringCloud的版本是一一对应的搞错了连启动都会报错。我当时的搭配方案是SpringBoot 2.7.18SpringCloud 2021.0.8SpringCloud Alibaba 2021.0.5.0Nacos 2.2.3Seata 1.7.0Redisson 3.20.1不建议一上来就选SpringBoot 3.x因为SpringCloud Alibaba的适配进度和SpringBoot 3.x的Jakarta迁移可能会让新手浪费时间排坑。用这套相对成熟的组合社区资料、踩坑案例都多出问题能查到解决方案。父工程是一个pom聚合工程每个服务是一个子模块公共依赖比如tide-common模块里的Result类、UserContext、异常处理单独抽成一个模块其他服务引用它。3.2 Nacos注册中心与Gateway网关配置Nacos在这个系统里扮演两个角色服务注册和配置中心。服务注册这一块几乎零成本在Nacos控制台启动好服务后SpringBoot应用加一条依赖spring-cloud-starter-alibaba-nacos-discovery然后在application.yml里配置spring.cloud.nacos.discovery.server-addr启动时服务名就会自动注册到Nacos控制台服务列表里就能看到实例和健康状态。Gateway网关是整个系统的流量入口它的路由配置决定了外部请求如何分发到各个微服务。一个典型的路由规则是这样spring: cloud: gateway: routes: - id: user-service uri: lb://tide-user-service predicates: - Path/api/user/** filters: - StripPrefix1 - id: goods-service uri: lb://tide-goods-service predicates: - Path/api/goods/** filters: - StripPrefix1lb://tide-user-service会从Nacos拿到服务实例列表Gateway自动做负载均衡转发。StripPrefix1的含义是去掉第一段路径也就是说外部请求/api/user/info经过网关后变成/info转发给用户服务。我在Gateway里还加了全局的鉴权过滤器、跨域过滤器、限流过滤器限流用的是基于Redis的RequestRateLimiter按IP维度每秒最多10个请求防止接口被盗刷。3.3 核心业务代码实现要点用户登录认证这块的核心代码主要分三段登录接口、JWT生成、网关过滤器。登录接口的逻辑没什么特别就是Spring Security的AuthenticationManager校验一下用户名密码校验通过后从用户表查出用户信息用Jwts.builder()生成Token。网关的过滤器是关键它的代码逻辑是这样的Component public class AuthGlobalFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token exchange.getRequest().getHeaders().getFirst(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody(); ServerHttpRequest mutatedRequest exchange.getRequest().mutate() .header(X-User-Id, claims.get(uid).toString()) .header(X-User-Role, claims.get(role).toString()) .build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } catch (Exception e) { // 返回401 } } // 白名单路径直接放行登录接口、商品浏览等 return chain.filter(exchange); } Override public int getOrder() { return -100; } }那段获取锁扣库存的代码用Redisson的API写起来很清楚RLock stockLock redissonClient.getLock(stock:lock: skuId); boolean locked stockLock.tryLock(0, 10, TimeUnit.SECONDS); if (!locked) { throw new BizException(当前抢购人数过多请稍后重试); } try { Long remain redisTemplate.opsForValue().decrement(stock:preoccupy: skuId); if (remain null || remain 0) { redisTemplate.opsForValue().increment(stock:preoccupy: skuId); throw new BizException(商品已经售罄); } // 发送MQ消息创建订单 } finally { stockLock.unlock(); }注意这里有个细节Redis的decrement操作是原子性的即使并发请求都获取到了锁最终也只能有一个请求把预占库存扣到负数以下所以还要判断扣减后的值如果小于0就回滚。分布式锁解决的是同一线程不能同时扣两次的问题Redis原子操作解决的是多个线程竞争时不能扣成负数的问题两个机制配合才严谨。本地消息表的实现是最终一致性的兜底方案。在订单表旁边建一张order_message表order_id、status、create_time、retry_count创建订单和插入消息在同一次数据库事务里提交。定时任务每5分钟扫描消息表中状态为待发送且重试次数小于5的记录把它们发送到RocketMQ发送成功后状态改为已发送。下游库存服务消费消息后执行库存扣减如果返回失败就进入重试Retry超限就进入人工告警。这套机制的核心价值在于本地表记录和业务数据同生共死消息绝对不会丢。3.4 前后端部署与运行验证部署我采用了两套环境开发环境用Docker Compose一键拉起基础设施MySQL、Redis、Nacos、MinIO、RocketMQ应用服务直接本地IDE启动日志在控制台看测试环境用Docker镜像部署所有微服务注册到同一个Nacos。前端构建时有个关键配置Vite的base路径要设置为/构建产物放在Nginx的html目录。Nginx配置里除了静态资源托管还配了反向代理location /api/ { proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这样请求/api/user/info会被转发给网关的/user/info前端代码里请求地址直接写/api/user/info所有流量都走同源。前端路由用的是History模式所以Nginx还需要一个try_files配置location / { try_files $uri $uri/ /index.html; }不配这个的话用户刷新/goods/detail/123这种二级页面会直接404这个问题在发布后特别容易遇到。4. 常见问题与排查技巧实录4.1 版本兼容与依赖冲突这是我见过最多人踩的坑也是最容易解决的。SpringCloud和SpringBoot版本没有对齐项目启动时各种ClassNotFoundException、NoSuchMethodError整个日志根本没法看。排查方法很粗暴但有效打开项目的pom.xml确认SpringBoot的版本号然后去SpringCloud官方文档查版本对应关系再根据SpringCloud的版本去SpringCloud Alibaba查对应版本。记住了spring-boot-starter-parent里定义的SpringBoot版本和spring-cloud-dependencies里定义的SpringCloud版本必须匹配否则后面写的所有微服务代码都是空中楼阁。另外热词里提到的SpringBoot版本太高同样值得警惕。新版本虽然性能更好但生态适配往往滞后。比如SpringBoot 3.x要求JDK 17部分老项目的第三方SDK比如某些支付SDK还在用JDK 8编译直接启动就报UnsupportedClassVersionError。做项目不是追新能用、稳定、社区熟才是第一原则。4.2 分布式锁与缓存经典问题分布式锁失效的场景比想象中多。第一种是业务执行时间超过锁的leaseTime锁自动释放后被别的线程拿到两个线程同时操作同一份数据超卖问题重新出现。Redisson的看门狗机制能解决大部分场景默认每10秒自动续期但如果业务方法里做了长时间IO操作或者大事务续期依然可能来不及。稳妥的做法是评估业务的正常耗时上限把leaseTime设置成平时的5倍以上同时保证业务代码里不能用tryLock后不放锁一定要在finally块里释放。第二种是锁的粒度太大。如果你对整个用户ID加锁那同一用户同时提交两笔订单没问题如果你对整个商品SKU加锁那所有用户同时抢购同一SKU都被串行化了秒杀性能直接崩。我的经验是锁粒度要尽量细比如用户ID SKU组合作为锁key单个用户单次购买单个商品是天然串行的不同用户买同一个SKU却能并发执行配合Redis原子扣减既能防超卖又不损失性能。缓存击穿和雪崩的排查工具其实很简单观察Redis的监控面板如果在某个时间点出现大面积查询打到数据库的P99曲线飙升基本就是缓存集中失效。解决雪崩的办法前面说过是过期时间加随机值解决击穿的互斥锁可以用Caffeine的get(key, loader)方法天然实现单飞模式比手写Redis锁更轻量。4.3 分布式事务与接口超时Seata AT模式踩过最深的坑是全局事务锁等待超时。两个事务分别操作同一张表的同一行数据后一个事务等待前一个事务释放全局锁时如果前一个事务执行时间过长比如内部调了一个慢接口后一个事务就会在到达全局锁等待超时阈值后抛异常。排查思路分三步一是在Seata控制台看全局事务的状态确认是Rollbacked还是Committing卡住二是看数据库里lock_table表确认持锁事务的XID和耗时三是找到那个慢接口优化它的执行时间或者调整client.rm.lock.retryInterval和client.rm.lock.retryTimes配置。Feign调用超时也是微服务架构里的高频问题。默认的Feign超时只有1秒稍微慢一点的SQL或者跨服务调用必然超时。我在application.yml里的配置是feign: client: config: default: connectTimeout: 5000 readTimeout: 5000但超时之后怎么处理才是关键。不能只是把超时时间改长更重要的是重试机制。Feign的Ribbon重试默认是关闭的如果开了重试对于扣款成功但返回超时这种幂等性敏感的接口必须保证接口实现了幂等比如用OrderId做去重否则重试会造成重复扣款。我在订单服务里对所有的写接口统一做了幂等校验请求参数里必须携带一个唯一业务流水号Redis里存一份重复请求直接拒绝。4.4 前端播放与跨域问题Vue播放m3u8最常见的坑是CORS。m3u8文件和ts分片文件放在MinIO上前端通过hls.js请求这些资源时浏览器会发起跨域请求。解决方式是在MinIO的CORS配置里加上允许跨域的规则或者更简单粗暴——直接用Nginx代理MinIO让前端请求的是同源地址不存在跨域问题。开发阶段最容易出现的是本地能播放、部署到服务器不能播放。原因多半是服务器上的MinIO桶权限没配置公开读或者Nginx代理MinIO时路径没对。排查顺序是先用浏览器直接访问m3u8文件的地址看看有没有403如果有就是桶权限问题如果没有看hls.js报的错误是网络错误还是解析错误网络错误排查路径和响应头解析错误就是文件本身切片有问题重新用FFmpeg转一次即可。4.5 性能排查的思路系统上线后不可避免地会遇到某个接口特别慢的问题。我在排查时有一套固定的套路第一看慢查询日志在MySQL开启slow_query_log抓出执行超过1秒的SQL一般来说排序、分组或者没走索引的查询八成是罪魁祸首第二看Redis的命中率如果接口每次都查数据库说明缓存策略失效第三看Gateway的请求日志里有没有超时时间特别长的路由如果有说明下游服务本身处理逻辑复杂第四看链路追踪用Sleuth把一次请求在多个服务之间的耗时放大看找到耗时占比最大的那个服务节点。性能优化不是玄学大部分性能问题都能归因到某个环节的串行等待上。比如我曾经优化过一个订单列表接口原先接口查一次数据库就算完了但为了拿商品封面图又调了一次商品服务导致接口耗时从20ms涨到400ms。后来把商品图URL直接冗余进订单表接口改回只查一次数据库耗时立刻降到30ms以下。分布式系统里的每一次远程调用都是性能损耗点能不调用就不调用这是铁律。5. 一些扩展方向这个系统的技术骨架其实可以复用。比如做一个SpringBootVueSpringCloud微服务平台的通用底座把认证、网关、日志、监控这些基础设施沉淀成一套公共服务任何垂直业务餐饮点单、二手交易、校园信息平台都能在这套底座上快速迭代业务模块。我当时在商品搜索里接入过HanLP做中文标签分词自动从穿搭描述里提取街头风日系机能风等风格标签在订单通知里接入过微信公众号模板消息这些场景都是底座之外的加分项。再比如分布式事务里那套本地消息表MQ的最终一致性方案实际工作中很多系统在用的其实就是这个思路。如果你面试时被问到分布式系统怎么保证数据一致你应该先说清楚遇到的是什么级别的一致性需求强一致的走Seata AT模式最终一致的走本地消息表或者事务消息。能把为什么这样选讲透比背十个技术名词有用得多。6. 个人实操体会项目做下来最大的体会就是技术服务于业务架构服务于演进。潮服商城这种业务天然需要快速迭代上新、灵活扩容秒杀、前后端并行开发所以微服务化的收益远大于成本。但也要清醒地认识到微服务带来的复杂性网络延迟、数据一致性、运维成本是实打实的如果做一个商场的官网站单体足够硬上微服务就是给自己找事。最后再分享一个实用性很高的小技巧在网关层把所有业务服务的请求日志统一打出来包含请求路径、耗时、状态码、用户ID。以后排查线上问题第一件事不是看数据库而是去网关日志里翻一次完整的请求链路根据耗时快速定位问题节点。日志打得好排查不用愁这个习惯我从这个项目开始一直保留到现在。
