企业官网建设流程全解析

做了几年微服务落地项目，大大小小的系统也折腾过不少，但像“农产品物流运输”这种业务链条特别长的，还是有不少值得复盘的地方。这个系统表面上是一个物流管理系统，实际上牵扯到订单、仓储、运输、结算、溯源好几个核心域，业务链路长、参与角色多，还有大量的实时状态流转。用单体架构硬扛，到后期基本是改一处动全身，测试回归成本高到吓人。所以当时立项的时候，技术选型直接定了 SpringBoot + Vue + Spring Cloud 这套微服务组合，目标就一个：把复杂的业务拆开，让每个团队能独立迭代，互不踩踏。

这篇文章我不打算只讲架构图怎么画、代码怎么敲，而是把从零搭建这套农产品物流运输系统的完整思路、拆服务的方法论、关键技术难点的处理方式，以及线上实际踩过的坑，全部摊开来聊一遍。适合正在做微服务选型、准备拆系统，或者学校课程设计想拿微服务当亮点的同学参考。内容不会太教科书，都是我实际落地过程中验证过的东西。

1. 项目整体设计与微服务拆分思路

1.1 为什么农产品物流系统必须走微服务

先说说业务痛点。农产品物流和其他物流有个很大的区别：商品是生鲜，有生命周期。一车荔枝从产地出发，路上温度、湿度、停留时长都直接影响损耗率；运输过程中还要经过产地检验、装车、在途、到达、签收多个状态节点，每个节点都有不同的角色在操作——货主看单、调度派车、司机上报位置、仓库做入库、财务对账结算。

我最早用单体应用跑过一版Demo（也就是学校课设那个规模），发现的问题非常典型：

• 一个“创建运输单”的操作，要同时写订单表、生成调度任务、更新库存预占、触发运费计算，集中在同一个事务里。业务耦合就算了，并发一上来，数据库连接池直接被打满。
• 后台管理员要导出报表，一个重查询能把整个Tomcat线程池拖死，司机端App的请求也跟着排队响应。
• 每次改动——哪怕是换个报表模板——都要全量回归，整个项目编译打包一次要几分钟，效率极低。

这些问题的本质是：业务域之间的边界没有切开，技术资源被混在一起共享，谁都无法独善其身。微服务解决的不是“性能问题”，而是“复杂度问题”。把订单、仓储、运输、结算拆成独立服务后，每个服务有自己的数据库、自己的缓存、自己的线程池，重查询再也不会拖垮核心交易链路。

1.2 服务拆分的两种思路对比

当时拆服务时，团队里有两种声音。

一种主张按技术层拆，也就是拆成controller层服务、service层服务、dao层服务，这种拆法从技术架构图上看起来很规整，但业务上会让一次请求穿透多个服务，网络调用频繁，事务一致性几乎没法保证，而且任何一点改动都可能牵扯多个服务联调，比单体还难维护。

另一种主张按业务域拆，也是我们最终采用的方案：以领域模型为边界，一个核心业务闭环一个服务。我比较认同DDD里面的一句话：微服务的边界应该由业务能力来定义，而不是由技术组件来定义。农产品物流可以拆出这么几个核心域：

• 用户与认证服务：管理货主、司机、仓库管理员、平台运营等角色，负责登录鉴权
• 订单服务：处理货源发布、下单、支付、订单状态流转
• 运输调度服务：运单创建、车辆指派、司机接单、在途轨迹上报
• 仓储管理服务：出入库记录、库存管理、生鲜批次温度记录
• 结算服务：运费计算、司机结算单、货主账单
• 消息通知服务：短信、站内信、微信公众号模板消息推送（有热词提到微信公众号测试号API对接，这一块就是这个服务在管）

有人会问，为什么不拆得更细，比如把车辆管理、司机管理也单独拆出来？我的经验是：微服务不是拆得越细越好，而是要让每个服务都有清晰的业务存在感。车辆和司机本质上是调度域的基础数据，拆出去反而会让调度服务每次都要远程调用拿数据，凭空增加延迟。拆服务的粒度有个标准可以参考：如果两个功能总是同时被修改、同时被查询，它们就应该在一起；如果两个功能各自的修改频率和扩展方向不同，就应该拆开。

1.3 技术选型的关键判断

技术栈选型这块，我直接列一个表格，说明为什么选了这些组件。

