架构师思维：从"写好代码"到"做好取舍"的认知跃迁
从宇信科技的初级开发到凯士比的中级开发+项目管理，再到趣玩搭的开发主管+初级架构师。这篇文章不是技术文章，而是一篇关于角色认知转变的复盘——架构师到底和高级开发有什么区别？以及一个真实的架构决策案例，聊聊"取舍"这件事。
一、三段经历的认知变化
1.1 宇信科技（2019-2021）：学会"做对"
在宇信做银行信贷系统开发的两年，我的核心能力是"把需求文档翻译成代码"。领导给了接口文档和表结构，我按照规范写 CRUD、写审批流程、写单元测试。做得好的标准是：代码能跑、功能正确、Bug少、按时交付。
这个阶段我关注的是"怎么做对"——用正确的方式实现正确的功能。
1.2 凯士比（2021-2024）：学会"做好"
到了凯士比，角色从纯开发变成了"开发 + 项目管理"。我不只是写代码，还要参与需求评审、设计数据库、制定开发计划、做代码 Review。
这个阶段最大的变化是我开始关注"怎么做好"——同样是实现一个功能，用什么数据结构更高效？SQL 怎么写性能更好？接口怎么设计扩展性更强？开始有了"非功能性需求"的意识：性能、可用性、可维护性。
但说实话，这个阶段的"设计"更多是局部优化——在已有架构的框架内，把自己负责的模块做到最好。架构层面的决策（选什么技术栈、服务怎么拆、数据怎么流）还是由团队中更资深的同事主导。
1.3 趣玩搭（2025-至今）：学会"做取舍"
加入趣玩搭后，作为开发主管和初级架构师，我第一次需要对一个系统的整体架构负责。没有更资深的人替我做决策了——技术栈选型、服务拆分方案、中间件选择、部署架构，都要我来做决定（当然也会和团队讨论，但最终决策是我的责任）。
这才让我真正理解了架构师和高级开发的核心区别。
二、核心区别：视角不同、责任不同
2.1 高级开发：深度思维
高级开发是"局部最优"的追求者。给定一个模块、一个需求，他能用最优的算法、最合理的设计模式、最高效的代码来实现。他的价值在于深度——把一个点做到极致。
高级开发关注的问题：这段代码的时间复杂度是多少？有没有线程安全问题？接口的入参出参怎么设计更合理？异常怎么处理更优雅？
2.2 架构师：广度 + 取舍思维
架构师是"全局次优"的决策者。他需要在时间、人力、预算、技术成熟度、团队能力等多重约束下，做出一个不完美但合理的整体方案。
架构师关注的问题：这个功能该放在哪个服务里？同步调用还是异步消息？要不要引入新的中间件？数据一致性要求到什么级别？如果这个选型是错的，切换成本有多大？
最核心的区别是"取舍"。 高级开发在大多数情况下追求的是"最好的方案"（最高性能、最优设计）。而架构师面对的几乎每个决策都不存在"最好的方案"——只有"在当前约束下最合适的方案"。每个选择都有代价，架构师的职责是评估代价、做出决策、并为决策负责。
2.3 一句话总结
高级开发解决的是"how"——怎么把事情做好。架构师解决的是"what"和"why"——做什么、不做什么、为什么这样做。
三、一个真实的架构决策案例：IM 方案的选型
3.1 背景
趣玩搭的社交属性决定了即时通讯（IM）是核心功能——用户报名活动后自动进入活动群聊，活动前的沟通、活动中的互动、活动后的约下一场，都依赖 IM。
IM 的需求看起来很明确：支持单聊和群聊，支持文字/图片/语音消息，支持消息已读/未读，支持离线消息推送。
但在"怎么实现"这件事上，我面临了一个典型的架构取舍。
3.2 三个备选方案
方案 A：接入第三方 IM 云服务（融云/环信/腾讯IM）
直接用成熟的 IM SDK，前端集成 SDK 即可，后端几乎不用开发。
优点：开发周期最短（1-2 周），稳定性有保障（百万级并发验证过），不需要专人维护。
缺点：月费不低。以融云为例，按 DAU 计费，1 万 DAU 的价格约 ¥3,000-5,000/月。随着用户增长，成本会线性上升。而且消息数据存储在第三方，涉及用户隐私合规问题。业务定制灵活度有限——比如"用户退出活动后自动退群并清除消息"这种和业务深度耦合的需求，第三方 SDK 不一定支持。
方案 B：基于开源 IM 框架自建（如 OpenIM、Turms）
部署开源 IM 服务端，客户端用对应的 SDK。
优点：数据自控，长期成本低（只有服务器费用），可深度定制。
缺点：开源 IM 框架的学习和部署成本不低，文档质量参差不齐。遇到 Bug 要靠社区或自己排查，没有商业支持。对团队的 IM 领域经验有要求——我们团队没人做过 IM。
方案 C：自研轻量 IM 模块
基于 Spring Boot + WebSocket + Redis + RocketMQ 自己实现一套简化版 IM。
优点：完全自控，和业务系统无缝集成，功能裁剪到刚好够用。
缺点：开发周期长（预估 4-6 周），需要处理消息可靠投递、离线消息、多端同步等复杂问题，长期维护成本高。自己造轮子意味着踩坑得自己填。
3.3 我的决策过程
这个决策我纠结了三天。三个方案各有利弊，没有一个是完美的。
第一步：明确约束条件。
时间约束：产品要求 IM 功能 3 周内上线（有投资人 demo）。方案 C 的 4-6 周直接超期，排除。
预算约束：月均 AI 预算已经占了 ¥8,000，如果 IM 再花 ¥5,000/月，对初创团队来说压力很大。方案 A 的成本虽然不低，但在 1 万 DAU 阶段还能接受，问题在于 10 万 DAU 时可能飙到 ¥30,000-50,000/月。
团队约束：4 个后端都没有 IM 经验。方案 B 的学习成本在时间约束下不可接受。
第二步：评估最大风险。
方案 A 的最大风险是"成本不可控"和"被第三方锁定"。方案 B 的最大风险是"踩坑后排查成本高"和"可能延期"。
第三步：做出决策并设计退出路径。
最终选择了方案 A（接入融云），但同时做了两件事来对冲风险：
第一，设计了 IM 抽象层。所有业务代码不直接调用融云 SDK，而是通过一个 IMService 接口调用。后续如果要切换到自研或其他方案，只需要替换实现类，业务代码不用动。
public interface IMService {
void sendMessage(String fromUserId, String toUserId, IMMessage message);
void createGroup(String groupId, List<String> memberIds);
void dismissGroup(String groupId);
void addGroupMember(String groupId, String userId);
void removeGroupMember(String groupId, String userId);
List<IMMessage> getOfflineMessages(String userId, long sinceTimestamp);
}
// 当前实现：融云
@Service
public class RongCloudIMServiceImpl implements IMService { ... }
// 未来可替换为：自研实现
// public class SelfHostedIMServiceImpl implements IMService { ... }第二，在技术路线图中规划了"用户达到 10 万 DAU 时评估切换自研"。到那个时候，团队规模和技术积累应该足以支撑 IM 自研，而且成本节省也足够明显。
3.4 决策的后续验证
上线 3 个月后回看这个决策：
做对了的地方： 3 周内 IM 功能按时上线，投资人 demo 顺利完成。融云的稳定性确实省了很多心，上线以来 IM 相关的故障为零。抽象层在后续对接"用户退出活动自动退群"等定制需求时也派上了用场——在 IMService 上扩展方法就行。
需要反思的地方： 融云的文档质量一般，群聊人数上限、消息存储天数等限制在文档中写得不清楚，实际踩了几个坑。月均 IM 成本约 ¥2,800（比预估低，因为并非所有活跃用户都使用 IM），在可接受范围内。
如果重新选一次？ 在同样的约束条件下，我还是会选方案 A。但如果时间约束放宽到 6 周，我会认真考虑方案 B（OpenIM），因为它的长期成本更低。
3.5 这个案例的启示
架构决策不是选"最好的"，而是选"约束条件下最合理的"。 方案 C（自研）从技术完美性角度是最好的，但在时间和团队约束下不可行。方案 A 从技术角度是"最偷懒的"，但在当前阶段是最务实的。
架构决策必须附带退出路径。 任何技术选型都可能是错的。好的架构师不是能做出永远正确的决策，而是在做决策时就想好了"如果错了怎么办"。IM 抽象层就是退出路径——即使融云不靠谱，我们也能在合理成本内切换。
架构决策要明确"决策有效期"。 我在做这个决策时就明确说了"这个方案适用于 10 万 DAU 以下，超过后要重新评估"。这不是推卸责任，而是承认每个方案都有适用范围。
四、架构师的日常：不是画图，而是做判断
4.1 我的日常工作构成
很多人以为架构师的日常就是画架构图、写技术方案文档。实际上在趣玩搭这样的初创团队中，架构师（或者说兼任架构师的开发主管）的日常是：
30% 做技术判断。 团队遇到技术分歧时做最终决策——用 A 方案还是 B 方案？这个功能该放在哪个服务里？要不要引入一个新的中间件？
30% 写核心代码。 团队只有 4 个后端，我不可能不写代码。我负责最复杂的模块（支付、分布式事务、AI 集成），其他同事负责常规的业务 CRUD。
20% 做 Code Review。 确保团队的代码质量和架构一致性。最常见的 Review 意见不是"这段代码写得不好"，而是"这个功能不应该放在这个服务里"或"这个场景不需要用分布式事务"。
20% 做技术规划和问题排查。 包括制定技术路线图、排查线上疑难问题、做性能调优等。
4.2 从"自己写代码"到"让别人写好代码"
这是角色转变中最难的一关。作为高级开发，我的价值体现在自己写出好代码。作为架构师，我的价值体现在让整个团队写出好代码。
具体做法：制定编码规范和最佳实践文档（不是教科书式的，而是从项目中沉淀的实战规范）；建立 Code Review 文化（每个 PR 必须至少一个人 Review 才能合入）；搭建好脚手架和基础设施（统一异常处理、统一日志格式、统一接口规范），降低团队犯错的概率。
五、给希望走架构路线的开发者的建议
第一，先把代码写好。 没有扎实的编码功底，做架构决策就像没上过战场的人指挥打仗。至少要有 3-5 年的深度开发经验，踩过足够多的坑。
第二，刻意训练"系统思维"。 每次做需求开发时，多想一步：这个功能如果用户量翻 10 倍会怎么样？如果这个依赖挂了会怎么样？如果需求变了这个设计还能用吗？把自己从"实现者"拉到"设计者"的视角。
第三，学会接受不完美。 初入架构角色最大的痛苦是发现每个方案都有缺陷、每个决策都有代价。完美主义会让你陷入无尽的纠结。接受"没有完美方案，只有当下最合适的方案"，然后做决策、承担责任、往前走。
第四，多和不同角色的人沟通。 架构师需要理解业务（和产品经理聊）、理解用户（和客服聊）、理解成本（和财务聊）、理解运维（和运维聊）。只懂技术的架构师，做出的架构可能技术上完美但业务上不可用。
第五，持续学习，但不追逐热点。 技术热点每年都在变（前几年是微服务、今年是 AI），但架构的底层逻辑不变：高内聚低耦合、单一职责、关注点分离、为变化而设计。把精力花在理解底层原理上，而不是追逐每一个新框架。
六、写在最后
回顾这 6 年的成长路径，从"写好每一行代码"到"做好每一个取舍"，最大的认知变化是：技术是为业务服务的，架构是为团队服务的。 再好的架构如果团队 hold 不住，就是坏架构。再烂的架构如果能支撑业务跑起来，就有价值。
架构师不是一个"高人一等"的角色，而是一个"承担更多责任"的角色。你需要为自己的每一个决策负责——选对了是团队的功劳，选错了是你的锅。这份责任感，是架构师最核心的素质。
如果这篇文章对你有帮助，欢迎访问我的博客 robinzhu.top 获取更多实战分享。