企业官网建设流程全解析

1 什么是微服务？

微服务不是“把服务做小”，而是一种按业务拆分的架构思想：
把单体应用按领域边界（如用户、订单、支付）拆成多个高内聚、低耦合、独立进程、独立数据库、独立部署的小服务，服务间用 HTTP/gRPC 等轻量协议通信，技术栈也可自由选择（Java/Go/Python 各用各的）。

• 分布式系统（Distributed System）：一种将系统组件部署在多个物理节点上，通过网络协同工作的架构范式。
• 微服务（Microservices）：一种基于业务领域边界构建的分布式架构风格，强调服务自治、独立演进与松耦合协作。

1.1 为什么需要微服务？（直击单体痛点）

单体架构的四大死穴：
🔹部署：改一点，发全部→ 上线风险高；
🔹扩容：扩一个，全跟着涨→ 资源浪费严重；
🔹代码：多人抢一库→ 合并冲突多、构建等待久；
🔹技术：技术绑死→ 想换框架？重写半边天。

微服务对症下药：✅ 独立部署｜✅ 按需扩容｜✅ 团队自治｜✅ 技术解耦

1.2 微服务不是银弹，用对时机才有效

🔹适合微服务：团队 ≥5人｜代码 ≥10万行｜业务高频迭代｜需独立扩缩容或技术异构；
🔹坚持单体更优：小系统（如内部管理、MVP验证）、低流量、业务稳定、人力有限——简单即可靠。
⚠️ 过早微服务 = 自建复杂度，却无实际收益。

1.3 单体 vs 微服务

1.4 微服务的组成及选型（这里比较全可以参考哈）

1.5 生产级选型（Spring Cloud Alibaba）

🔹 基础选型（入门 → 中小型项目）

🔹 进阶选型（中大型 / 高并发）

• 分布式事务：Seata AT 模式（通用）+TCC 备案（强一致性关键链路）
• 消息队列：RocketMQ（高可靠、事务消息、阿里系深度适配）
• 缓存：Redis Cluster+Nacos 动态配置缓存策略（如过期时间、降级开关）
• 监控告警：Prometheus + Grafana（统一指标采集，对接 Sentinel/SkyWalking）
• 服务网格：Istio（仅当 Kubernetes 成熟且需精细化流量治理时引入）

🔹 配置最佳实践（避坑要点）

• Nacos：按环境 + 服务名分组；敏感配置启用Nacos AES 加密。
• Sentinel：规则存储用Nacos 推模式（持久化+动态生效），禁用内存拉模式。
• Gateway：路由写lb://service-name，严禁硬编码 IP/端口。
• 版本管理：全程使用spring-cloud-alibaba-dependenciesBOM 控制版本，禁止单独升级子组件。

2 微服务核心组件

2.1 服务注册 / 发现

🔹 服务注册流程

1. 注册请求发起
   服务提供者启动时，通过Nacos SDK向 Nacos 服务端发送注册请求，携带关键元数据：
   • 服务名（serviceName）、主机 IP（ip） 、服务端口（port） 、健康检查路径（healthChecker.path，如/actuator/health）
2. 元数据持久化与同步
   • Nacos 服务端将实例信息持久化写入 MySQL（保障高可用与可恢复性）；
   • 同时基于Distro 协议（去中心化、最终一致性协议）异步广播至集群其他节点，实现跨节点元数据同步。
3. 健康状态维护（心跳机制）
   • 提供者以默认 5 秒间隔向服务端发送心跳；
   • 服务端判定逻辑：
     • 超过15 秒未收到心跳→ 标记该实例为UNHEALTHY（不健康）；
     • 连续30 秒无心跳→ 从内存及持久层自动剔除该实例。

🔹 服务发现流程

1. 首次查询
   服务消费者启动时，向 Nacos 服务端发起GET /nacos/v1/ns/instance/list?serviceName=xxx请求，指定目标服务名。
2. 服务端响应策略
   • Nacos 优先从本地内存缓存（非实时查库）中获取该服务下所有healthy = true的实例列表；
   • 返回结果包含 IP、端口、权重、集群名等字段，支持负载均衡路由。
3. 客户端本地缓存优化
   • 消费者 SDK 自动缓存服务列表，默认每 30 秒拉取一次更新（可配置nacos.client.refresh.interval）；
   • 后续远程调用直接读取本地缓存，避免频繁网络请求，显著降低延迟与服务端压力。

🔹 实际应用

• 📚Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现
• 📚Spring Cloud Alibaba基础教程：Nacos的集群部署

2.2 配置中心

🔹 核心流程

🔹 配置分级模型（Namespace / Group / DataID）

🔹 常见误解澄清：

🔹 实际应用

• 📚Spring Cloud Alibaba基础教程：使用Nacos作为配置中心

2.3 API 网关

🔹 网关的核心功能特性

💡本质一句话：
网关 = 统一入口 + 安全闸机 + 智能导航 + 流量调度员，所有能力均在客户端侧闭环完成，零侵入后端服务。

🔹 “客户端负载均衡” 和 “服务端负载均衡” 的分水岭

1. 负载均衡永远作用于“被调用方”（下游服务），而非“调用方”（自身）。
2. 调用方只负责「从多个候选实例中选一个」，不向自己发起转发。
3. 网关 或是 业务服务使用的都是客户端负载均衡。

🔹 路由配置组成

🔹 内置路由断言（Predicates）列表

🔹 内置路由过滤器工厂（Filters）种类

Spring Cloud Gateway 提供了31 种不同的路由过滤器工厂。例如：