不少人纠结过要不要上Spring Cloud Alibaba，觉得Nacos和Seata是不是太重了。我的观点是：既然已经决定走微服务，注册中心、配置中心、网关、分布式事务这些是躲不开的，与其每个组件去拼凑、自己去处理兼容性问题，不如直接用一套完整方案，让团队把精力放在业务实现上。而且Spring Cloud Alibaba的组件之间有很好的兼容性保证，版本对好了，基本不会出什么幺蛾子。

1.4 服务间通信与数据一致性架构

在服务通信上，我坚持的原则是：同步调用走OpenFeign处理强一致性的场景，异步消息走RocketMQ处理最终一致性的场景。

举个例子，用户下单这个动作：创建订单、扣减预占库存这两件事需要强一致性，所以订单服务通过Feign调用库存服务的接口，并在Seata全局事务里一起提交。而订单创建成功后的“给司机推送新任务通知”，这个就不需要和主流程绑在同一个事务里，直接发一条MQ消息到消息服务，哪怕通知发送失败，司机刷新页面也能看到任务列表，不影响主流程。

这里说一个细节点：不是所有服务间调用都要走分布式事务。很多新手容易犯的错是把每一步都纳入Seata事务，导致全局锁的竞争极其激烈，性能直线下降。我做过压测对比：一个创建运单的流程，原本只有订单+库存两步强一致操作，全局事务耗时大约在50ms左右，但如果把通知、日志、积分之类弱一致操作全部塞进来，耗时直接飙升到300ms以上。思路应该反过来——能用最终一致性解决的，就不要让分布式事务插手。

2. 核心技术点拆解与方案选型背后的逻辑

2.1 分布式事务：Seata AT模式的实际应用

农产品物流系统里有一类典型场景：司机在途确认送达时，运单状态要更新，库存要扣减（如果是门店自提商品），司机的结算单要生成，货主的账户要完成冻结金额扣除。这四个操作分别落在运输调度服务、仓储服务、结算服务三个服务里，任何一个失败都会导致账目不平。

我用的是Seata的AT模式。它的原理简单说就是：把业务SQL的“数据快照”记录下来，业务提交时先统一提交，如果后续发生异常，则根据快照进行逆操作回滚。好处是业务代码几乎无侵入，只需要在方法上加一个@GlobalTransactional注解。

看下实际代码（做了简化）：

