企业官网建设流程全解析

这个问题我看到标题第一反应是：“怎么又是练手项目？”但仔细看完需求描述，发现其实要从一个比较工程化的视角来展开——不是那种“照着粘贴配置就能跑”的教程文，而是真正讲清楚：微服务拆分之后，入口和调用链为什么难维护，Spring Cloud Gateway 和 Nacos 在这套体系里分别解决什么问题，以及从注册中心、网关、业务服务到服务间调用，到底怎么串成一条可观测、可 排查、易扩展的完整链路。

这篇内容主要适合正在从单体转向微服务的中小型团队。工作机制类似：原来的 Spring MVC 单体里，模块之间直接用本地方法调用，不涉及网络，排错也简单。但拆成独立进程部署之后，每个服务都要处理鉴权、限流、跨域、路由跳转，服务之间要互相发现，调用链要能观测。你把网关和注册中心这套架子搭起来，后面只要往 Nacos 里注册新服务，路由和负载均衡就能自动接上，维护成本会明显降一大截。

我在标题里看到“全链路”三个字，理解不只是“网关做了转发、Nacos 注册了几个实例”就结束了，而是把“Gateway + Nacos + OpenFeign”这条线串起来做一次完整的闭环。正文就按实际工程落地顺序来写：先做环境和方案选型，再装 Nacos 和搭建父工程，然后写网关模块、用户服务、订单服务，最后把所有节点通过 TraceId 串起来，并用 Postman 模拟一整个请求链路。整个实操我建议围绕一个简化版的“订单-用户”业务模型展开，这样既能体现服务间调用，又不会因为业务复杂而把基建问题掩盖掉。

1. 方案拆解与架构设计

1.1 解决的核心问题

微服务改造后，第一个遇到的通常不是性能问题，而是“服务之间怎么找到对方 + 入口纪律怎么维持”。服务 A 调用服务 B 的时候，如果 B 的地址写死在配置文件里，那 B 一旦扩容或者迁移，A 就得跟着改配置重启。这个局面维持不了几天。

引入 Nacos 之后，服务 B 启动时把自己的 IP、端口、服务名注册到注册中心，服务 A 在调用 B 时只认服务名，IP 由注册中心动态下发。这样服务实例的上线、下线、扩容，对调用方几乎透明。这是微服务最基础也是最重要的一环。

但只是服务发现还不够。原来单体架构下，所有请求都进同一个应用，鉴权、日志、限流都是统一做的。服务拆分后，如果每个服务都自己实现一套鉴权，那拦截逻辑会散落到各个系统里，很难统一维护，而且是安全风险点。把网关放到所有服务前面，让所有外部请求先过网关，由网关做统一的路由转发和身份校验，这就是入口控制的核心思路。

1.2 技术选型说明

网关我选择 Spring Cloud Gateway 而不是 Zuul 或直接写一个 Servlet 过滤器，核心理由是 Gateway 基于 WebFlux 异步非阻塞模型，在高并发连接数下对线程资源的消耗更小，而且官方维护的 Spring Cloud 生态里，Gateway 本身就是标准入口组件。

注册中心方面，Nacos 有注册发现和配置管理两个重要能力，搭建一套环境就能同时解决“服务发现”和“配置集中管理”两个问题。和 Eureka 相比，Nacos 的控制台体验更直观，配置变更可以动态推送。

服务间远程调用选用 OpenFeign，因为它把 HTTP 调用封装成了接口声明式调用，代码里只要写好接口定义，底层负载均衡和请求发送都由框架完成。链路串联的部分，我会用一个自定义的 Filter 生成 TraceId，经过 OpenFeign 继续往下游传递，这为后续接入 SkyWalking 这类分布式追踪系统预留了扩展空间。

整个链路设计只为一个目标：外部请求无论打到哪个下游服务，都能从网关开始完整追踪到所属的调用链。

1.3 模拟业务模型定义

整个验证项目采用先创建基础工程，再层层递进的方式推进：第一层创建父工程，统一管理依赖版本。第二层创建 Nacos 基础设施，负责服务注册。第三层是网关服务，负责所有外部流量入口；第四层是业务服务，内部通过 OpenFeign 互相调用。

