架构思维：从代码实现到系统思维的进阶之路

引言

一、架构设计认知：解耦的艺术与效率革命

系统拆分案例分析

某平台遭遇严重性能瓶颈，交易系统频繁超时。原单体架构中订单处理、促销计算、报价生成三个模块相互耦合：

请问： 为什么还要做系统架构拆分？而且拆分之后会带来其他的复杂度，是怎么考虑的？

系统拆分的架构设计问题，可以从以下四个层面的回答。

• 从订单系统层面来看，由于交易流程中的订单系统相对来说业务稳定，不存在很多的迭代需求，如果耦合到整个交易系统中，在其他功能发布上线的时候会影响订单系统，比如订单中心的稳定性。基于这样的考虑，需要拆分出一个独立的子系统。

• 从促销系统层面来看，由于促销系统是交易流程中的非核心系统，出于保障交易流程稳定性的考虑，将促销系统单独拆分出来，在发生异常的时候能让促销系统具有可降级的能力。

• 从报价系统层面来看，报价是业务交易流程中最为复杂和灵活的系统，出于专业化和快速迭代的考虑，拆分出一个独立的报价系统，目的就是为了快速响应需求的变化。

• 从复杂度评估层面来看，系统拆分虽然会导致系统交互更加复杂，但在规范了 API 的格式定义和调用方式后，系统的复杂度可以维持在可控的范围内。

这样的分解其实对系统设计有个一个比较深刻的思考与理解。因为原有系统中关于订单、促销和报价功能耦合在一起带来的实际问题，这是立足于点，又从业务流程的角度做系统设计串联起三个系统的拆分逻辑，这是连接成线，最后从复杂度和成本考量的方向夯实了设计的原则，这是扩展成面。

那继续思考一下： 拆的底层逻辑到底是什么？

• 为什么做架构拆分？通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。

• 为什么要做系统解耦？系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个系统职责更单一，功能更为内聚。

• 为什么要做职责单一？因为职责单一的系统功能逻辑的迭代速度会更快，会提高研发团队响应业务需求的速度，也就是提高了团队的开发效率。

• 为什么要关注开发效率？研发迭代效率的提升是在业务发展期间都最为关注的问题，所以从某种程度上看，架构拆分是系统提效最直接的手段。

所以，架构拆分其实是管理在技术上提效的一种手段，认识到这一点后，就不难理解为什么很多架构师在做系统架构时，会做系统设计上的拆分 。

拆分方案：

1. 订单系统独立：采用CQRS模式分离读写操作，数据库主从分离
2. 促销系统微服务化：引入熔断机制和本地缓存，QPS从200提升至2000
3. 报价系统异步化：通过Kafka实现报价计算的削峰填谷

效果验证：

• 系统可用性从95%提升至99.99%
• 需求迭代速度加快3倍
• 资源成本降低40%

二、分析问题认知：穿透表象的本质洞察

在实际工作中，开发人员在做系统设计时需要与公司或部门的战略定位对齐，才能让技术有价值。因为对于系统技术架构升级的问题，业务方、管理者和技术人员的关注点是不同的。

• 业务方的诉求是在技术升级后，系统有能力迭代功能来满足市场的要求，所以关注点在系统能力。

• 管理者的诉求是在技术升级后，系统研发团队的开发效能得到提升，所以关注点在人效管理。

• 作为开发人员，需要找到自己做系统设计的立足点，来满足不同人对技术的诉求，而这个立足点通常就是系统设计原则。

所以系统的设计原则不是乱提出来的，而是针对系统现阶段业务发展带来的主要矛盾提出，才会更有价值且被认可。

遗留系统改造案例

某遗留系统，表象是算法性能问题，本质是架构无法支撑业务扩展：

表象

早期，业务发展比较简单，团队规模也不是很大，单体系统可以支撑业务的早期规模，但当业务不断发展，团队规模越来越大时，之前的一个业务团队逐渐发展成了多个业务团队，这时每个业务团队都会提出自己的功能需求。

然而，系统现状仍然是单体架构，研发同学都在同一个系统里进行开发，使得系统逻辑复杂，代码耦合，功能迭代和交付变得非常缓慢，牵一发而动全身，研发都不敢轻易修改代码。

本质

这个时期系统的主要矛盾就变成了：多人协作进行复杂业务，导致速度缓慢，但业务需求又快速迭代。说白了，就是研发效率不能匹配业务发展的速度，并且单靠加人不能解决问题。

对于这样的一个系统，此阶段的系统架构核心原则就不能随便定义为要保证高性能和高可用。

那么应该怎么做呢？针对这样的问题，我们需要对原有系统进行合理的系统边界拆分，让研发人员有能力提速，来快速响应需求变化，这就要求架构师对业务领域和团队人员有足够的了解。

在 20 世纪 60 年代，《人月神话》的作者就分析，软件复杂性来源于两点：本质复杂度和偶然复杂度。开发工具、开发框架、开发模式，以及高性能和高可用这些仅是偶然复杂性，架构最重要的是要解决本质复杂性，这包括人的复杂性和业务的复杂性。

破局之道：

1. 领域驱动设计划分边界
2. 引入事件溯源机制
3. 构建调度引擎中间件

设计原则矩阵：

三、能力边界认知：系统思维的维度跃升

典型差异对比：

• 一个中高级研发工程师对系统的驾驭边界至少是模块或者子系统层面；

• 一个架构师对系统的驾驭边界至少是全系统层面；

• 一个高级架构师对系统的驾驭边界至少是某一领域层面

没有触达多系统层面的设计，就不会掌握多系统层面带来的复杂度和解决问题的思考逻辑。但是往往研发同学意识不到这样的问题存在，即便能碰到一个通盘考虑架构设计的机会，但价值、眼界、认知的形成，也不是一朝一夕的事儿。

因此需要在工作中养成归纳总结的习惯，形成自己的知识体系，沉淀自己的方法论，提高自己的认知能力，并且跳出舒适区，多争取扩展自己能驾驭系统的边界的机会。

小结

• 首先要提高对系统架构设计的认知能力，一个好的架构师的架构设计不是仅仅停留在技术解决方案上。

• 其次要提高分析系统问题的认知能力，做架构设计要具备根据现阶段的主要矛盾来分析问题的能力。

• 最后要扩大自己能够驾驭系统的边界，因为只有这样才能遇到之前没经历过的问题层次，注意这里说的是问题层次，而不是问题数量。

技术认知的跃迁本质是思维模式的升级。当你能从代码细节中抽离，看到系统间的能量流动；当你能穿透技术表象，洞察业务本质矛盾；当你的设计边界从模块扩展到领域——这就是架构思维真正形成的时刻。记住：优秀的系统设计都是生长出来的，而不是设计出来的，我们需要做的是为这种生长提供合适的土壤和框架。