企业官网建设流程全解析

开门见山

架构师干的所有事，归结为一句话：

在约束条件下做取舍，并承担后果。

不是画图，不是选型，不是写文档。那些都是取舍的载体。取舍本身，才是架构。

一、开发者和架构师看同一个问题的区别

一个需求丢过来：“我们要做一个消息推送系统。”

开发者想的是：

• 用什么MQ？
• 消息体怎么定义？
• 接口怎么写？

架构师想的是：

• 推送给谁？一个人还是一千万人？
• 推送频率？一天一条还是每秒一万条？
• 丢一条消息，业务能不能忍？忍多久？
• 团队现在会什么？给我多少时间？多少机器？
• 这套东西上线之后，下一步业务最可能往哪个方向变？

看出区别了吗？

开发者从方案出发。架构师从约束出发。

方案是无限的，Redis、Kafka、RocketMQ、自研，都能推消息。但约束是有限的——时间、人力、钱、团队技能、业务容忍度——这些东西框死之后，方案空间会急剧收缩，最后剩下的那一两个选择，就是你的架构。

二、架构设计的真实过程

不是灵感一现画出一张漂亮的图。是下面这个过程：

第一步：把模糊的问题变成具体的数字

"高并发"不是需求。“双十一峰值每秒12万笔订单、平均响应200ms以内、数据不能丢”——这才是需求。

你没有数字，就没有架构。因为你不知道你在对抗什么量级的力。

做法很暴力：逼业务方给数字，给不出就自己估，估完让业务方确认。

日活用户 × 人均操作次数 ÷ 活跃秒数 = 峰值QPS的量级

有了数字，你才知道单机扛得住还是扛不住，才知道要不要引入缓存、要不要拆服务、要不要异步化。

第二步：画出数据怎么流动

不要上来就画组件框图。先画数据：

一条数据从产生到最终被消费，经过了哪些节点？在每个节点停留多久？变成了什么形态？

用户下单 → 订单写入DB → 发消息到MQ → 库存服务消费扣减 → 结果回写 ↓ 推送服务消费 → 通知用户

数据流画清楚了，系统的骨架就出来了。剩下的组件选型，只是在骨架上填肉。

第三步：对每个节点问"它会怎么死"

这一步是区分PPT架构师和实战架构师的分水岭。

你不需要把所有死法都防住——你需要知道每种死法的代价是什么，然后决定哪些值得防、哪些可以忍。

这就是取舍。

第四步：为每个选型写下"为什么不选另一个"

选了Kafka——为什么不选RocketMQ？
选了最终一致——为什么不选强一致？
选了单体——为什么不拆微服务？

如果你只能说出"选了什么"，却说不出"为什么不选另一个"，说明你没做过真正的决策，只是在跟风。

好的架构决策记录长这样：

决策：消息队列选用 Kafka 备选方案： A. RocketMQ — 支持事务消息，但团队无人熟悉，运维成本高 B. Kafka — 团队三人有生产经验，社区成熟，吞吐量满足需求 C. Redis Stream — 轻量，但持久化保障不够，消息量大时内存扛不住 决策依据： - 团队熟悉度（最重要，三个月内要上线） - 吞吐量满足（日均2000万条消息） - 不需要事务消息（业务容忍最终一致） 代价： - 放弃了事务消息能力，后续如果需要，要额外补偿机制

三、架构品味：什么是好，什么是烂

技术能力决定你能不能做。品味决定你做出来的东西是不是好的。

好架构的特征

1. 简单到让人觉得"显而易见"

看到一个架构图，第一反应是"这不是理所当然的吗？"——这恰恰说明它好。好架构不让人觉得聪明，让人觉得自然。

2. 改一个需求，只动一个地方

如果加一个消息类型，要改五个服务的代码——这架构烂了。

3. 能说清楚什么不做

好架构有清晰的边界。“这套系统不负责 XXX，那是另一套系统的事”——说得清这句话，说明你想明白了。

烂架构的气味

你一看就知道它烂，但很多人说不出为什么。我帮你总结：

• 为了"将来可能需要"而加的抽象层— 将来90%的情况下不会需要
• 所有服务都通过一个"万能中间层"通信— 单点、黑盒、出了问题谁都查不出
• 微服务拆了20个，但共享同一个数据库— 你拆了个寂寞，耦合全在DB层
• 到处写着TODO和临时方案，但从来没人回来改— 不是技术债，是技术烂账

四、后端系统的三层审视法

任何后端项目，不管多复杂，本质上只有三层关注点。架构师的工作，就是在这三层之间反复穿梭、反复校验：