业务仅模拟两个服务节点：

• user-service：提供用户基本信息查询接口，端口 8081
• order-service：提供订单查询接口，端口 8082，并调用 user-service 获取用户名称

一条完整请求从网关进去后，会落到 order-service，再由 order-service 通过 OpenFeign 调用 user-service。这样最少两个节点就能把网关、注册中心、服务发现、负载均衡、链路追踪全部串起来。

2. 前置准备与版本锁定

2.1 本地环境清单

我先列出自己搭建时用到的基础环境，避免后期大家拿不同版本组合遇到一堆莫名其妙的依赖冲突。核心组件统一用 JDK 8，因为我测试了 JDK 17 某些组合会报 Spring 相关组件和 JDK 模块限制的错误，对入门项目不友好。Maven 使用 3.6.3 以上，并配置阿里云镜像加速依赖下载。

我最终测试通过的版本组合如下：

提示：Spring Cloud Alibaba 的版本必须和 Spring Cloud 版本严格对应，否则 Nacos 的 Starter 会找不到对应依赖。这个版本对照表可以在 Spring Cloud Alibaba 官方文档里查，建议不要自行组合。

2.2 创建父工程 pom

父工程只负责管理依赖版本，不写具体业务代码。创建根目录microservice-lab，在 pom.xml 引入 dependencyManagement，关键点是把 Spring Cloud 和 Spring Cloud Alibaba 的 BOM 一起 import：

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>2021.0.5</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2021.0.5.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

这里要注意 dependencyManagement 和 dependencies 的区别：父工程里用 dependencyManagement 只是锁定版本，不会把依赖传递给所有子模块。如果直接放在 dependencies 里，每个子模块都会被迫引入 Nacos 客户端、Gateway 相关的依赖，这会污染普通业务模块，所以必须用前者。

2.3 初始化三个子模块结构

在父工程下创建gateway-service、user-service、order-service三个目录，并在父 pom 的 modules 节点里注册：

<modules> <module>gateway-service</module> <module>user-service</module> <module>order-service</module> </modules>

每个子模块的 pom 只需要引入自己需要的 starter。比如 order-service 引入 openfeign、nacos-discovery、web 和 loadbalance，不像网关那样引入 gateway starter。父工程锁版本，子模块明确自己的职责依赖，这样后期调整版本只改一个文件。

3. Nacos 安装与注册中心搭建

3.1 下载、启动与控制台验证

去 Nacos 官方 GitHub 仓库下载 2.2.0 版本，运行nacos-server-2.2.0.tar.gz。Windows 环境进 bin 目录双击startup.cmd -m standalone，Linux 环境用sh startup.sh -m standalone。-m standalone的意思是单机模式，不需要额外启动 MySQL。

启动完成后访问http://localhost:8848/nacos，默认账号密码是nacos/nacos。能看到登录页面就说明服务已经起来了。

注意：Nacos 2.x 版本默认会占用 8848 和 9848 两个端口，9848 是 gRPC 通信端口。如果本地防火墙策略比较严格，两个端口都要放通，否则服务注册时偶现失败，表现为服务能启动但 Nacos 控制台始终看不到实例。

3.2 配置命名空间和分组

很多人在 Nacos 里把配置分组当作环境隔离来用，我个人更建议在一开始就直接建好命名空间。namespace 用于区分不同的微服务环境，比如 dev、test、prod，每个环境都有独立的注册中心和配置集合，物理隔离；group 用于同一环境内不同业务域之间的区分，类似逻辑分组。

在控制台“命名空间”菜单中创建一个名为dev的命名空间，记录生成的命名空间 ID，后续在 Spring Cloud 配置中通过 Namespace 属性引用。

很多人在配 bootstrap.yml 的时候会把 namespace 配成“dev”这个字符串，这是踩了第一个坑。Nacos 的 namespace 字段使用的是控制台里生成的那一串比较长的 ID，不是命名空间名称。我用过的是自动生成的那串 UUID。写成名称会导致配置找不到，服务正常启动，但配置中心的内容拉取不到。

