初识微服务架构：从单体到拆分，看懂核心原理与实战

初识微服务架构：从单体到拆分，看懂核心原理与实战

前言

在后端开发演进过程中，单体应用和微服务架构是绕不开的两个核心概念。刚接触微服务时，容易被RPC、注册发现、服务通信等名词绕晕。其实微服务本质并不复杂——它就是把庞大的单体项目，按业务拆分成多个独立、轻量的小服务，再通过通信机制协同工作。

---

一、单体应用 vs 微服务架构：核心区别

1. 单体应用（Monolith）

定义：所有业务功能（用户、订单、商品、支付等）都写在同一个项目、同一个代码库、同一个部署包中，共用一个数据库，统一打包、发布、运行。

优点：

• 开发简单，无需考虑分布式问题
• 本地调试、部署成本低
• 适合小型项目、初创团队

缺点：

• 代码臃肿，后期维护难度飙升
• 单体项目存在并发能力受限的问题。单体内部想要 “同时执行多个任务”，只能靠多线程 / 线程池。即使在单体里引入消息队列，想让消息被 “并行处理”，底层依然依赖多线程。
• 一处修改，全量重启，影响整个系统
• 无法单独扩容，性能瓶颈难以优化
• 技术栈固化，难以灵活升级

2. 微服务架构（Microservices）

定义：按照业务领域，将大系统拆分为多个独立的小服务（用户服务、订单服务、商品服务等），每个服务都是一个小型单体项目，独立开发、部署、运维，甚至可使用不同技术栈。

核心特点：

• 单一职责：一个服务只做一件事
• 独立部署：互不影响，支持灰度发布
• 独立数据库：数据解耦，避免单点故障
• 服务自治：团队可独立维护

3. 极简对比表

维度	单体应用	微服务架构
代码结构	一个项目包	多个独立服务项目
部署方式	整体打包部署	单个服务独立部署
数据存储	共用一个数据库	服务独立数据库/数据自治
故障影响	一处故障，整体瘫痪	单个服务故障，不影响核心流程
技术栈	统一固定	灵活选择，服务间可不同
适用场景	小型项目、快速迭代初期	中大型项目、高并发、复杂业务

一句话总结：微服务 = 把大单体拆成多个小单体，通过网络通信协同工作。

---

二、微服务基础结构：一个服务包含哪些模块？

微服务不是随便拆分，每个服务内部都有规范的模块划分，常见结构：

eq-manage-service-master   👈 这是【一个微服务】
   ├── eq-manage-common    👈 自己内部的公共模块（给内部用）
   ├── eq-manage-data-api  👈 数据接口
   ├── eq-manage-data      👈 数据实现
   └── eq-manage-start     👈 启动入口

这四个是兄弟关系，一起组成一个微服务。

所以：

• start 要依赖 common
• data 要依赖 common
• data-api 也要依赖 common

它是你自己内部共用，不是给外部微服务用的。

这些模块属于同一个微服务，只服务当前业务，不跨服务共享（公共能力可抽离为独立依赖包）。

---

三、微服务核心：服务间如何通信？

微服务拆分后，必须通过网络通信实现数据交互，主流有3种方式：HTTP、RPC、消息队列。

1. HTTP（RESTful）通信

特点：基于HTTP协议，通用、跨语言、调试简单，是Spring Cloud生态主流方案。
实现：OpenFeign（声明式调用）。
适用场景：跨平台、对外接口、通用服务调用。

@FeignClient("user-service")
public interface UserClient {
    @GetMapping("/user/{id}")
    User getUserById(@PathVariable Long id);
}

HTTP 是微服务之间的通信方式，本身不需要注册中心就能调用；而注册中心（如 Nacos）是为了解决服务地址管理、动态发现、负载均衡的问题，让微服务在集群、扩缩容、多实例部署时，能够稳定、灵活、自动化地运行。简单说：HTTP 负责 “通话”，注册中心负责 “找人”。

2. RPC 远程过程调用

定义：像调用本地方法一样调用远程服务，RPC 性能高 = 传输更快 + 解析更快 + 体积更小；所以访问速度、响应速度确实比 HTTP 更快。。
RPC是概念，具体实现：Dubbo、gRPC。
核心流程：

1. 抽离公共接口包（common-api.jar），只定义接口，不实现
2. （被调用方）服务提供者实现接口，override。服务提供者去实现 common.jar 里的接口，「重写接口方法」。
3. 服务消费者（调用方）引入依赖包，直接调用方法
4. 底层框架自动完成网络通信

适用场景：后端内部服务、高并发、低延迟需求。

3. 消息队列（异步通信）

特点：解耦、削峰、异步，不阻塞主流程。
常用组件：Kafka、RocketMQ、RabbitMQ。
适用场景：订单创建→通知物流、支付成功→更新积分等非实时强一致业务。

@Service
public class OrderService {

    @Autowired
    private KafkaTemplate<String, Object> kafkaTemplate;

    // 创建订单
    public void createOrder(Order order) {
        // 1. 执行业务：保存订单、扣库存...
        orderMapper.insert(order);

        // 2. 发送消息到 Kafka，不阻塞
        OrderCreateMessage msg = new OrderCreateMessage();
        msg.setOrderId(order.getId());
        msg.setPhone(order.getUserPhone());
        msg.setContent("您的订单已创建，订单号：" + order.getId());

        // 发送到主题：order_topic
        kafkaTemplate.send("order_topic", msg);
    }
}

---

四、微服务核心：服务注册与发现（Nacos）

微服务数量多、IP端口动态变化，必须用注册中心统一管理。
主流组件：Nacos（同时支持注册中心+配置中心）。

核心流程：

1. 微服务启动时，将自己的服务名、IP、端口注册到Nacos
2. 调用方从Nacos获取目标服务地址列表
3. 框架自动实现负载均衡

配置步骤：

1. 引入Nacos依赖
2. 配置文件填写Nacos地址
3. 启动服务，自动注册

---

五、结语

微服务不是银弹，小型项目没必要强行使用；但中大型、高并发、多团队协作项目中，微服务能极大提升研发效率、系统稳定性和扩展性。

初学者不用追求一步到位，先理解拆分思想、通信方式、注册发现三大核心，再动手跑通Demo，就能快速入门微服务架构。

后续可深入学习：微服务网关、配置中心、熔断降级、分布式事务、链路追踪等进阶内容。