给美食分享交流平台选技术栈那天我在单体 Spring Boot 和 springcloud-alibaba 微服务之间纠结了一下午。项目本身不复杂就是用户发菜谱、晒探店、互相点赞评论的社区站但内容、用户、互动这三块数据的增长曲线和读写压力完全不是一回事。最后我还是拍板走 Spring Cloud Alibaba 整套方案把项目拆成网关、用户、内容、互动、信息流五个服务先跑通再打磨。这篇文章记录的就是从需求分析、服务拆分、组件落地到部署排错的全过程尤其适合准备做 SpringCloud 项目、又不想只啃文档的朋友希望你们能少踩几个我踩过的坑。1. 先想清楚美食分享平台到底该拆成几个服务动手写代码之前我花最多时间做的不是搭建工程而是画服务拆分图。刚开始我有个很朴素的冲动照着页面拆服务——登录一个、首页一个、帖子一个、评论一个。后来被一个做架构的朋友拦住他说微服务拆分的单位从来不是页面而是业务边界和数据边界。页面是会变的今天首页展示的是信息流明天可能就要改版成关注流如果按页面拆改一版页面等于重构一套服务。1.1 三类核心业务内容、用户、互动美食分享交流平台表面上功能很多注册登录、发图文菜谱、探店打卡、点赞收藏、评论互动、个人主页、关注关系。但这些功能归纳下来其实只有三类用户类账号、资料、关注关系读写量中等数据一致性要求最高改密码、封号这类操作一个都不能丢。内容类帖子、图文、分类标签读取量大、写入相对低频发帖之后还有图片处理、摘要提取这类异步任务。互动类点赞、收藏、评论数、浏览数特征是高频、短数据、对实时性要求高丢几个点赞数字用户根本无感知但绝对不能把用户资料弄丢。三类业务的性质完全不同这就是拆分的最底层依据。我按这个思路定成了五个服务服务职责主要技术gateway统一入口、鉴权、路由Spring Cloud Gatewayuser-service注册登录、用户资料、关注关系Spring Boot JWTpost-service发帖、图文、分类、帖子详情Spring Boot MyBatis Plusinteraction-service点赞收藏、评论、计数Spring Boot Redisfeed-service首页信息流、热榜Spring Boot Redis我没有单独拆搜索服务是因为项目初期的帖子量级撑不起 Elasticsearch 的成本。很多人做 SpringCloud 项目容易陷入一个误区组件越多显得越厉害。我的原则正好相反每个服务、每个组件都必须有明确的业务理由没有理由就不上。1.2 服务之间的调用关系五个服务不是平级的。前端只跟 gateway 打交道登录之后拿到 JWT后续所有请求都带 token 过网关。网关校验身份之后把请求路由到具体服务。服务之间的调用统一走 OpenFeign比如 feed-service 要组装信息流需要拿到帖子摘要和作者昵称就会用 Feign 调 post-service 和 user-service。这里有个原则能异步的不要同步。发帖之后要更新信息流我不会在发帖接口里同步去调 feed-service而是用消息队列把“新帖发布”这个事件广播出去feed-service 自己订阅后更新缓存。好处是发帖接口的响应时间只算写自己 MySQL 的那一小段信息流晚一两秒更新用户根本感知不到。还有一个容易踩的地方服务之间不要形成环形调用。我一开始画的是 user-service 调 post-service 查帖子数post-service 又调 user-service 查作者信息跑起来之后发现一个接口嵌套了三层 Feign响应时间非常难看。后来统一改成 feed-service 来编排聚合其他服务只提供查询接口不在内部互相拉来拉去。1.3 数据拆分与一致性底线服务拆了数据库也得跟着拆。我给每个业务服务分配了独立的 MySQL 库user_db、post_db、interaction_db。Redis 则是共享的因为点赞这种热点数据必须全局统一否则互动服务查一下缓存、帖子服务也查一下缓存很容易出现两边不一致。分布式环境下最大的心理负担是跨服务的数据一致性。我在设计初期的原则是核心操作绝不搞跨服务的强一致事务能用最终一致的绝不用分布式事务。比如点赞先写 Redis再通过定时任务批量落库中间差几秒甚至几分钟都能接受。但用户注册不能这么干注册和初始化用户资料放在同一个服务里用本地事务解决宁可让这个服务写得“重”一点也不为了拆而拆。这一块建议所有准备做 springcloud 项目的同学先画一张数据归属表明确每个字段归哪个服务管别的服务需要这个数据只能通过接口拿绝不能绕过去直连别人的库。跨库直连是微服务架构里最隐蔽的坑短期测试环境看不出来等上线后数据对不上才开始后悔排查成本直接翻倍。2. 项目骨架搭建与组件选型把 Spring Cloud Alibaba 全家桶用明白工程结构和版本兼容是 SpringCloud 项目最先遇到的两座大山。很多新手照着教程敲代码结果服务启动一个崩一个大概率不是代码问题而是版本组合根本对不上。2.1 多模块 Maven 工程怎么建创建 springcloud 项目第一步不是写业务代码而是建好顶层父工程。我用的是 Maven 多模块结构food-parent聚合父工程common公共模块统一返回体、异常、工具类gatewayuser-servicepost-serviceinteraction-servicefeed-service父工程的 packaging 必须是 pom子模块各自负责打包。common 被其他所有模块依赖。父工程里的依赖统一用 dependencyManagement 管理子模块不要写死版本号这样升级组件的时候只改一处不会出现五个服务五个版本号乱飞的情况。2.2 版本兼容是头号陷阱Spring Cloud 和 Spring Cloud Alibaba 的版本号长期处于“看着差不多、实际天差地别”的状态。我用的这套组合在当时是比较稳的配比组件版本JDK1.8Spring Boot2.6.3Spring Cloud2021.0.1Spring Cloud Alibaba2021.0.1.0Nacos Server2.0.3MySQL8.0Redis6.2Spring Cloud Alibaba 的版本命名是跟 Spring Cloud 走的不是简单的 2.x。如果你直接引入 Spring Cloud Alibaba 2.2.2 这种老版本跟 Spring Cloud 2021 混在一起Nacos 初始化的时候会持续报错。最简单的办法是去翻官方的版本对应表别靠感觉猜。pom 里关键就两段。父工程里引入 Alibaba 的 BOMdependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.0.1.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement服务模块里引入 Nacos 注册中心dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency我因为版本踩过整整一天的坑Nacos 2.0.3 的服务端和 1.x 的客户端不兼容启动时注册成功过几秒却被踢下线日志里全是心跳超时。换到 2.0.3 的客户端后问题才消失。这个点在面试里也是高频题建议把 Spring Cloud Alibaba 的版本对应关系背清楚至少能随口说出一个可运行的组合。2.3 Nacos注册中心和配置中心一起开Nacos 是这套架构的地基。注册中心很好理解所有服务启动后把自己的 IP 和端口报给 Nacos消费者通过服务名来找提供者。我推荐把配置中心一起用上虽然多一层学习成本但后面改配置的时候是真的省事。我的做法是每个服务一个 namespace 一个组spring: application: name: post-service cloud: nacos: discovery: server-addr: localhost:8848 config: server-addr: localhost:8848 file-extension: yaml namespace: food-dev group: DEFAULT_GROUP数据库连接串、Redis 地址、限流阈值、功能开关全部放 Nacos 配置里本地用 food-dev 的 namespace服务器上用另一个 namespace同一份代码在不同环境间切换只需要改一个环境标识不用重新打包。有个细节很容易被忽略配置中心读取的 dataId 规则是${spring.application.name}.${file-extension}也就是 post-service.yaml 这样的命名。如果多个服务之间有公共配置可以用 shared-configs 指定共享配置文件否则每个服务都要复制一遍数据库连接字符串后期改起来非常痛苦。2.4 OpenFeign 与 Sentinel 的落地配置OpenFeign 是服务间调用的标配。相比 RestTemplateFeign 的优势是接口化和声明式——定义一个接口加注解就能远程调用代码可读性高很多也方便统一做降级处理。FeignClient(name user-service, fallbackFactory UserClientFallbackFactory.class) public interface UserClient { GetMapping(/api/user/{id}) ResultUserVO getUserById(PathVariable(id) Long id); }注意 OpenFeign 默认超时时间是 1 秒服务之间如果业务处理超过 1 秒就会直接报超时。我在配置里调到了 3 秒ribbon: ReadTimeout: 3000 ConnectTimeout: 1000再配合 Sentinel 做流量控制。美食平台的流量有个明显特点饭点前后点赞评论特别集中偶尔一个探店帖被推上热门瞬间可能涌进几千个请求。我给点赞接口配了限流单机 QPS 超过 1000 就排队等待超过 2000 直接返回“稍后再试”。规则放在 Nacos 里动态加载改阈值不需要重启服务。这里要特别提醒一个认知问题Sentinel 的限流是单机维度不是全局维度。如果你的服务部署了多副本实际吞吐是单机限流值乘以副本数。压测时必须按这个估算否则你以为限了 2000实际线上可能打进来 6000 还是挡不住。3. 三条核心链路发帖、信息流、互动这样落地架构搭起来之后真正见功夫的是业务链路怎么走。我挑三条核心链路详细讲讲它们几乎涵盖了社区类项目最难处理的问题文件上传、缓存一致性、高并发计数、内容安全。3.1 发帖链路图片上传与异步处理发帖是平台的第一个核心操作。用户上传照片、填写文字、选择分类、发布。这里最考验架构的其实是图片上传图片直接走应用服务器会占用大量带宽所以我让前端直传对象存储后端只接收图片 URL应用本身完全不碰文件流。发帖的接口流程分五步前端调用对象存储获取上传凭证直传图片拿到图片 URL。前端把文字内容和图片 URL 列表提交给 post-service。post-service 校验登录态从 JWT 里拿用户 ID、校验内容非空写入 post 表和 post_image 表。发送消息队列事件post.published事件里带帖子 ID。feed-service 收到消息后异步更新首页信息流缓存。第 4 步很多人会省略后果是首页每次都要查库才能知道有没有新帖长列表越拉越慢。用消息队列解耦之后发帖和展示的时效性由事件驱动feed-service 可以做增量排序不用每次请求都扫全表。消息队的可靠性也别忽略。生产者发送失败、消费者处理失败都要有兜底我加了一个本地消息表发帖事务提交后往消息表插一条发送记录后台定时任务把状态为“待发送”的记录重新投递消费端重复收到消息时通过唯一业务键做幂等判断。这套方案不依赖任何高级事务消息机制在中小型项目里已经足够可靠。3.2 首页信息流热度排序与 Redis 缓存首页是整个平台的门面。我的实现不是简单的“最新发布在前”而是一个热度排序避免首页全被低质量帖子和水帖占领。热度公式参考了社区类产品的常见做法score 点赞数 × 3 评论数 × 5 浏览数 × 0.1 - (当前时间 - 发布时间) / 3600公式里时间衰减是线性的一天前发布的帖子热度衰减 24 分一周前衰减 168 分。权重初版就用这组上线后根据数据表现再迭代。实现上我用 Redis 的 ZSet 存帖子 ID 和热度分值每当有人点赞或评论就在对应 ZSet 上更新分数。首页查询时从 ZSet 取出前 50 个帖子 ID再从帖子缓存批量取详情缓存没有的走数据库回源并回填。缓存要防三个经典问题穿透、击穿、雪崩。我的做法是回源时如果数据库也没有写入一个 null 值的短缓存热帖设置 1 到 3 小时的随机过期时间避免同一秒集体失效发帖和缓存更新之间用消息队列通知再加一层兜底双删先删缓存再更新数据库延迟 500 毫秒再删一次。这里分享一个实测经验Redis 里缓存的是帖子摘要而非全文摘要字段在发帖时生成。做这个优化之后首页响应时间从 80ms 降到了 30ms 以内效果立竿见影强烈建议做社区类项目的朋友照着试一下。3.3 点赞收藏Redis 计数器与落库补偿点赞是互动服务里最典型的场景。用户看中一篇菜谱点个赞数字加一再点一下取消。这种高频操作如果每次都写 MySQL单条更新虽然快但并发放大之后数据库扛不住而且“取消赞再点赞”的特殊逻辑很容易产生脏数据。我的设计分成两层。第一层是 Redis。每个帖子维护一个 ZSet成员是用户 ID分值标记点赞状态同时维护一个计数器 Stringkey 是post:like:{postId}。点赞接口执行 ZAdd 加用户 ID、INCR 计数器取消赞则 ZRem、DECR。用户是否点过赞的判断也走 RedisZScore 查一下就知道不用回数据库。第二层是落库。Redis 数据不是永久的我起了一个定时任务每分钟扫描最近有变更的帖子 ID把计数器的值和 MySQL 里的 like_count 对齐。为了防止任务重复执行造成计数漂移每次扫描记录一个游标时间只处理游标之后有变更的 key。这套方案有个天然取舍极端情况下 Redis 重启且没来得及落库会丢一部分点赞记录。我的判断是点赞属于“可以容忍丢失”的数据用户看到数字少了不会真有人去核对而且我把落库周期控制在 1 分钟以内风险极小。如果业务要求强一致就得走分布式锁甚至 Seata成本高很多我认为在这个场景确实没必要。3.4 评论与内容安全评论单独跑在 interaction-service 里评论表和帖子表分开存储。帖子详情页查评论走服务内部接口不直接读帖子库。好处是评论量再大也只拖累互动服务不会影响帖子列表的查询性能。内容安全是我一开始没想到、后来被逼着补上的模块。平台是公开的总有人发广告、发低质内容。我做了两层防护第一层是敏感词过滤用 DFA 算法加载一个敏感词词典发帖和评论在入口处直接过滤命中即拒绝。DFA 实现不复杂但要注意词典的更新机制。我是从配置中心拉取敏感词集合内容运营同学更新后通过 Nacos 推送服务不用重启。第二层是图片审核图片上传成功后会调用第三方审核接口异步回调如果审核不通过帖子标记为隐藏同时给用户发系统通知告知其内容因违规被限制展示。评论这里还有个经典坑“楼层号”在并发下容易乱套。如果是“第几楼”这种需求不能在应用层查 count 加一正确做法是让 MySQL 的自增主键承担楼层号或者用 Redis INCR 生成。我一开始在应用层查 count 再加一压测并发 100 个评论直接产生了 37 个重复楼层改成 Redis INCR 生成之后问题当场消失。4. 从本地调试到服务器部署踩过的坑和完整排查链路架构和代码都写完了真正的考验才开始。本地跑通和线上稳定运行之间隔着整整一层“环境地狱”。我在这部分栽过好几次挑几个印象最深的写详细一点。4.1 本地环境用 Docker 一次性把依赖拉起来本地开发最烦的是装环境Nacos、MySQL、Redis 一个个装一遍很浪费时间。我直接写了个 docker-compose一条命令全部拉起version: 3 services: nacos: image: nacos/nacos-server:v2.0.3 ports: [8848:8848] environment: MODE: standalone NACOS_AUTH_ENABLE: false mysql: image: mysql:8.0 ports: [3306:3306] environment: MYSQL_ROOT_PASSWORD: root123 redis: image: redis:6.2 ports: [6379:6379]注意 Nacos 2.0 的客户端通信默认走 9848 端口gRPC如果本地防火墙或服务器安全组只开放了 8848客户端会出现注册成功但心跳失败的情况。我一共三次遇到“明明注册了一会儿就下线”的怪现象最后都是 9848 端口的问题。这个问题非常隐蔽排查时务必第一个想到它。4.2 Nacos 注册成功但是 OpenFeign 调用 503 的排查这是整个项目里印象最深的一次排错前后花了快三个小时最终发现是一个很小、但又极其容易犯的配置错误。现象gateway 和其他服务都成功注册到 Nacos控制台能看到所有实例但在 post-service 里用 OpenFeign 调 user-service启动后第一次调用就抛异常java.lang.IllegalStateException: No instances available for localhost奇怪的是用网关入口去调 user-service 是成功的唯独服务间调用失败。我按下面的顺序一步一步排查检查 user-service 是否真的注册成功登录 Nacos 控制台确认服务列表里有 user-service实例健康状态是 true。检查 post-service 里 FeignClient(name user-service) 的服务名是否和控制台完全一致最容易因为大小写不一致、前后多空格、下划线写错而出问题。检查两个服务是否在同一个 namespace 和 groupnamespace 是隔离环境用的如果 post-service 在 dev 环境、user-service 在 prod 环境两边就互相看不见。检查 bootstrap.yml 里的 cluster-name 配置Nacos 默认集群名是 DEFAULT如果你手抖写了一个自定义集群名服务会优先在集群内找实例找不到就报 503。最终问题出在第 4 点。我在 post-service 里为了本地区分环境写了一个 cluster-nameuser-service 没写两边集群名不一致Feign 的负载均衡器按集群隔离查找实例自然什么都找不到。把两个服务的 cluster-name 对齐之后调用立刻恢复。这个排查链路值得完整写下来因为它覆盖了微服务排错的通用思路先确认注册再确认服务名再确认隔离分组最后确认负载均衡元数据。遇到 503 或者 No instances available 这类通用错误按这个顺序查基本都能在半小时内定位。4.3 网关统一鉴权与前端跨域冲突网关是所有请求的第一道关口我把登录校验放在了这里。前端登录后拿到 JWT后续每个请求在 Authorization 头里带上 token。网关的 GlobalFilter 先放行登录接口和公开接口其余请求解析 JWT解析失败直接返回 401解析成功把用户 ID 通过请求头往后端服务传递。这里最容易翻车的是跨域。前端域名是 localhost:3000后端网关是 localhost:8888浏览器 preflight 请求首轮就被拦表现是“明明后端接口能通浏览器里就是报 CORS 错误”。我的处理是在 gateway 配置里加全局 CORSBean public CorsWebFilter corsWebFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); return new CorsWebFilter(new UrlBasedCorsConfigurationSource()); }注意开启 credentials 模式也就是允许携带 cookie 或 Authorization 头时allowedOrigins 不能用*必须用 allowedOriginPatterns否则浏览器会直接拒绝响应。这个问题踩的人非常多写在这里帮各位排雷。还有一个顺序问题CORS 过滤器和 JWT 校验过滤器的执行顺序。如果 JWT 过滤器先执行preflight 的 OPTIONS 请求没有 token直接返回 401前端就会报跨域。所以 OPTIONS 请求必须无条件放行再进入 CORS 过滤器处理。4.4 单机服务器的部署与内存规划部署阶段我用了一台 2核4G 的云服务器坦白说这个配置跑微服务全家桶非常局促。五个服务全部启动后光 JVM 开销就超过 2G再加上 MySQL、Redis、Nacos内存一直徘徊在告警边缘。我的调整方案Nacos 以 standalone 模式运行MySQL 和 Redis 复用系统资源尽量精简服务端配置。每个服务的 JVM 堆内存限制在 256MB 到 512MB启动参数示例java -Xms256m -Xmx512m -jar post-service.jar用 Nginx 托管前端静态资源同时把 /api 反向代理到网关。证书、HTTP 转 HTTPS 都在 Nginx 处理Spring Cloud Gateway 只管内部路由不直接暴露公网端口。部署完成后我做了一轮简单压测200 并发请求首页接口缓存命中时 P95 响应时间在 150ms 以内数据库连接池没有打满。这个成绩对一台可用内存 2G 出头的服务器来说已经算不错。这里有个核心结论微服务不等于必须大集群。规模小的时候一台机器把所有服务打包部署也一样能跑但一定要做足资源规划别让每个服务都按默认参数启动否则 4G 内存连进程都撑不住。5. 这套架构的边界和后续还能怎么玩项目上线稳定运行之后我开始重新审视这套架构。很多准备做 SpringCloud 项目的朋友会问我一个美食分享社区真有必要拆这么多服务吗我的回答是既有必要也没必要关键是看你的目标是什么。5.1 什么时候该反思“拆多了”说实话如果只看功能实现单体 Spring Boot 完全够用甚至更合适。微服务带给你的核心价值是团队协作的解耦能力和独立扩展能力而不是性能提升。性能反而会下降因为每一次 Feign 调用都是一次网络开销每多一个中间件就多一个故障点。那为什么还要拆我的判断依据是如果你明确要为下一阶段做准备——比如要接推荐系统、要多端协同、要细分团队——那么提前按业务边界把服务拆好比上线后再拆要省太多事。这是一个典型的“现在痛一点以后省很多”的选择。把话说明白点学习阶段、毕设阶段、个人项目阶段做微服务不是为了炫技而是为了把分布式的几个核心问题提前练熟。注册中心、配置中心、限流降级、分布式事务、链路追踪这些能力在单体项目里永远练不到而这恰恰是 SpringCloud 面试题里最高频的考点也是实际工作中最值钱的经验。5.2 后续可以扩展的方向如果这个平台继续往下做我会优先考虑三件事。第一是搜索。内容多了之后靠 MySQL LIKE 查菜谱是忍不了的。我下一步打算引入 Elasticsearchpost-service 发布帖子时同步过去搜索走倒排索引支持按菜名、食材、标签多维度查询还能叠加城市字段筛选本地探店。第二是推荐。现在的首页是统一热榜用户画像完全不同也只能看同一屏。下一步可以用 Redis 记录浏览、点赞、收藏的帖子类别按类别加权召回候选集再做热度排序。不需要多复杂的算法简单的协同过滤已经能明显提升用户留存。第三是链路追踪。服务多了之后一个请求跨三个服务排查日志变得非常痛苦。SkyWalking 是我确定要接的它不需要侵入业务代码部署 Agent 就能把调用链和耗时串起来定位慢接口非常方便。最后再分享一个个人看法做这类项目的最大收获往往不是“用了多少中间件”而是你能不能讲清楚每一步为什么要这样设计。能把“为什么拆五个服务”“为什么用 Redis 存点赞”“为什么配置中心要单独拉出来”讲明白才是真的把 Spring Cloud Alibaba 这套东西学到手了。技术选型永远没有标准答案但每个决定背后都应该有一个能说服自己的理由这是我在这个项目里最大的体会。
Spring Cloud Alibaba微服务实战：美食分享平台架构设计全记录
给美食分享交流平台选技术栈那天我在单体 Spring Boot 和 springcloud-alibaba 微服务之间纠结了一下午。项目本身不复杂就是用户发菜谱、晒探店、互相点赞评论的社区站但内容、用户、互动这三块数据的增长曲线和读写压力完全不是一回事。最后我还是拍板走 Spring Cloud Alibaba 整套方案把项目拆成网关、用户、内容、互动、信息流五个服务先跑通再打磨。这篇文章记录的就是从需求分析、服务拆分、组件落地到部署排错的全过程尤其适合准备做 SpringCloud 项目、又不想只啃文档的朋友希望你们能少踩几个我踩过的坑。1. 先想清楚美食分享平台到底该拆成几个服务动手写代码之前我花最多时间做的不是搭建工程而是画服务拆分图。刚开始我有个很朴素的冲动照着页面拆服务——登录一个、首页一个、帖子一个、评论一个。后来被一个做架构的朋友拦住他说微服务拆分的单位从来不是页面而是业务边界和数据边界。页面是会变的今天首页展示的是信息流明天可能就要改版成关注流如果按页面拆改一版页面等于重构一套服务。1.1 三类核心业务内容、用户、互动美食分享交流平台表面上功能很多注册登录、发图文菜谱、探店打卡、点赞收藏、评论互动、个人主页、关注关系。但这些功能归纳下来其实只有三类用户类账号、资料、关注关系读写量中等数据一致性要求最高改密码、封号这类操作一个都不能丢。内容类帖子、图文、分类标签读取量大、写入相对低频发帖之后还有图片处理、摘要提取这类异步任务。互动类点赞、收藏、评论数、浏览数特征是高频、短数据、对实时性要求高丢几个点赞数字用户根本无感知但绝对不能把用户资料弄丢。三类业务的性质完全不同这就是拆分的最底层依据。我按这个思路定成了五个服务服务职责主要技术gateway统一入口、鉴权、路由Spring Cloud Gatewayuser-service注册登录、用户资料、关注关系Spring Boot JWTpost-service发帖、图文、分类、帖子详情Spring Boot MyBatis Plusinteraction-service点赞收藏、评论、计数Spring Boot Redisfeed-service首页信息流、热榜Spring Boot Redis我没有单独拆搜索服务是因为项目初期的帖子量级撑不起 Elasticsearch 的成本。很多人做 SpringCloud 项目容易陷入一个误区组件越多显得越厉害。我的原则正好相反每个服务、每个组件都必须有明确的业务理由没有理由就不上。1.2 服务之间的调用关系五个服务不是平级的。前端只跟 gateway 打交道登录之后拿到 JWT后续所有请求都带 token 过网关。网关校验身份之后把请求路由到具体服务。服务之间的调用统一走 OpenFeign比如 feed-service 要组装信息流需要拿到帖子摘要和作者昵称就会用 Feign 调 post-service 和 user-service。这里有个原则能异步的不要同步。发帖之后要更新信息流我不会在发帖接口里同步去调 feed-service而是用消息队列把“新帖发布”这个事件广播出去feed-service 自己订阅后更新缓存。好处是发帖接口的响应时间只算写自己 MySQL 的那一小段信息流晚一两秒更新用户根本感知不到。还有一个容易踩的地方服务之间不要形成环形调用。我一开始画的是 user-service 调 post-service 查帖子数post-service 又调 user-service 查作者信息跑起来之后发现一个接口嵌套了三层 Feign响应时间非常难看。后来统一改成 feed-service 来编排聚合其他服务只提供查询接口不在内部互相拉来拉去。1.3 数据拆分与一致性底线服务拆了数据库也得跟着拆。我给每个业务服务分配了独立的 MySQL 库user_db、post_db、interaction_db。Redis 则是共享的因为点赞这种热点数据必须全局统一否则互动服务查一下缓存、帖子服务也查一下缓存很容易出现两边不一致。分布式环境下最大的心理负担是跨服务的数据一致性。我在设计初期的原则是核心操作绝不搞跨服务的强一致事务能用最终一致的绝不用分布式事务。比如点赞先写 Redis再通过定时任务批量落库中间差几秒甚至几分钟都能接受。但用户注册不能这么干注册和初始化用户资料放在同一个服务里用本地事务解决宁可让这个服务写得“重”一点也不为了拆而拆。这一块建议所有准备做 springcloud 项目的同学先画一张数据归属表明确每个字段归哪个服务管别的服务需要这个数据只能通过接口拿绝不能绕过去直连别人的库。跨库直连是微服务架构里最隐蔽的坑短期测试环境看不出来等上线后数据对不上才开始后悔排查成本直接翻倍。2. 项目骨架搭建与组件选型把 Spring Cloud Alibaba 全家桶用明白工程结构和版本兼容是 SpringCloud 项目最先遇到的两座大山。很多新手照着教程敲代码结果服务启动一个崩一个大概率不是代码问题而是版本组合根本对不上。2.1 多模块 Maven 工程怎么建创建 springcloud 项目第一步不是写业务代码而是建好顶层父工程。我用的是 Maven 多模块结构food-parent聚合父工程common公共模块统一返回体、异常、工具类gatewayuser-servicepost-serviceinteraction-servicefeed-service父工程的 packaging 必须是 pom子模块各自负责打包。common 被其他所有模块依赖。父工程里的依赖统一用 dependencyManagement 管理子模块不要写死版本号这样升级组件的时候只改一处不会出现五个服务五个版本号乱飞的情况。2.2 版本兼容是头号陷阱Spring Cloud 和 Spring Cloud Alibaba 的版本号长期处于“看着差不多、实际天差地别”的状态。我用的这套组合在当时是比较稳的配比组件版本JDK1.8Spring Boot2.6.3Spring Cloud2021.0.1Spring Cloud Alibaba2021.0.1.0Nacos Server2.0.3MySQL8.0Redis6.2Spring Cloud Alibaba 的版本命名是跟 Spring Cloud 走的不是简单的 2.x。如果你直接引入 Spring Cloud Alibaba 2.2.2 这种老版本跟 Spring Cloud 2021 混在一起Nacos 初始化的时候会持续报错。最简单的办法是去翻官方的版本对应表别靠感觉猜。pom 里关键就两段。父工程里引入 Alibaba 的 BOMdependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.0.1.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement服务模块里引入 Nacos 注册中心dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency我因为版本踩过整整一天的坑Nacos 2.0.3 的服务端和 1.x 的客户端不兼容启动时注册成功过几秒却被踢下线日志里全是心跳超时。换到 2.0.3 的客户端后问题才消失。这个点在面试里也是高频题建议把 Spring Cloud Alibaba 的版本对应关系背清楚至少能随口说出一个可运行的组合。2.3 Nacos注册中心和配置中心一起开Nacos 是这套架构的地基。注册中心很好理解所有服务启动后把自己的 IP 和端口报给 Nacos消费者通过服务名来找提供者。我推荐把配置中心一起用上虽然多一层学习成本但后面改配置的时候是真的省事。我的做法是每个服务一个 namespace 一个组spring: application: name: post-service cloud: nacos: discovery: server-addr: localhost:8848 config: server-addr: localhost:8848 file-extension: yaml namespace: food-dev group: DEFAULT_GROUP数据库连接串、Redis 地址、限流阈值、功能开关全部放 Nacos 配置里本地用 food-dev 的 namespace服务器上用另一个 namespace同一份代码在不同环境间切换只需要改一个环境标识不用重新打包。有个细节很容易被忽略配置中心读取的 dataId 规则是${spring.application.name}.${file-extension}也就是 post-service.yaml 这样的命名。如果多个服务之间有公共配置可以用 shared-configs 指定共享配置文件否则每个服务都要复制一遍数据库连接字符串后期改起来非常痛苦。2.4 OpenFeign 与 Sentinel 的落地配置OpenFeign 是服务间调用的标配。相比 RestTemplateFeign 的优势是接口化和声明式——定义一个接口加注解就能远程调用代码可读性高很多也方便统一做降级处理。FeignClient(name user-service, fallbackFactory UserClientFallbackFactory.class) public interface UserClient { GetMapping(/api/user/{id}) ResultUserVO getUserById(PathVariable(id) Long id); }注意 OpenFeign 默认超时时间是 1 秒服务之间如果业务处理超过 1 秒就会直接报超时。我在配置里调到了 3 秒ribbon: ReadTimeout: 3000 ConnectTimeout: 1000再配合 Sentinel 做流量控制。美食平台的流量有个明显特点饭点前后点赞评论特别集中偶尔一个探店帖被推上热门瞬间可能涌进几千个请求。我给点赞接口配了限流单机 QPS 超过 1000 就排队等待超过 2000 直接返回“稍后再试”。规则放在 Nacos 里动态加载改阈值不需要重启服务。这里要特别提醒一个认知问题Sentinel 的限流是单机维度不是全局维度。如果你的服务部署了多副本实际吞吐是单机限流值乘以副本数。压测时必须按这个估算否则你以为限了 2000实际线上可能打进来 6000 还是挡不住。3. 三条核心链路发帖、信息流、互动这样落地架构搭起来之后真正见功夫的是业务链路怎么走。我挑三条核心链路详细讲讲它们几乎涵盖了社区类项目最难处理的问题文件上传、缓存一致性、高并发计数、内容安全。3.1 发帖链路图片上传与异步处理发帖是平台的第一个核心操作。用户上传照片、填写文字、选择分类、发布。这里最考验架构的其实是图片上传图片直接走应用服务器会占用大量带宽所以我让前端直传对象存储后端只接收图片 URL应用本身完全不碰文件流。发帖的接口流程分五步前端调用对象存储获取上传凭证直传图片拿到图片 URL。前端把文字内容和图片 URL 列表提交给 post-service。post-service 校验登录态从 JWT 里拿用户 ID、校验内容非空写入 post 表和 post_image 表。发送消息队列事件post.published事件里带帖子 ID。feed-service 收到消息后异步更新首页信息流缓存。第 4 步很多人会省略后果是首页每次都要查库才能知道有没有新帖长列表越拉越慢。用消息队列解耦之后发帖和展示的时效性由事件驱动feed-service 可以做增量排序不用每次请求都扫全表。消息队的可靠性也别忽略。生产者发送失败、消费者处理失败都要有兜底我加了一个本地消息表发帖事务提交后往消息表插一条发送记录后台定时任务把状态为“待发送”的记录重新投递消费端重复收到消息时通过唯一业务键做幂等判断。这套方案不依赖任何高级事务消息机制在中小型项目里已经足够可靠。3.2 首页信息流热度排序与 Redis 缓存首页是整个平台的门面。我的实现不是简单的“最新发布在前”而是一个热度排序避免首页全被低质量帖子和水帖占领。热度公式参考了社区类产品的常见做法score 点赞数 × 3 评论数 × 5 浏览数 × 0.1 - (当前时间 - 发布时间) / 3600公式里时间衰减是线性的一天前发布的帖子热度衰减 24 分一周前衰减 168 分。权重初版就用这组上线后根据数据表现再迭代。实现上我用 Redis 的 ZSet 存帖子 ID 和热度分值每当有人点赞或评论就在对应 ZSet 上更新分数。首页查询时从 ZSet 取出前 50 个帖子 ID再从帖子缓存批量取详情缓存没有的走数据库回源并回填。缓存要防三个经典问题穿透、击穿、雪崩。我的做法是回源时如果数据库也没有写入一个 null 值的短缓存热帖设置 1 到 3 小时的随机过期时间避免同一秒集体失效发帖和缓存更新之间用消息队列通知再加一层兜底双删先删缓存再更新数据库延迟 500 毫秒再删一次。这里分享一个实测经验Redis 里缓存的是帖子摘要而非全文摘要字段在发帖时生成。做这个优化之后首页响应时间从 80ms 降到了 30ms 以内效果立竿见影强烈建议做社区类项目的朋友照着试一下。3.3 点赞收藏Redis 计数器与落库补偿点赞是互动服务里最典型的场景。用户看中一篇菜谱点个赞数字加一再点一下取消。这种高频操作如果每次都写 MySQL单条更新虽然快但并发放大之后数据库扛不住而且“取消赞再点赞”的特殊逻辑很容易产生脏数据。我的设计分成两层。第一层是 Redis。每个帖子维护一个 ZSet成员是用户 ID分值标记点赞状态同时维护一个计数器 Stringkey 是post:like:{postId}。点赞接口执行 ZAdd 加用户 ID、INCR 计数器取消赞则 ZRem、DECR。用户是否点过赞的判断也走 RedisZScore 查一下就知道不用回数据库。第二层是落库。Redis 数据不是永久的我起了一个定时任务每分钟扫描最近有变更的帖子 ID把计数器的值和 MySQL 里的 like_count 对齐。为了防止任务重复执行造成计数漂移每次扫描记录一个游标时间只处理游标之后有变更的 key。这套方案有个天然取舍极端情况下 Redis 重启且没来得及落库会丢一部分点赞记录。我的判断是点赞属于“可以容忍丢失”的数据用户看到数字少了不会真有人去核对而且我把落库周期控制在 1 分钟以内风险极小。如果业务要求强一致就得走分布式锁甚至 Seata成本高很多我认为在这个场景确实没必要。3.4 评论与内容安全评论单独跑在 interaction-service 里评论表和帖子表分开存储。帖子详情页查评论走服务内部接口不直接读帖子库。好处是评论量再大也只拖累互动服务不会影响帖子列表的查询性能。内容安全是我一开始没想到、后来被逼着补上的模块。平台是公开的总有人发广告、发低质内容。我做了两层防护第一层是敏感词过滤用 DFA 算法加载一个敏感词词典发帖和评论在入口处直接过滤命中即拒绝。DFA 实现不复杂但要注意词典的更新机制。我是从配置中心拉取敏感词集合内容运营同学更新后通过 Nacos 推送服务不用重启。第二层是图片审核图片上传成功后会调用第三方审核接口异步回调如果审核不通过帖子标记为隐藏同时给用户发系统通知告知其内容因违规被限制展示。评论这里还有个经典坑“楼层号”在并发下容易乱套。如果是“第几楼”这种需求不能在应用层查 count 加一正确做法是让 MySQL 的自增主键承担楼层号或者用 Redis INCR 生成。我一开始在应用层查 count 再加一压测并发 100 个评论直接产生了 37 个重复楼层改成 Redis INCR 生成之后问题当场消失。4. 从本地调试到服务器部署踩过的坑和完整排查链路架构和代码都写完了真正的考验才开始。本地跑通和线上稳定运行之间隔着整整一层“环境地狱”。我在这部分栽过好几次挑几个印象最深的写详细一点。4.1 本地环境用 Docker 一次性把依赖拉起来本地开发最烦的是装环境Nacos、MySQL、Redis 一个个装一遍很浪费时间。我直接写了个 docker-compose一条命令全部拉起version: 3 services: nacos: image: nacos/nacos-server:v2.0.3 ports: [8848:8848] environment: MODE: standalone NACOS_AUTH_ENABLE: false mysql: image: mysql:8.0 ports: [3306:3306] environment: MYSQL_ROOT_PASSWORD: root123 redis: image: redis:6.2 ports: [6379:6379]注意 Nacos 2.0 的客户端通信默认走 9848 端口gRPC如果本地防火墙或服务器安全组只开放了 8848客户端会出现注册成功但心跳失败的情况。我一共三次遇到“明明注册了一会儿就下线”的怪现象最后都是 9848 端口的问题。这个问题非常隐蔽排查时务必第一个想到它。4.2 Nacos 注册成功但是 OpenFeign 调用 503 的排查这是整个项目里印象最深的一次排错前后花了快三个小时最终发现是一个很小、但又极其容易犯的配置错误。现象gateway 和其他服务都成功注册到 Nacos控制台能看到所有实例但在 post-service 里用 OpenFeign 调 user-service启动后第一次调用就抛异常java.lang.IllegalStateException: No instances available for localhost奇怪的是用网关入口去调 user-service 是成功的唯独服务间调用失败。我按下面的顺序一步一步排查检查 user-service 是否真的注册成功登录 Nacos 控制台确认服务列表里有 user-service实例健康状态是 true。检查 post-service 里 FeignClient(name user-service) 的服务名是否和控制台完全一致最容易因为大小写不一致、前后多空格、下划线写错而出问题。检查两个服务是否在同一个 namespace 和 groupnamespace 是隔离环境用的如果 post-service 在 dev 环境、user-service 在 prod 环境两边就互相看不见。检查 bootstrap.yml 里的 cluster-name 配置Nacos 默认集群名是 DEFAULT如果你手抖写了一个自定义集群名服务会优先在集群内找实例找不到就报 503。最终问题出在第 4 点。我在 post-service 里为了本地区分环境写了一个 cluster-nameuser-service 没写两边集群名不一致Feign 的负载均衡器按集群隔离查找实例自然什么都找不到。把两个服务的 cluster-name 对齐之后调用立刻恢复。这个排查链路值得完整写下来因为它覆盖了微服务排错的通用思路先确认注册再确认服务名再确认隔离分组最后确认负载均衡元数据。遇到 503 或者 No instances available 这类通用错误按这个顺序查基本都能在半小时内定位。4.3 网关统一鉴权与前端跨域冲突网关是所有请求的第一道关口我把登录校验放在了这里。前端登录后拿到 JWT后续每个请求在 Authorization 头里带上 token。网关的 GlobalFilter 先放行登录接口和公开接口其余请求解析 JWT解析失败直接返回 401解析成功把用户 ID 通过请求头往后端服务传递。这里最容易翻车的是跨域。前端域名是 localhost:3000后端网关是 localhost:8888浏览器 preflight 请求首轮就被拦表现是“明明后端接口能通浏览器里就是报 CORS 错误”。我的处理是在 gateway 配置里加全局 CORSBean public CorsWebFilter corsWebFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); return new CorsWebFilter(new UrlBasedCorsConfigurationSource()); }注意开启 credentials 模式也就是允许携带 cookie 或 Authorization 头时allowedOrigins 不能用*必须用 allowedOriginPatterns否则浏览器会直接拒绝响应。这个问题踩的人非常多写在这里帮各位排雷。还有一个顺序问题CORS 过滤器和 JWT 校验过滤器的执行顺序。如果 JWT 过滤器先执行preflight 的 OPTIONS 请求没有 token直接返回 401前端就会报跨域。所以 OPTIONS 请求必须无条件放行再进入 CORS 过滤器处理。4.4 单机服务器的部署与内存规划部署阶段我用了一台 2核4G 的云服务器坦白说这个配置跑微服务全家桶非常局促。五个服务全部启动后光 JVM 开销就超过 2G再加上 MySQL、Redis、Nacos内存一直徘徊在告警边缘。我的调整方案Nacos 以 standalone 模式运行MySQL 和 Redis 复用系统资源尽量精简服务端配置。每个服务的 JVM 堆内存限制在 256MB 到 512MB启动参数示例java -Xms256m -Xmx512m -jar post-service.jar用 Nginx 托管前端静态资源同时把 /api 反向代理到网关。证书、HTTP 转 HTTPS 都在 Nginx 处理Spring Cloud Gateway 只管内部路由不直接暴露公网端口。部署完成后我做了一轮简单压测200 并发请求首页接口缓存命中时 P95 响应时间在 150ms 以内数据库连接池没有打满。这个成绩对一台可用内存 2G 出头的服务器来说已经算不错。这里有个核心结论微服务不等于必须大集群。规模小的时候一台机器把所有服务打包部署也一样能跑但一定要做足资源规划别让每个服务都按默认参数启动否则 4G 内存连进程都撑不住。5. 这套架构的边界和后续还能怎么玩项目上线稳定运行之后我开始重新审视这套架构。很多准备做 SpringCloud 项目的朋友会问我一个美食分享社区真有必要拆这么多服务吗我的回答是既有必要也没必要关键是看你的目标是什么。5.1 什么时候该反思“拆多了”说实话如果只看功能实现单体 Spring Boot 完全够用甚至更合适。微服务带给你的核心价值是团队协作的解耦能力和独立扩展能力而不是性能提升。性能反而会下降因为每一次 Feign 调用都是一次网络开销每多一个中间件就多一个故障点。那为什么还要拆我的判断依据是如果你明确要为下一阶段做准备——比如要接推荐系统、要多端协同、要细分团队——那么提前按业务边界把服务拆好比上线后再拆要省太多事。这是一个典型的“现在痛一点以后省很多”的选择。把话说明白点学习阶段、毕设阶段、个人项目阶段做微服务不是为了炫技而是为了把分布式的几个核心问题提前练熟。注册中心、配置中心、限流降级、分布式事务、链路追踪这些能力在单体项目里永远练不到而这恰恰是 SpringCloud 面试题里最高频的考点也是实际工作中最值钱的经验。5.2 后续可以扩展的方向如果这个平台继续往下做我会优先考虑三件事。第一是搜索。内容多了之后靠 MySQL LIKE 查菜谱是忍不了的。我下一步打算引入 Elasticsearchpost-service 发布帖子时同步过去搜索走倒排索引支持按菜名、食材、标签多维度查询还能叠加城市字段筛选本地探店。第二是推荐。现在的首页是统一热榜用户画像完全不同也只能看同一屏。下一步可以用 Redis 记录浏览、点赞、收藏的帖子类别按类别加权召回候选集再做热度排序。不需要多复杂的算法简单的协同过滤已经能明显提升用户留存。第三是链路追踪。服务多了之后一个请求跨三个服务排查日志变得非常痛苦。SkyWalking 是我确定要接的它不需要侵入业务代码部署 Agent 就能把调用链和耗时串起来定位慢接口非常方便。最后再分享一个个人看法做这类项目的最大收获往往不是“用了多少中间件”而是你能不能讲清楚每一步为什么要这样设计。能把“为什么拆五个服务”“为什么用 Redis 存点赞”“为什么配置中心要单独拉出来”讲明白才是真的把 Spring Cloud Alibaba 这套东西学到手了。技术选型永远没有标准答案但每个决定背后都应该有一个能说服自己的理由这是我在这个项目里最大的体会。