3.3 Nacos 成功标准

验证 Nacos 是否就绪，要以服务实例注册、心跳上报及控制台实例列表可见为准，而不是以服务进程起来为准。先启动任意一个业务服务，再去控制台检查名为user-service的服务，点击“详情”，能看到对应实例的 IP 和端口，才表示注册中心这条链路是通的。

4. 网关服务搭建与核心功能实现

4.1 Gateway 依赖和启动类

网关模块在依赖层面有严格的要求：不能额外引入spring-boot-starter-web，因为 Spring Cloud Gateway 基于 WebFlux 的响应式模型，和传统的 Spring MVC servlet 模型冲突。一旦两个 starter 同时存在，启动阶段会出现路由自动装配失效、请求进不了网关的诡异情况，这个坑在所有排查场景中出现频率最高。网关模块的 pom 就引入两个核心依赖：

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>

启动类加上@SpringBootApplication和@EnableDiscoveryClient注解即可。实际上新版本下即使不加@EnableDiscoveryClient，只要 classpath 里有 Nacos Discovery 的 starter，服务注册也会自动生效，但显式加上可以让人一眼看出这个服务具备注册发现能力，后期排错也更清晰。

4.2 路由配置与负载均衡规则

看下面的配置，完整覆盖了网关的关键信息：

server: port: 8080 spring: application: name: gateway-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: 你的namespaceID gateway: routes: - id: user-service-route uri: lb://user-service predicates: - Path=/api/user/** filters: - StripPrefix=1 - id: order-service-route uri: lb://order-service predicates: - Path=/api/order/** filters: - StripPrefix=1 discovery: locator: enabled: false

这里拆开几个关键概念：

lb://user-service中的 lb 前缀意思是让网关采用客户端负载均衡，通过注册中心获取服务实例列表，再按负载均衡策略从其中选一个实例转发。如果直接写http://127.0.0.1:8081，服务实例变更后就无法自动感知，这和网关引入注册中心的目的冲突了。

StripPrefix=1的含义是转发路径时去掉第一个路由前缀。比如外部请求/api/user/info，经过 StripPrefix 之后，网关转发给 user-service 的路径就变成/user/info。很多团队如果不做这个处理，下游接口定义必须带着/api前缀，两边耦合会很深，所以要尽早习惯用 StripPrefix 把网关前缀和服务内部路径解耦。

discovery.locator.enabled=false是为了防止网关自动生成以服务名为路径的路由规则。如果开启true但没有配置对应路由，可能引起网关对外暴露过多内部路由信息，且和自定义路由容易混淆。我不建议开启。

路由 id 必须唯一，如果有两条都声明user-service-route，启动时会报错且路由不生效。命名建议按服务候选名来：服务名-route，后期配置管理时扫一眼就很清楚。

4.3 全局过滤器实现认证和 TraceId

网关层最重要的自定义组件是全局过滤器，它会在每个请求被转发前执行。这里我做一个通用逻辑：从请求头里取 Token 做简单校验，并且生成 TraceId 放入请求头。

@Component public class AuthAndTraceFilter implements GlobalFilter, Ordered { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String traceId = UUID.randomUUID().toString().replace("-", ""); ServerHttpRequest request = exchange.getRequest().mutate() .header("X-Trace-Id", traceId) .build(); String token = request.getHeaders().getFirst("Authorization"); if (token == null || token.isEmpty()) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } return chain.filter(exchange.mutate().request(request).build()); } @Override public int getOrder() { return -100; } }

Order 值设置为负数，优先级更高，保证网关过滤器能先执行。

在正式项目中不可能只做这么简单的 Token 判断，更常见的是网关统一解析 JWT，然后把解析出来的用户信息写入请求头，下流服务从请求头直接读。把鉴权逻辑放在网关层而不是业务服务里的原因是，这类校验逻辑往往涉及多业务系统共享的公共逻辑，只要收敛到入口，就不会出现“某个服务忘了校验就暴露了非法接口”这样的低级事故。限流和日志等其他公共逻辑也可以逐步往这一层集中。