💡 其他常用过滤器还包括：Retry,StripPrefix,SetPath,DedupeResponseHeader,SaveSession,SetStatus等（共 31 种，详见官方文档）。

🔹 实际应用

• 📚Spring Cloud构建微服务架构：服务网关（Spring Cloud Gateway）

2.4 服务通信

🔹 微服务调用方式速查表

✅一句话选型建议：

• 写 REST API → 选@FeignClient；
• 写核心链路/高并发内部服务 → 选@DubboReference；
• 学原理或特殊调度 → 用LoadBalancerClient；
• RestTemplate + Ribbon仅用于兼容老系统。

🔹RPC 与 HTTP 的核心区别

💡一句话理解：
HTTP 是“打电话说普通话”——通用、易懂、谁都能接；
RPC 是“打电话说密语+专用耳机”——更快更省，但双方得装同款APP、约定暗号。

🔹 声明式 vs 命令式

🌟 本质：
声明式 =“定义契约，框架实现”；
命令式 =“手写流程，自己掌控”。

🔹 Dubbo 为何比 Feign 更适合高并发场景

🔹 实际应用

• 📚Spring Cloud构建微服务架构：服务消费者（LoadBalancerClient、RestTemplate、FeignClient、Dubbo）
• 📚Spring Cloud Alibaba基础教程：Dubbo

2.5 熔断限流

🎈核心功能

🔑三大设计哲学（本质总结）：

• 零侵入：仅需@SentinelResource注解，规则全靠控制台配置；
• 强实时：秒级指标采集、毫秒级响应、内存保留5分钟（长期可对接 Prometheus）；
• 全维度：覆盖单机→集群→系统→链路→授权五层防护体系。

🎈代码实现

@SentinelResource(value = "xxx")是唯一必写代码；所有流控策略（QPS/线程/热点/Warm
Up/关联等）均通过控制台配置生效，零侵入、动态生效、无需重启应用。

🎈@FeignClient客户端（Feign + Nacos + Sentinel）

importcom.alibaba.csp.sentinel.annotation.SentinelResource;importcom.alibaba.csp.sentinel.slots.block.BlockException;importorg.springframework.cloud.openfeign.FeignClient;importorg.springframework.web.bind.annotation.GetMapping;importorg.springframework.web.bind.annotation.PathVariable;importjava.util.Map;// Feign 自动从 Nacos 发现 user-service 实例（需 application.yml 配置 nacos discovery）@FeignClient(name="user-service")publicinterfaceUserClient{@SentinelResource(value="feign-user-get",// 资源名（控制台规则匹配依据）blockHandler="blockHandler",// 流控/熔断触发fallback="fallback",// 远程异常触发（如 500、超时）fallbackClass=UserClientFallback.class// 静态 fallback 类)@GetMapping("/api/user/{id}")Map<String,Object>getUser(@PathVariable("id")Longid);}// ← 静态 fallback 类（必须 public static 方法，无 Spring 依赖）classUserClientFallback{publicstaticMap<String,Object>blockHandler(Longid,BlockExceptione){returnMap.of("id",id,"status","BLOCKED","reason",e.getClass().getSimpleName());}publicstaticMap<String,Object>fallback(Longid,Throwablet){returnMap.of("id",id,"status","FALLBACK","error",t.getMessage());}}

✅ 调用方式不变：userClient.getUser(123)→ 自动具备：

• ✅ Nacos 服务发现（负载均衡）
• ✅ Sentinel QPS/线程数限流
• ✅ 慢调用/异常比例熔断
• ✅ 全链路降级兜底

🎈@DubboReference客户端（Dubbo + Nacos + Sentinel）

importcom.alibaba.csp.sentinel.annotation.SentinelResource;importcom.alibaba.csp.sentinel.slots.block.BlockException;importorg.apache.dubbo.config.annotation.DubboReference;importorg.springframework.stereotype.Service;importjava.util.Map;@ServicepublicclassUserService{// Dubbo 自动从 Nacos 订阅 user-service 提供者（需 application.yml 配置 nacos registry）@DubboReferenceprivatecom.example.demo.service.UserServiceuserService;@SentinelResource(value="dubbo-user-get",// 资源名（独立于 Feign，可同名也可区分）blockHandler="blockHandler",fallback="fallback",fallbackClass=UserServiceFallback.class)publicMap<String,Object>fetchUser(Longid){returnuserService.getUser(id);// ← 原始 RPC 调用，Sentinel 在其外层织入保护}// 静态 fallback 方法（同上）staticclassUserServiceFallback{publicstaticMap<String,Object>blockHandler(Longid,BlockExceptione){returnMap.of("id",id,"status","DUBBO_BLOCKED","reason",e.getClass().getSimpleName());}publicstaticMap<String,Object>fallback(Longid,Throwablet){returnMap.of("id",id,"status","DUBBO_FALLBACK","error",t.getMessage());}}}

✅ 调用方式不变：userService.fetchUser(123)→ 自动具备：

• ✅ Nacos 服务发现（Dubbo provider 列表）
• ✅ Sentinel 对Dubbo consumer 端的全维度防护（方法级资源）
• ✅ 支持@DubboReference(check=false)避免启动报错，与 Sentinel fallback 协同更健壮

🔹 实际应用

• 📚Spring Cloud Alibaba基础教程：Sentinel

2.6 分布式事务

• 📚Spring Cloud Alibaba基础教程：Seata

2.7 消息队列

• 📚Spring Cloud Alibaba基础教程：RocketMQ

3 Mall4j商城实战

• 📚mall4j 商城实战