第二章技术选型与架构设计

技术选型和架构设计，说白了就是给项目「搭骨架」。骨架搭得好，后面写代码就像拼乐高；搭不好，那就是在烂泥里打滚。我见过太多项目，一开始图省事随便选了个技术栈，结果半年后重构成本比重新写一套还高。

这一章，我把这些年踩过的坑和总结的经验都摊开来讲。你想想看，选技术就像挑工具——锤子再好，也不能拿来拧螺丝对吧？

2.1 技术选型原则

技术选型没有银弹，但有几条铁律。我个人习惯先问三个问题：团队会什么？业务要什么？社区活不活跃？

核心原则：

团队匹配度——选团队熟悉的技术，别为了炫技选冷门框架
业务适配性——高并发选 Go/Java，快速原型选 Python/Ruby
社区生态——活跃社区意味着坑有人填，问题有人答
长期维护成本——别选那种「三年不更新」的库

我在项目中遇到过一件事：有个团队非要上 Rust 做 Web 后端，理由是「性能好」。结果招人招了三个月，项目延期半年。嗯，这里要注意——技术选型不是选「最好的」，而是选「最合适的」。

避坑指南：我曾经在一个电商项目里选了 MongoDB 做订单存储，理由是「灵活」。结果到了对账环节，复杂查询慢得像蜗牛。最后不得不加了一层 Elasticsearch 做查询缓存。所以啊，关系型数据还是老老实实用 MySQL 或 PostgreSQL。

2.2 分层架构设计

分层架构是最经典的架构模式，没有之一。它的核心思想就一句话：各司其职，互不干扰。

我习惯把系统分成四层：

层级	职责	常见技术
表现层	处理用户交互、数据展示	React、Vue、Spring MVC
业务层	核心业务逻辑、规则校验	Service 层、领域模型
数据访问层	数据库 CRUD、缓存操作	MyBatis、JPA、Redis
基础设施层	消息队列、文件存储、日志	Kafka、MinIO、ELK

为什么会这样分层？说白了就是为了「解耦」。表现层改了，业务层不用动；数据库换了，业务层也不用动。我刚开始做架构时，把所有代码都塞在一个 Controller 里，后来改需求改到想哭。

// 错误示范：所有逻辑堆在 Controller
@RestController
public class OrderController {
    @PostMapping("/create")
    public String createOrder(@RequestBody Order order) {
        // 校验参数
        // 查库存
        // 扣库存
        // 生成订单
        // 发消息通知
        // 返回结果
        return "success";
    }
}

// 正确做法：分层清晰
@RestController
public class OrderController {
    @Autowired
    private OrderService orderService;

    @PostMapping("/create")
    public Result createOrder(@RequestBody OrderDTO dto) {
        return orderService.createOrder(dto);
    }
}

注意：分层不是越多越好。我见过有人分了七层，结果一个简单的查询要穿越五个类。记住：分层是为了降低复杂度，不是增加复杂度。

2.3 单体架构 vs 微服务架构

这个话题吵了好几年了。我的态度很明确：能用单体就别上微服务。

你想想看，微服务带来的分布式事务、服务发现、链路追踪、配置中心……哪一个不是坑？我见过一个创业公司，总共 5 个人，硬要拆 8 个微服务，结果每天光部署就要花半天。

那什么时候该上微服务？我总结了三个信号：

团队规模超过 20 人——人多了，代码冲突频繁，单体编译慢
业务模块天然独立——比如订单和用户，几乎没有强耦合
需要独立扩缩容——某个模块流量暴增，其他模块不需要跟着扩容

我的建议：先做单体，把业务跑通。等真的遇到瓶颈了，再按「绞杀者模式」逐步拆微服务。别一开始就搞分布式，那是给自己挖坑。

2.4 架构选型决策矩阵

为了方便你做决策，我整理了一个表格。每次选型时，对着打分就行：

评估维度	单体架构	微服务架构
开发效率	⭐⭐⭐⭐⭐	⭐⭐⭐
部署复杂度	⭐⭐⭐⭐⭐	⭐⭐
扩展性	⭐⭐	⭐⭐⭐⭐⭐
故障隔离	⭐	⭐⭐⭐⭐
团队要求	低	高
运维成本	低	高

说白了，选架构就是做 trade-off。没有完美的架构，只有适合当前阶段的架构。我记得有个前辈说过一句话：「架构是演进来的，不是设计出来的。」深以为然。

个人经验：如果你拿不准选什么，那就选你团队最熟悉的技术栈，用最朴素的分层架构。先把业务跑起来，再考虑优化。80% 的项目根本活不到需要微服务的那一天。

2.5 本章小结

这一章我们聊了技术选型的四条铁律，看了分层架构怎么搭，也对比了单体和微服务的优劣。核心就一句话：别为了技术而技术，技术是服务于业务的。

下一章，我们会进入实战——从零搭建一个项目的目录结构。到时候我会手把手带你搭一个「看着就专业」的项目骨架。

📚 课程目录

第二章 技术选型与架构设计

2.1 技术选型原则

2.2 分层架构设计

2.3 单体架构 vs 微服务架构

2.4 架构选型决策矩阵

2.5 本章小结

第二章技术选型与架构设计