4.4 跨域配置的三种做法

微服务网关默认处理跨域配置有几种常见方式。方法一是在 gateway 配置里加 GlobalCors 属性，最推荐；方法二是在全局过滤器中手动设置 CORS 响应头；方法三是让业务服务自己处理跨域。推荐直接改网关，避免业务服务每个服务都要维护一套 CORS 配置。

如果配置了网关跨域但请求还是出现跨域错误，最常见原因是浏览器对 OPTIONS 预检请求的路径识别和转发规则冲突。预检请求需要网关直接返回响应，不要再进入业务服务的路由。推荐的配置写法如下：

spring: cloud: gateway: globalcors: cors-configurations: '[/**]': allowed-origin-patterns: "*" allowed-methods: "*" allowed-headers: "*" allow-credentials: true

配置里允许携带凭证（allow-credentials: true）时，allowed-origin-patterns 不能直接配*，否则会被浏览器拦截，这一点是以往前端联调时比较容易出现的问题。

5. 业务服务落地与 OpenFeign 调用

5.1 user-service：基础接口实现

user-service 是完整的 Spring Web 应用，pom 中引入spring-boot-starter-web、nacos-discovery。配置文件里指定端口为 8081，服务名是user-service，并注册到同一个 Nacos 服务中。

提供一个简单的用户接口：

@RestController @RequestMapping("/user") public class UserController { @GetMapping("/info/{id}") public UserInfo getUserInfo(@PathVariable("id") Long id) { return new UserInfo(id, "用户" + id, "测试地址"); } }

因为网关层做了 StripPrefix，外部请求路径是/api/user/info/1，网关转发到 user-service 后才能真正对应到/user/info/1这个接口。如果本地绕过网关直接访问http://localhost:8081/user/info/1，也不需要加上/api前缀。

5.2 order-service：通过 OpenFeign 调用用户服务

order-service 是链路中的关键节点，它要同时开放本地查询接口，并通过 OpenFeign 调用 user-service。

pom 里引入：

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-loadbalancer</artifactId> </dependency>

Spring Cloud 2021.0.x 版本以后，OpenFeign 默认使用 Spring Cloud LoadBalancer 做负载均衡，必须配合引入 loadbalancer 包，否则启动时的报错信息是找不到ReactiveLoadBalancer或LoadBalancerClient。

启动类加上@EnableFeignClients，这样框架就会自动扫描所有 FeignClient 接口并生成动态代理实现。定义一个 Feign 客户端：

@FeignClient(name = "user-service") public interface UserClient { @GetMapping("/user/info/{id}") UserInfo getUserInfo(@PathVariable("id") Long id); }

FeignClient 的 name 必须和 Nacos 上注册的服务名完全一致，包括大小写，并且不能带下划线之外的字符。调用时写本地接口的相对路径，不包含服务名。

订单接口中调用 Feign 客户端：

@RestController @RequestMapping("/order") public class OrderController { @Resource private UserClient userClient; @GetMapping("/detail/{orderId}") public OrderDetail getOrder(@PathVariable Long orderId) { String userName = userClient.getUserInfo(1L).getName(); return new OrderDetail(orderId, "订单-" + orderId, userName); } }

通过网关发起/api/order/detail/1001，网关转发到 order-service 的/order/detail/1001，处理过程中自动调用 user-service。整个链路两个服务之间的负载均衡是注册中心+ Feign 客户端完成的，不需要手写 HTTP 请求。

5.3 负载均衡的生效过程

用户服务如果启动两个实例：8081 和 8082，Nacos 控制台 user-service 的实例列表就会展示两条记录。Feign 在调用时通过内置负载均衡策略选择其中一个。默认策略是轮询，两个实例分别分配一次请求。

这个过程和网关层的 lb:// 逻辑一样，都是先把服务名解析成实例列表，再用 LoadBalancer 选择实例。所以整个链路中，虽然不同端点技术服务模型不同，但注册中心这边是一致的，配置也一致，排错思路也可复用。

5.4 OpenFeign 调用的超时和序列化坑

