架构原则概述：架构的定义、架构的演进、架构设计的目标

聊到架构，很多人第一反应是「高大上」的东西。其实没那么玄乎。

我个人的理解，架构就是一组有意识的、提前做好的设计决策。说白了，就是你在写代码之前，先想清楚这系统长什么样、各模块怎么配合、出了问题怎么兜底。

你想想看，盖房子总得先有图纸吧？架构就是软件世界的图纸。没有图纸，你也能砌墙，但砌到三层发现承重不够，那就得拆了重来。我在项目中遇到过好几次这种「先干再说」的团队，最后无一例外都返工了。

架构的定义

架构这个词，其实包含两个层面：

• 结构层面：系统由哪些组件构成，组件之间怎么连接、怎么通信。
• 行为层面：系统在运行时如何响应请求、如何处理故障、如何扩展。

我记得有一次评审一个电商系统的架构，对方画了张很漂亮的拓扑图，各种微服务、消息队列、缓存一应俱全。但我问了一句：「如果订单服务挂了，用户还能不能浏览商品？」对方愣住了。嗯，这就是典型的只画了结构，没想清楚行为。

说白了，架构就是你在「功能实现」和「非功能约束」之间做的权衡。没有完美的架构，只有合适的架构。

架构的演进

架构不是一天变成今天这样的。我从业十几年，亲眼看着它一步步走过来。咱们捋一捋。

单体架构

最早期的架构，就是一个大包。所有代码写在一起，部署在一台服务器上。数据库、前端页面、业务逻辑，全在一个进程里跑。

好处很明显：简单。开发快，部署快，调试也方便。我刚开始做项目时，一个Tomcat搞定一切，连负载均衡都不需要。

但坏处也致命：

• 改一行代码要重新部署整个应用
• 某个模块出问题，整个系统都崩
• 没法针对热点模块单独扩容

我曾经维护过一个单体老系统，每次发布都要停机半小时。后来业务量上来了，用户一多，系统直接卡死。没办法，只能拆。

SOA（面向服务架构）

单体扛不住了，大家开始想：能不能把系统拆成几个独立的服务？每个服务负责一块业务，服务之间通过某种协议通信。

这就是SOA的由来。它引入了几个关键概念：

• 服务：独立部署的业务单元
• ESB（企业服务总线）：服务之间的通信枢纽
• 服务注册与发现：让服务能找到彼此

SOA在当时是个大进步。我记得2010年左右，很多大厂都在推SOA。但实践中也暴露了问题：ESB太重了，成了新的单点瓶颈。而且服务划分的粒度不够细，很多时候还是「大服务」套「小服务」。

微服务架构

微服务可以看作是SOA的进化版。它把服务拆得更细了——每个服务只做一件事，而且做得足够好。

微服务的关键特征：

• 单一职责：一个服务只负责一个业务能力
• 独立部署：每个服务可以独立发布、升级
• 去中心化：没有ESB这种中心组件，服务之间直接通信
• 技术异构：不同服务可以用不同的语言、数据库

但微服务也不是银弹。我见过不少团队，一上来就拆了20个微服务，结果发现：

• 服务间调用链太长，一个请求要经过七八个服务
• 分布式事务搞不定，数据不一致
• 运维成本飙升，光监控告警就够喝一壶的

三种架构的对比，我整理了一张表：

维度	单体架构	SOA	微服务
服务粒度	粗（整个应用）	中（业务模块）	细（单一能力）
通信方式	进程内调用	ESB/消息中间件	HTTP/RPC/消息
部署方式	单机部署	集群部署	容器化/独立部署
扩展性	差（整体扩展）	中（按服务扩展）	好（按需扩展）
运维复杂度	低	中	高
适用场景	小团队、简单业务	中型企业、系统集成	大型互联网、高并发

下面这张图，展示了架构演进的核心脉络：

架构设计的目标

说了这么多，架构设计到底图个啥？我个人总结，核心目标就四个：

1. 可用性：系统不能动不动就挂。99.9%和99.99%的可用性，差的不只是一个小数点，而是整个架构的冗余设计。
2. 可扩展性：业务量涨了，加机器就能扛住。而不是推倒重来。
3. 可维护性：新同事接手代码，能看得懂、改得了。不是只有原作者才能维护。
4. 安全性：数据不被泄露，系统不被攻破。这个不用多说。

嗯，这一章的内容就到这里。架构是个大话题，后面我们会逐一深入每个原则和模式。慢慢来，不着急。