@GlobalTransactional(name = "transport-confirm", rollbackFor = Exception.class) public void confirmArrival(TransportConfirmRequest request) { // 1. 更新运单状态为已到达 transportOrderMapper.updateStatus(request.getTransportOrderId(), TransportStatus.ARRIVED); // 2. 调仓储服务扣减库存（如果该运单关联入库单） if (request.getHasStorageRecord()) { storageFeignClient.deductStock(request.getWarehouseId(), request.getProductId(), request.getActualQuantity()); } // 3. 调结算服务生成司机结算单 settlementFeignClient.createSettlementForDriver( request.getDriverId(), request.getTransportOrderId(), request.getFreightAmount()); // 4. 调结算服务扣减货主预付款 settlementFeignClient.deductFromShipperAccount( request.getShipperId(), request.getFreightAmount()); }

这里有个非常有用的实践心得：AT模式虽然侵入性小，但要注意锁的时间控制。Seata AT模式在事务执行期间，会对涉及的数据行加全局锁，其他事务要操作同一行数据就得等待。如果全局事务里有耗时的第三方调用（比如短信通知），全局锁的持有时间就会很长，直接拖垮并发。我们的做法是把这类耗时操作移到事务外面，通过MQ异步去触发，让全局事务里只有纯数据库操作。

另外，有人问过：能不能用本地消息表代替Seata？可以，但实现成本不低。本地消息表的核心思路是每个服务维护一张消息表，业务操作和消息写入放在同一个本地事务里，然后通过定时任务把消息发出去，靠消息确认和重试机制保证最终一致性。这个方案的优点是性能好、不依赖额外中间件，但缺点是要处理消息重复发送、消费幂等、表设计等一系列问题。如果项目里本来就要引入MQ，本地消息表+MQ是能接受的方案；如果不想搞那么多基础设施，Seata AT模式直接一步到位更省心。

2.2 分布式锁在生鲜库存扣减中的应用

农产品经常搞限时秒杀类的促销活动，比如“海南荔枝产地直发，前100单五折”。这种场景对库存的扣减并发要求非常高。单机时代我们用的synchronized和JVM锁，在微服务架构下直接失效——因为多个服务实例之间根本不在同一个JVM里。

我选择用Redis分布式锁解决这个问题。这里share一个曾经的踩坑经历：最早我直接用setnx加锁，忘记设置过期时间，结果某次服务OOM挂掉了，锁永远没有释放，所有库存操作直接死锁。后来改成Redis官方推荐的Redisson客户端，它提供了看门狗机制自动续期，解决了锁过期时间设置的问题。

核心代码示例：

@Autowired private RedissonClient redissonClient; public boolean tryDeductStock(Long productId, Integer quantity) { String lockKey = "stock:lock:" + productId; RLock lock = redissonClient.getLock(lockKey); boolean locked = false; try { // 尝试获取锁，最多等待3秒，自动释放时间默认30秒 locked = lock.tryLock(3, TimeUnit.SECONDS); if (!locked) { return false; // 抢锁失败，说明有其他请求正在处理同一商品 } // 扣减库存逻辑 int result = stockMapper.deductStockWithCondition(productId, quantity); return result > 0; } finally { if (locked) { lock.unlock(); } } }

注意这里我用了deductStockWithCondition，也就是SQL里带条件写：

UPDATE inventory SET available_stock = available_stock - #{quantity}, version = version + 1 WHERE product_id = #{productId} AND available_stock >= #{quantity}

这个更新语句本身就是原子操作，为什么还要加分布式锁？因为业务上除了扣库存还要做其他的非原子操作，比如记录秒杀成功的用户、发送优惠券、创建物流预订单。分布式锁在这里保证的是“整个业务完整执行完再放过下一个请求”，而SQL条件写保证的是“数据库层面的库存不会超卖”。两者是层次不同的保障，不能说有了SQL条件写就不需要锁了，反之亦然。

2.3 网关层的统一鉴权与动态路由

微服务架构下，前端请求进来首先是打到网关（Spring Cloud Gateway），由网关做路由转发。我一开始把鉴权逻辑写在了各个服务里，每个服务都要解析JWT、查用户权限表，代码大量重复不说，权限策略调整时要改所有服务再重新发布，折腾得够呛。

后来把鉴权统一收敛到网关层，思路是：

1. 前端登录拿到JWT token后，后续所有请求在Header里带上 token
2. 网关的全局过滤器先解析JWT，验证签名和有效期
3. 解析出的用户ID和角色写入请求Header，转发给下游服务
4. 下游服务从Header里拿用户信息，不再重复解析token

这里有一个细节值得分享：网关层做鉴权，但细粒度的权限判断要下沉到业务服务里。比如“司机只能查看分配给自己的运单”，这种行级权限网关没法处理，必须在运输调度服务里根据Header里的用户ID去过滤数据。所以合理的划分是——网关做“身份认证 + URL级权限粗筛”，业务服务做“数据级权限控制”。

网关过滤器的核心逻辑：

@Component public class AuthGlobalFilter implements GlobalFilter, Ordered { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); String path = request.getPath().value(); // 白名单路径直接放行 if (isWhitelist(path)) { return chain.filter(exchange); } String token = request.getHeaders().getFirst("Authorization"); if (StringUtils.isBlank(token)) { return unauthorizedResponse(exchange); } try { // 解析JWT Claims claims = Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token.replace("Bearer ", "")) .getBody(); // 将用户信息放入Header，转发给下游服务 ServerHttpRequest mutatedRequest = request.mutate() .header("X-User-Id", claims.get("userId").toString()) .header("X-User-Role", claims.get("role").toString()) .build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } catch (Exception e) { return unauthorizedResponse(exchange); } } }

2.4 前端Vue在复杂物流场景下的架构设计

农产品物流系统的前端不是简单的增删改查页面，它有几个比较有挑战的点：

• 司机端需要实时刷新在途任务，掌握位置上报的状态
• 货主端需要看到订单从下单到签收的全生命周期状态
• 运营后台需要处理大量数据表格、图表统计、报表导出

我用的是 Vue 3 + Vue Router + Pinia + Element Plus的组合。当时从 Vue 2 迁移过来的，一个重要考量是Vue 3 的组合式API让业务逻辑的复用变得非常舒服。比如司机端有一个“上报当前位置”的功能，逻辑涉及获取经纬度、调接口、更新任务状态、判断是否需要弹窗提醒，用composable函数可以很干净地封装出来，多个页面共用一套逻辑。

前端路由用动态路由的方式实现：根据用户的角色和权限，动态生成菜单和路由表。这个设计在物流系统特别实用——司机登录后只能看到我的任务、我的账单；货主登录后看到发布货源、订单跟踪；管理员登录后看到所有模块。实现思路是：

1. 登录成功后，后端返回该用户可访问的菜单列表
2. 前端把菜单列表映射为路由表，动态注册到Vue Router
3. 通过路由守卫判断用户是否有权限访问某个页面

还有一个比较实用的建议：前端工程打包后部署到Nginx，配置反向代理把/api前缀的请求转发到网关地址。这样前端代码里只需要写相对路径，开发环境和生产环境可以用同一个.env文件里的变量控制后端地址，避免打包时手动改代码。

3. 环境搭建与核心模块的实操记录

3.1 服务端基础工程搭建

创建微服务工程环境，我用的是Maven多模块结构（从热搜词里看到“Java Maven项目构建方法SpringBoot”高频出现，这里重点展开）。父工程只做依赖版本管理，子模块是各个微服务。结构大概是这样：

agriculture-logistics/ ├── pom.xml // 父工程，统一管理版本号 ├── auth-service/ // 用户认证服务 ├── order-service/ // 订单服务 ├── transport-service/ // 运输调度服务 ├── storage-service/ // 仓储管理服务 ├── settlement-service/ // 结算服务 ├── notification-service/ // 消息通知服务 ├── common/ // 公共模块（工具类、统一返回体、异常处理） ├── gateway/ // 网关服务 └── sql/ // 数据库初始化脚本

父工程pom里用dependencyManagement统一锁定版本，这是所有微服务的基础。注意别图省事把每个子模块的依赖写死，版本统一管理后面能省掉大量“A服务用Spring Boot 2.7，B服务用2.6”这种兼容性灾难。

<properties> <spring.boot.version>2.7.18</spring.boot.version> <spring.cloud.version>2021.0.5</spring.cloud.version> <spring.cloud.alibaba.version>2021.0.5.0</spring.cloud.alibaba.version> </properties>

这个版本组合是我实际验证过比较稳的一套。Spring Boot 2.7.18是2.x系列的最后一个维护版本，稳定性有保障；Spring Cloud Alibaba 2021.0.5.0 对Nacos和Seata的支持也成熟。如果要用Spring Boot 3.x，整个Spring Cloud版本要升级到2022.0.x以上，而且很多组件的API有变化，没必要在课程设计或中小型项目里追新。

3.2 Nacos注册中心与配置中心落地

Nacos安装不复杂，下载解压后直接启动startup.cmd -m standalone（单机模式）。但有两个容易踩坑的点要提前说：

第一，Nacos的配置文件里要设置数据源为MySQL，默认是Derby内嵌数据库，重启后配置会丢失。需要提前执行官方提供的nacos-mysql.sql脚本，并在conf/application.properties里配置：

spring.datasource.platform=mysql db.num=1 db.url.0=jdbc:mysql://localhost:3306/nacos?characterEncoding=utf8&useSSL=false db.user.0=root db.password.0=你的密码

第二，服务注册到Nacos之后，一定要在配置中心里建对应的配置文件，比如order-service.yaml。这里要特别提醒：Nacos的配置文件名要写全，带上后缀（.yaml或.properties），而且Data ID的命名规范是服务名.后缀，没带后缀会导致服务启动时配置拉取不到，我就是因为这个小细节排查了半天。配置中心的动态刷新也是微服务比单体舒服的地方，改了配置点发布，服务不需要重启就能生效。

3.3 Nacos + OpenFeign的服务调用链路打通

服务注册到Nacos后，接下来就是服务间调用。我用OpenFeign做声明式HTTP调用，接口定义变得非常直观。以运输调度服务调用仓储服务为例：

@FeignClient(name = "storage-service", path = "/api/storage") public interface StorageFeignClient { @PostMapping("/stock/deduct") Result<Boolean> deductStock(@RequestBody StockDeductRequest request); @GetMapping("/stock/{productId}") Result<StockInfo> getStockInfo(@PathVariable("productId") Long productId); }

在运输调度服务里直接注入使用，配合Nacos的负载均衡默认机制，请求会自动分发到storage-service的多个实例上。这一步打通之后，业务逻辑就能在各服务之间流转了。

这里有一个很关键的配置项：Feign的超时时间。默认超时是1秒，物流场景下业务接口往往涉及数据库查询甚至多个表的联查，1秒很容易超时。当时一台服务器配置差了点，查询库存详情经常要800-900ms，偶尔一慢就超时报错。后来在配置文件里调整了超时时间：

feign: client: config: default: connectTimeout: 5000 readTimeout: 10000

3.4 数据库设计与分库策略

微服务架构下，每个服务有独立的数据库。这不仅是架构偏好，更是数据安全的红线——如果服务都连同一个库，一旦某个服务的慢查询把数据库连接池打满，所有服务的数据库操作都会受到牵连，等于没有拆分。

我在设计阶段对库做了明确的职责划分：

分库带来一个直接的问题：跨库查询没法用join。以前单体里一条SQL就能搞定的“查询某订单的司机姓名和车辆牌照”，现在要分别查transport库和user库再在应用层组装。为了减少这种跨服务调用的频率，我在设计表结构时就做了反范式的冗余设计——运输订单表里直接冗余了司机名、司机电话、车辆牌照等字段，避免每次展示列表都要远程调用认证服务。这个取舍在数据量可控的物流系统里是非常合理的，订单状态变化不频繁，冗余字段的更新成本很低。

3.5 Vue前端与后端联调实践

前端这块，我建议在开发阶段就配置好Vite的代理，避免跨域问题干扰联调。在vite.config.ts里配置：

export default defineConfig({ server: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', // 网关地址 changeOrigin: true, // 不要重写路径，网关里路由会按前缀区分服务 } } } })

后端网关里用路径前缀区分服务，这个设计我在项目里验证过非常实用：

spring: cloud: gateway: routes: - id: auth-service uri: lb://auth-service predicates: - Path=/api/auth/** - id: order-service uri: lb://order-service predicates: - Path=/api/order/** - id: transport-service uri: lb://transport-service predicates: - Path=/api/transport/**

前端请求统一走/api/auth/**、/api/order/**这种地址，网关根据前缀转发到对应服务。这样做的好处是：前端不需要关心后端服务拆分了多少个模块，后端服务部署地址怎么变，前端代码都不需要改动。

3.6 MinIO在农产品溯源图片存储中的应用

农产品物流系统里需要存大量的现场照片——装车时拍的货物照片、运输途中司机上报的车辆状态照片、到达时仓库验收的照片。一部分还涉及售后纠纷取证，图片必须长期保存且不能丢。用本地磁盘存不行——微服务多个实例无法共享本地磁盘。用FastDFS搭建复杂，维护成本高。

我选了MinIO，它是开源的对象存储服务，兼容S3协议，部署非常简单。Spring Boot整合MinIO的依赖是io.minio:minio，核心操作就是创建桶、上传对象、生成访问链接：

@Configuration public class MinioConfig { @Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint("http://localhost:9000") .credentials("minioadmin", "minioadmin") .build(); } } // 上传并返回访问地址 public String uploadFile(MultipartFile file) { String objectName = UUID.randomUUID().toString() + "." + FilenameUtils.getExtension(file.getOriginalFilename()); minioClient.putObject(PutObjectArgs.builder() .bucket("logistics-images") .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return "http://localhost:9000/logistics-images/" + objectName; }

有个细节：MinIO的桶默认是私有的，直接返回URL访问会403。要么在MinIO控制台把桶权限设置为public（适合图片这种不敏感的数据），要么通过后端服务生成临时预签名URL。农产品物流场景里的照片主要供货主和司机查看，没有保密性要求，我直接设为public了，简洁实用。

4. 线上部署与运维排查实录

4.1 Docker Compose环境编排

开发环境我直接用Docker Compose把全套依赖拉起来，比手动装MySQL、Redis、Nacos、MinIO要省事得多。docker-compose.yml里把中间件定义好，一条docker-compose up -d全部搞定。

这个环节有个值得推荐的设置：给每个容器加上资源限制。Nacos在开发环境里经常因为内存不足自动挂掉，yml里加上mem_limit: 1g能避免很多幺蛾子。另外所有中间件都要配置restart: always，否则服务器一重启，服务很难自动恢复。

服务的Docker镜像用Dockerfile打包，这里也给一个标准的Spring Boot微服务Dockerfile：

FROM openjdk:8-jre-alpine MAINTAINER your-name ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone WORKDIR /app COPY target/transport-service.jar app.jar EXPOSE 8083 ENTRYPOINT ["java", "-Xms512m", "-Xmx512m", "-jar", "app.jar"]

4.2 服务监控与日志排查实战

微服务实例多了之后，最大的痛点就是排查问题——报错的时候根本不知道问题出在哪个服务。

日志排查方面，我用的是Spring Boot默认的logback日志框架，但加了traceId贯穿链路。在Feign调用时通过RequestInterceptor把traceId传到下游服务，这样在日志系统里按traceId搜一下就能看到整个调用链的日志。这个改造很简单但价值极大。

@Component public class TraceIdFeignInterceptor implements RequestInterceptor { @Override public void apply(RequestTemplate template) { // 从当前请求上下文获取traceId，透传到下游 String traceId = MDC.get("traceId"); if (StringUtils.isNotEmpty(traceId)) { template.header("X-Trace-Id", traceId); } } }

刚开始做日志排查的时候，我经历了一次比较典型的“事故”。某个周末司机反馈上传运输轨迹一直失败，我想查日志，但运输服务有三个实例，我不知道用户的请求打到哪台，只能一台一台去翻日志，效率极低。后来给每个实例加了独立的日志目录并在日志输出里标记实例名，同时通过Nacos控制台看服务健康状态，这个窘境才缓解。

4.3 常见问题和故障排查速查表

把项目运行中实际遇到的高频问题整理成表格，方便大家对照排查：

4.4 分布式锁的并发压测验证

这个项目里最有意思的调优发生在生鲜秒杀库存扣减的压测环节。压测环境是4台运输服务实例，Redis单机，初始并发100，模拟1000个用户同时抢购200份库存。

第一轮压测结果惨不忍睹——超卖现象严重，最终库存成了负数。排查后发现两个问题：一是Feign调用链路上有服务实例超时重试，导致同一个请求被处理两次；二是库存扣减的SQL没有加available_stock >= #{quantity}条件，纯粹的update语句没法防止并发超卖。

修复这两个问题后再压测，200份库存最终扣减到0，没有超卖。后续把并发提到500时，发现Redis分布式锁的等待时间明显变长，一部分请求在3秒内等待不到锁直接失败了。这个属于正常情况——分布式锁本身就是用排队换一致性的，商品数量有限的情况下，失败请求直接返回“商品已抢光”是合理的产品行为。

5. 一些想分享的实战体会

项目上线稳定运行了将近一年，整个链路没有出过大故障。回看整个过程，有几件事感触很深。

第一件，微服务架构不是银弹，它解决复杂问题的同时也在制造新的复杂度。Nacos挂了怎么办、Feign调用超时怎么办、分布式事务回滚失败怎么办、日志怎么串联、配置怎么同步——这些都是单体应用里不需要面对的问题。所以我建议，如果项目规模不大、团队人数少，不要为了“微服务”三个字强行拆服务。把项目拆得零零碎碎，没有一个清晰的业务边界，维护成本只会更高。

第二件，拆服务的方式比技术选型更影响项目命运。技术选型不好可以换，服务边界拆错了，后期调整的代价几乎等于重写。我的经验是先画业务流程图，把核心链路走一遍，识别出哪些环节之间的交互频繁、哪些环节有着截然不同的变更频率，然后再定服务边界。

第三件，测试和运维的投入要比单体时代大得多。微服务架构下的测试要处理服务间的Mock、环境变量管理、联调环境部署，没有CI/CD流水线，每次发布都是手动的人肉操作，出错的概率非常高。如果时间精力允许，尽早引入流水线自动构建和发布，会给后期节省大量时间。

最后说一个实用的小技巧：如果学校课程设计或毕业设计想体现微服务的亮点，不一定要把业务做得多复杂，而是要在几个关键点上有“痕迹”——注册中心里有服务列表（截图）、配置中心里能动态改配置（演示视频）、Feign调用能通、网关成功拦截未登录请求，这几点做扎实了，答辩时的说服力是非常强的。我当时就是把“运输链路跟踪”这个业务场景和Nacos服务发现、MinIO图片存储、微信公众号通知这几个微服务特色点串成一条完整的故事线，整体效果还是不错的。