默认的 OpenFeign 连接超时是 10 秒，读超时是 60 秒，这个值对不同业务差异很大。在线下单场景中如果一个调用超过 5 秒，对终端用户来说感知已经很糟糕，建议根据具体场景单独改。在 application.yml 中测试配置如下：

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

实际测试网关发起的请求里，如果下游接口是慢 SQL，需要同步调大 Feign 读超时和网关的路由超时，并注意网关响应超时和 Feign 读超时不要倒挂。否则终端可能已经收到超时响应，但下游服务还在继续处理中，容易形成孤儿请求。

序列化方面，如果返回的是一个 Java 对象，需要确认它有没有可用的无参构造方法和 setter，否则 Feign 反序列化时会直接报 500，但日志里不一定有明显错误，这是隐蔽坑。接口返回值建议使用统一的响应体；测试时没加包装类，直接暴露了实体，这在真实项目中不推荐，但演示链路上足够了。

6. 链路追踪与全链路打通

6.1 自定义 TraceId 的传递机制

把过滤器生成的 TraceId 放进 request header 是链路追踪的起点，

但服务之间的调用是新的 HTTP 请求，不会自动携带原有请求头。所以要让 Feign 把网关传入的X-Trace-Id继续传递下去。最简单的方式是实现一个 Feign 的 RequestInterceptor，把当前请求上下文里的 TraceId 拿出来放到 Feign 请求头。

@Component public class FeignTraceInterceptor implements RequestInterceptor { private static final String TRACE_ID = "X-Trace-Id"; @Override public void apply(RequestTemplate template) { ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attributes != null) { String traceId = attributes.getRequest().getHeader(TRACE_ID); if (traceId != null) { template.header(TRACE_ID, traceId); } } } }

注意：只有在请求经过 order-service 的 Controller 时，RequestContextHolder 里才有当前请求上下文，所以拦截器才能拿到值。如果某次调用不是由外部 HTTP 请求触发（比如定时任务），拦截器里的 attributes 会是 null，要确保在代码里判空。

6.2 日志输出带上 TraceId

链路追踪最终要在日志中可查，否则只是传输过去也不能快速定位问题。在每个服务里初始化日志格式，在 pattern 中使用%X{TRACE_ID}占位符。这里我直接用 MDC 把 traceId 放入日志上下文：

@Component public class WebTraceIdFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; String traceId = req.getHeader("X-Trace-Id"); if (traceId != null) { MDC.put("TRACE_ID", traceId); } try { chain.doFilter(request, response); } finally { MDC.remove("TRACE_ID"); } } }

日志配置里增加：

logging.pattern.level=%5p [%X{TRACE_ID}]

这样每个日志行都会自动带上 TraceId。当用户反馈某个订单问题，只要拿到一个订单号，就能从网关日志入口开始，按同一个 TraceId 把所有服务日志串起来，定位到具体是哪个服务超时或报错。

这个方案比直接接入 Zipkin 轻量得多，已经能覆盖排查请求链路的需求。等服务数量和调用链复杂度上升，再升级为 SkyWalking 或 Zipkin 时，也可以把 TraceId 转为标准的 traceId、spanId，平滑迁移。

6.3 全链路请求验证过程

启动顺序：Nacos -> user-service -> order-service -> gateway-service。全部启动后，先验证各服务是否已注册到控制台。重点是打开服务列表，能看到gateway-service、user-service、order-service三个服务都在线。

再从外部发起请求：

curl -X GET "http://localhost:8080/api/order/detail/1001" \ -H "Authorization: test-token"

预期返回结果：

{ "orderId": 1001, "orderName": "订单-1001", "userName": "用户1" }

这个请求实际走了三个节点：网关认证并生成 TraceId、网关按 lb://order-service 转发到订单服务、订单服务通过 Feign 调用用户服务读取用户名。三个节点日志中通过 X-Trace-Id 串联：第一次启动不带 Token 请求，网关返回 401；带了 Token 后链路通。排查问题时直接去 order-service 日志搜这个 traceId，就能看到 OpenFeign 调 user-service 的完整执行时间。

6.4 链路定位中的日志排查顺序