┌─────────────────────────────────────────────────┐ │ 功能层 — 系统做什么 │ │ "需求对不对、逻辑通不通、边界全不全" │ ├─────────────────────────────────────────────────┤ │ 设计层 — 系统怎么做 │ │ "性能够不够、一致性怎么保、扩展性怎么留" │ ├─────────────────────────────────────────────────┤ │ 工程层 — 系统怎么活 │ │ "怎么上线、怎么监控、怎么回滚、怎么不烂掉" │ └─────────────────────────────────────────────────┘

大多数人只关注功能层——“能跑就行”。少数人关注设计层——“跑得好”。极少数人关注工程层——“跑得久”。

而真正的架构师，三层同时看。

五、八维检查清单

当你做架构设计、做方案评审、或者面试被追问"还有吗"的时候——心里默扫这张清单：

□ 功能正确性

正常路径能跑通只是及格。异常路径才见功力。

• 参数非法怎么办？
• 并发写入同一条数据怎么办？
• 上游重试导致重复请求怎么办（幂等）？
• 中间某一步失败了，已经执行的步骤要不要回滚？

□ 性能

别猜，量化。

• 热路径是哪条？（80%的流量走哪个分支）
• 有没有N+1查询、全表扫描、无效循环？
• 缓存加在哪？命中率预估多少？穿透了怎么兜底？
• 响应时间的P99是多少，不是平均值——平均值骗人。

□ 扩展性

下一个需求来的时候，是加一行配置还是改三个服务？

• 加一种新类型/新规则，要动几个文件？
• 有没有策略模式、插件机制、配置化的口子？
• 接口设计是否向前兼容？老客户端升不了级怎么办？

□ 可观测性

出了问题，能不能在5分钟内定位到根因。

• 关键路径有没有traceId串联？
• 错误日志是否带上了上下文（用户ID、请求参数、耗时）？
• 核心指标是否有dashboard（QPS、延迟、错误率）？
• 告警阈值设了没？告警了谁来响应？

□ 运维

代码写完才完成了30%。上线、变更、回滚才是剩下的70%。

• 配置变更需要重启吗？能不能热加载？
• 灰度策略是什么？先放1%流量还是先放内部用户？
• 回滚要多久？回滚后数据兼容吗？
• 数据库有DDL变更，怎么做到不停服？

□ 安全

你以为没人会攻击你的系统，直到有人真的来了。

• 接口鉴权在哪一层做？网关还是服务内部？
• 用户A能不能通过篡改参数看到用户B的数据？
• 敏感字段（手机号、身份证）存储和日志里脱敏了没？
• SQL注入、XSS这些基本功，框架兜底了还是要手动处理？

□ 一致性

分布式系统里没有"一定一致"，只有"多久之后一致"和"不一致了怎么修"。

• 缓存和DB之间的一致性窗口是多长？业务能忍吗？
• 跨服务调用失败，数据会不会处于中间状态？
• 有没有对账机制？多久跑一次？发现不一致了怎么修复？

□ 演化

最难的问题不是"今天怎么设计"，而是"两年后这个系统会烂成什么样"。

• 哪些地方是你现在就知道会变的？（预留口子）
• 哪些地方是你赌它不会变的？（赌输了代价多大）
• 代码里有没有"临时方案"正在悄悄变成永久方案？
• 团队人员流动后，新人能不能在一天内看懂核心链路？

六、怎么用这张清单

场景一：做架构设计时

画完数据流之后，拿清单逐条过一遍。不需要每条都有完美方案，但每条你都要有明确的态度——要么"我做了"，要么"我决定先不做，因为……"。

场景二：做方案评审时

别人讲方案的时候，你心里拿这八条默扫。找到他没提到的那一两条，提问——这就是高质量的评审意见。

场景三：面试被追问时

面试官问"还有吗"，你不需要慌。扫一眼清单，找到还没提到的维度，换个层面展开——每换一个维度，你就在展示自己看问题的立体程度。

七、怎么练出这种能力

不讲虚的，三件事：

1. 对你正在做的系统，拿清单过一遍

你会发现很多条你答不上来。答不上来的那些，就是你系统里正在裸奔的风险。

2. 每做一个技术决策，写三行字

选了什么 / 为什么选它 / 放弃了什么

坚持三个月，你会发现自己开始能"说出为什么"了。这就是架构思维的起点。

3. 读"反转故事"

• 从微服务回归单体的案例
• 从云上搬回自建机房的案例
• 从分布式缓存退回本地缓存的案例

这些故事告诉你：没有绝对正确的方案，只有当下约束下的最优解。约束变了，最优解就变了。

最后

架构师不神秘。

他只是那个愿意在动手之前多想十分钟"为什么"的人。
他只是那个能把模糊问题逼成具体数字的人。
他只是那个敢说"这个方案有缺陷，但在当前约束下我接受这个代价"的人。
他只是那个脑子里有一张清单，对每个