当请求链路较长，从哪个服务开始排查往往决定排障效率。我的经验是一律从网关访问日志开始。网关日志里会保留请求路径、目标路由、耗时、状态码。如果网关显示转发成功但下游返回 500，就去 order-service 看日志，因为网关本身不执行业务逻辑；如果网关日志里都没有对应记录，说明请求根本没进到网关，通常是网络层的问题。

需要保持所有服务的日志都输出到统一目录，并尽量统一格式，因为同一链路跨服务，如果各服务日志格式不一致，日志分析系统聚合后会出现明显的碎块化，定位效率低、体验割裂。推荐最少要统一时间格式、日志级别、TraceId 字段名。

7. 常见问题与排查技巧实录

7.1 问题速查表

7.2 时间超时问题的排查案例

实际配置过程中遇到最多的是网关和下游超时时间不一致。某个接口正常处理需要 3 秒，但网关转发超时配置时才 2 秒，就会出现浏览器不断转圈、网关已经返回 504 的“假故障”，但下游服务其实执行没问题。定位时看网关日志有超时，而下游日志显示请求已成功处理，而且随后出现了返回处理结果。这种问题核心在于，整个链路的超时时间必须按照“网关 -> Feign -> 下游处理”的顺序逐层递减规划。

7.3 使用 Nacos 控制台定位服务问题

如果调用失败，我第一个操作通常是打开 Nacos 控制台，确认像user-service是否有服务。若服务不存在，说明服务没注册成功；若实例是“不健康”状态，要检查心跳上报情况，通常是应用和 Nacos 的网络不通，但应用还能跑着，这种容易被忽略。

如果 Nacos 控制台看起来正常，但网关仍报 503，检查网关所在服务的配置文件，确认它是否和业务服务注册到了同一个 namespace。namespace 配置错了，控制台看是两个服务，但网关这一侧根本找不到目标服务。

7.4 配置永不生效的排查顺序

微服务配置类问题有一个固定排查顺序：先看 Nacos 配置文件有没有正常加载，再确认 bootstrap 是否引入，再确认 namespace 是否匹配，最后看字段名。实际项目里多是一些细节问题，比如 Spring Cloud Alibaba 版本不同，Nacos 相关配置的默认值是开启还是关闭不同，不同版本之间spring.cloud.nacos.discovery.enabled的默认值差异，本地测试环境偶尔出现服务总是注册不上，最终发现是某个默认配置文件把注册开关写死了。这种默认值和版本的差异问题，排查时先翻官方版本说明，再动配置，除非非常确定，否则不要臆测配置含义。

8. 实战心得与后期扩展建议

整套链路搭建下来，最花时间的其实不是写控制器，而是版本组合与异常排查。入门项目如果采用这套 Spring Boot 2 系列的组合，稳定性相对高。Spring Boot 3 和 Spring Cloud 2023 的版本组合在部分新版本组件上 API 有变化，尤其是 Gateway 和 Nacos 适配需要额外注意。如果不是团队规定要上新版本，我建议先沿用这套稳定组合，要冲新版本再单独立项验证。

后续项目要扩展，可以从这几个方向继续深入：

• 网关侧增加 Sentinel 限流规则，保护下游服务不被突发流量打垮；
• 把 Nacos 自带配置中心用起来，业务服务里的数据库连接池参数、开关配置都上收配置中心动态调整，避免频繁发布；
• 接入 SkyWalking 的 Java Agent，实现全链路调用链可视化，对每次请求每个节点的耗时一目了然；
• Gateway 路由全部迁移到 Nacos 配置中心，网关路由规则变动时不用重启网关，通过配置中心动态刷新。

最终我给这个项目的定位就是“最小但完整的微服务骨架”。不要一上来就堆 Sentinel、Seata、消息队列，把这些放在以后。你如果经历过从单体拆分成多服务的过程，就会理解跑一遍这套骨架最大的价值在于：知道一个请求从网关进来后，到底如何被路由、负载均衡、调转和追踪的。这些理解越扎实，未来再引入分布式事务，至少不会把组件的通信原理搞混。