系统架构设计核心三要素：组件划分、关系设计与约束管理

聊系统架构的人很多，但能把架构聊清楚的很少。很多人一张嘴就是“我们上了微服务”、“我们做了中台”、“我们要支撑百万并发”，这些充其量是方案的名字，不是架构的理解。真正把系统架构想明白的人，通常会先回答一个很朴素的问题：系统到底应该被拆成什么、各部分之间怎么咬合、哪些规则绝对不能变。我在过去十几年里接触过嵌入式固件、分布式网关、运营商计费系统，也带过不少系统架构设计师考试的备考者，最后发现一个规律：不管系统是大是小、技术栈是C还是Java、跑在x86还是ARM上，架构上真正要抓的“三个点”从来没变过——组件怎么划、关系怎么连、约束怎么定。这篇文章就是把这三个点掰开揉碎，讲讲我自己的理解。

1. 第一点：组件划分——先把系统切明白

1.1 组件划分到底解决什么问题

组件是什么？通俗点说，就是系统里一个个能独立识别、独立交付、独立替换的功能单元。在不同的语境里，它可能是微服务里的一个服务、嵌入式工程里的一个模块目录、Android APK里的一个独立库，甚至是一个.so文件。组件划分决定的是系统的边界长什么样。

很多人觉得组件划分就是把代码按文件夹分一分，这是非常大的误解。组件划分不是整理抽屉，而是在定一个系统里“谁和谁必须在一起、谁绝对不能和谁混在一起”的契约。这一步做错了，后面所有的工作都在还债。

我见过最典型的反面案例是一个流媒体后端项目。团队一开始为了赶进度，把推流、转码、鉴权、计费全部塞进了同一个服务包里，理由是“反正早期流量小，拆开了还得写接口，麻烦”。到了第二个月，并发一上来，转码导致CPU被打满，连鉴权也一起超时；第三个月上协议变更，改推送逻辑的人不小心碰了计费代码，线上直接出现了扣费异常。这不是代码质量问题，是组件划分的边界问题——把变化速度不同、稳定性要求不同的东西绑在了一起。

组件划分的核心作用有三个：一是让系统具备局部化修改的能力，改一个组件不影响全局；二是让不同团队可以独立并行研发；三是让系统能够按需弹性伸缩——流量大了扩容某个组件，而不是把整个系统复制一遍。在嵌入式场景里这一点更明显，STM32的固件如果按模块划分好，调试外设驱动时就不用反复重新编译和验证整个应用逻辑；反过来要是全都写在一个main文件里，改动一个引脚定义都可能引发一连串奇怪问题。

1.2 三种主流的划分逻辑与选择依据

组件划分没有唯一正确的答案，但有几种被反复验证有效的划分逻辑。

按业务域划分：这是微服务架构最推崇的方式，围绕业务能力去切，比如订单域、用户域、支付域。优点是边界天然清晰，团队能对齐业务认知；缺点是如果业务本身耦合度很高，强行切分会把大量时间花在接口协调上。

按技术层次划分：这是最古老的划分方式，把系统分成表现层、应用层、领域层、基础设施层。在嵌入式里就是驱动层、操作系统抽象层、应用层；在Android里就是UI层、业务逻辑层、数据层。优点是层次清晰、依赖方向好控制；缺点是如果过度分层，每加一个简单功能都要穿透好几层，开发效率会明显下降。

按变更频率划分：这个思路相对进阶，先把稳定不变的底座（框架、协议、公共库）和频繁变化的部分（业务规则、界面、外部对接）分开。这样稳定部分可以沉淀成平台，变化部分可以快速迭代。像是麒麟这类操作系统的架构，内核和桌面环境分开、运行库和系统服务分开，本质上都是为了隔离变更频率。

怎么选？我的经验是三个问题：业务的语言是什么？团队的组织结构是什么？系统的变更热点在哪里？如果业务语言清晰、团队也是按业务组织，那就按业务域划分；如果系统偏底层、以稳定为主，那技术层次划分更合适；如果系统已经进入了高速演化期，那一定要在划定时给“变化的部分”单独留位置。绝大多数系统实际的划分逻辑都是三者混合的，关键在于分清楚主导逻辑是什么，而不是东切一刀西切一刀。

1.3 组件划分里最常见的坑

第一个坑是划分粒度失当。要么切得太粗，一个巨型组件里什么都有，内部没有任何结构性约束；要么切得太细，一个只有几十行的方法也要抽成一个服务，结果线上的调用链绕成一团。我见过一个团队把“登录服务”和“注册服务”都单独拆出去了，看起来服务很多项目很“先进”，实际上这两个服务的调用方几乎永远是一对，拆开的唯一效果就是白白增加一次网络跳转和一套部署运维成本。

第二个坑是没有给划分标准留下文档。组件划分完了，不记录为什么这么划，过了半年新同事接手，看着目录结构完全无法理解边界逻辑，就开始凭感觉往现有组件里塞代码。时间一长，边界模糊了，各种跨组件的隐式调用也出现了。组件划分一定要留下架构决策记录，写明边界依据、变更代价和演化方向。

第三个坑是划分时过度依赖团队个人经验。很多时候组件的划分是“谁嗓门大听谁的”，而不是基于对系统真实运行状态的分析。合理的做法是先梳理系统的主要业务流程和数据流向，识别出候选组件的边界，再通过团队的架构评审去确认。

2. 第二点：关系设计——连接比零件更重要

2.1 关系的本质，先从耦合说起

如果说组件划分解决的是“系统有哪些零件”，那么关系设计解决的就是“零件怎么咬合”。架构的核心从来不在零件本身，而在零件之间的关系。

关系设计要回答的问题包括：组件A怎么调用组件B？数据在组件之间怎么流动？组件之间是同步等待还是异步解耦？一个组件挂了，其他组件会受到什么影响？这些问题的背后，全部指向一个词——耦合。

很多新手对耦合有误解，认为好的架构就是绝对的“零耦合”。实际上耦合是客观存在的，处理耦合的关键不是消灭它，而是把它管理在可控的位置上。没有耦合的系统是孤岛系统，集成那天就是灾难。真正的问题不是“要不要耦合”，而是“耦合的方向、强度、方式是否可以接受”。

我举个具体的例子。早期我负责一个网关注册中心，把服务发现、配置管理、注册信息全部耦合在一个数据库里。看起来是“统一管理”，但一旦配置中心要独立升级，数据库schema一变，所有依赖方跟着遭殃。后来改成三个组件，中间通过标准协议交互，耦合从“共享数据库”变成了“协议约定”，升级的爆炸半径一下子就缩小了。这里的本质不是减少了耦合，而是把隐式的高风险耦合变成了显式的低风险耦合。

2.2 接口与协议的设计要点

关系设计最直接的落地方式就是接口和协议。接口是静态的契约，协议是交互的规则，放到分布式系统里就是API定义、消息格式、重试和超时机制；放到Android这种场景里就是aidl接口、Binder调用的权限和线程模型；放到嵌入式里就是芯片片内外设的寄存器映射、I2C总线的设备地址与读写时序。

接口设计我始终坚持几个原则。第一，接口要小而稳定，少暴露内部细节，接收方只信任接口承诺的语义，不依赖发送方的实现细节。第二，接口版本要显式管理，尤其在移动端，APK的API版本、框架版本、系统版本只要不一致，就会出现兼容性风险，所以上线之前一定要先确认目标设备的系统架构是arm64-v8a还是armeabi-v7a，不同的指令集对应不同的so库生命周期。第三，接口要能独立验证，两边团队的联调不能等到集成阶段才开始，接口文档、mock服务、契约测试要前置。

协议设计里面最容易被忽视的是超时和重试。很多系统出故障不是组件坏了，而是调用方在组件响应变慢时无限等待、不断重试，结果把故障放大了。像电信计费系统这种实时交互非常敏感的场景，超时阈值定多长、重试次数定几次、是不是需要熔断、要不要异步削峰，这些都是关系设计的核心参数，不是随便拍脑袋填的。

2.3 依赖方向管理：从代码里的坑讲到架构上的原则

依赖方向是关系设计中最容易被忽视、也最容易累积出技术债的部分。依赖方向管理的核心原则是：高层组件可以依赖低层组件，抽象可以依赖抽象，但业务实现绝对不能反过来依赖具体的别家实现。

在嵌入式开发里这个原则体现得特别典型。STM32项目如果应用逻辑直接操作寄存器、直接引用某个驱动库的内部头文件，那换一颗芯片、升级一次固件库，应用层就得跟着改。合理的做法是应用层通过硬件抽象层（HAL）接口来访问外设，底层驱动实现这个接口。看起来只是多了一层间接调用，但换来的是应用层可以移植、驱动层可以独立替换。

在分布式系统里，依赖方向的问题就更隐蔽。最常见的反模式是“数据流向倒挂”——明明是对账组件需要从外部系统拉数据，结果设计成了外部系统反向往对账组件推送；明明是A服务依赖B服务的能力，结果A把B的数据库表直接当作自己的数据源。这些都违背了组件边界的基本常识。每次看到这种设计，我都会去追一下原始决策是怎么做出的，几乎无一例外都是开发图省事、绕过接口直接操作底层资源导致的。

3. 第三点：约束管理——架构成败的隐形天平

3.1 约束为什么重要，以及为什么容易被忽略

前面两个点讲的是“怎么把系统搭起来”，而约束讲的是“哪些事情的边界必须被守住”。约束是指对架构起到限制作用的规则和前提，包括技术栈选型、性能目标、部署环境、兼容性要求、团队规模，甚至还包括政策法规与行业规范。

为什么约束容易被忽略？因为约束不像组件和关系那样可以画成图、写进文档，它更像空气——平时存在感为零，一旦违背了就会立刻引爆。一个系统可以组件划分得很漂亮、关系设计得很优雅，但如果在约束上踩了红线，前面的努力全部白费。我见过一个云计算管理平台，组件化做得非常好，团队也很有架构素养，最后唯一没有做好的事情是忽视了国产化环境的适配要求，等到要在aarch64架构的麒麟系统上部署时才发现依赖的第三方运行库没有该架构的版本，落地进度直接受阻。

3.2 现实中四类常见约束，逐一拆解

技术选型约束。这是最直接的约束，解决的是“能用什么不能用什么”的问题。比如在嵌入式场景，资源受限，就不能随随便便上完整的操作系统内核，要按Flash容量、RAM大小去选裸机、RTOS还是完整Linux；在国产操作系统场景，不能假设所有第三方依赖都有现成的arm64安装包，Node.js这种运行时也要考虑有没有对应的aarch64构建版本。

性能与可靠性约束。这类约束表现为SLA数字：99.99%的可用性、P99延迟100毫秒内、支撑10万并发等。所有的架构设计都应该以这些数字为出发点去倒推——需要几副本、需要什么缓存策略、需要什么样的负载均衡与容错机制。

兼容性约束。特别是在移动端、混合架构场景里，API版本、系统版本、指令集架构共同决定了一个应用能覆盖多大的用户面。系统版本14、API 34、架构arm64-v8a，这些参数看着枯燥，但它们直接决定了APK里要打包哪些库、minSdk要定到多少、哪些新特性可以用、哪些必须做降级处理。

演化约束。这是一个容易被忽略但极其重要的约束：你希望这个系统未来三年走向哪里。如果明确知道系统要往多租户、多地域演进，那么现在做数据模型和命名空间设计时就该留好扩展位，而不是等到客户来了才推倒重来。演化约束站在“未来”的角度反向约束“今天”的架构。

3.3 把约束变成可落地的架构决策

很多团队不是没有约束，而是约束散落在各处，没有被统一管理。架构师真正要做的，是把模糊的“感觉不能这么做”变成可执行的架构决策。

处理约束的第一个动作是建约束清单。把当前已知的所有约束分类列出来，包括硬约束和软约束。硬约束是不可妥协的，比如“必须兼容ARM64指令集”“计费金额不能出现浮点误差”；软约束是可以在特殊情况下放宽的，比如“默认使用PostgreSQL，但性能评测显示瓶颈时可以补充独立存储层”。约束清单要做到人人可见、变更留痕。

第二个动作是给约束排优先级。当约束之间出现冲突时，要有明确的裁决顺序。比如性能约束和技术选型约束经常打架——团队想用某个开发效率高的框架，但性能测试不达标。这时优先满足硬性SLA还是硬性技术栈要求，架构师必须在冲突发生时给出明确裁决，而不是让开发团队自行摸索。

第三个动作是把约束翻译成检查和测试。仅仅写在设计文档里的约束是软性的，必须通过架构评审、CI扫描、接口契约测试、性能压测脚本把约束固化为“自动检查项”。拿API版本来说，每次出包前都应该自动扫描目标SDK版本和运行库的abi匹配情况，而不是等到线上崩溃才回头排查。

4. 三个点在真实系统里是怎么协作的

4.1 分布式系统里的三个点

拿分布式交换机系统这类场景来说——关注这类系统的人通常关心网络数据平面的高吞吐和转控分离。组件划分上，它至少分为管理平面、控制平面、数据平面，三者不允许混布；关系设计上，三个平面之间通过标准化的接口通信，数据平面负责快速转发，控制平面负责路由计算和策略下发，管理平面负责配置和运维；约束管理上，转发的时延上限、策略刷新的原子性要求，都必须在架构层面测试和保证。这三个点看着是三条独立的工作流，其实任何一个点被改动，都会影响另外两个：比如控制平面新增了一个协议，数据平面就要配套增加转发表的下发格式；下发格式变了，管理平面的配置模型也得跟着调整。

4.2 嵌入式场景下的三个点

嵌入式是我觉得最能体现“三个点”普适性的领域。比如STM32的系统架构，组件划分通常是存储管理、时钟与电源管理、外设驱动、任务调度这几块；关系设计则集中体现为事件驱动或时间片轮转的关系模型，中断服务函数和应用任务之间通过消息队列或信号量连接；约束管理在这里表现得非常具体——Flash容量只有几十KB，RAM可能只有几KB，实时性要求又是毫秒级。这些约束直接决定了能否引入一个RTOS、要用什么粒度的任务划分、中断栈该分配多大。很多嵌入式工程师觉得架构是“上层那些做分布式的人”才需要考虑的东西，其实一个main文件里函数之间的关系是不是清晰，本身就是架构问题。

再往大了看，ARM64内核和麒麟这类国产系统是另一个嵌入式例子。aarch64和x86在组件划分上自然不同，驱动层、适配层、系统服务层各管一段；关系设计上，应用通过系统API、ODBC之类标准接口访问数据库和外围设备；约束上则必须考虑硬件生态和软件生态的双重兼容。为什么有些系统在x86上开发完，迁移到arm64上就一堆问题？根本原因是第三点——约束——没有被提前识别。这不是经验问题，是架构认知问题。

4.3 电信计费这类高并发系统的三个点

电信计费系统是我做过的对架构理解要求最苛刻的方向之一，因为它的业务价值极其直接：扣错一分钱就是事故。也正因如此，三个点在那里表现得毫无遮掩。

组件划分上，计费系统至少区分为在线计费、离线计费、账务管理、催缴与信控、对外接口网关。关系设计上，在线计费鉴权消息必须低时延，离线话单可以批量异步处理，两个体系的数据最终要能够在账务层归并一致。约束上，可用性要求接近电信级，扣费事务不能丢、不能错、不能重复；同时它还要与外部短信网关、支付通道持续对接，每一个外部接口的协议变更都是约束变化。这类系统里，只看组件划分不看关系设计，会以为各组件可以独立升级，实际上一次话单格式的版本变更就足以让全链路相互牵制；只看关系设计不看约束，又会忽略合规审计、对账时效这些硬性前提。

4.4 移动端场景下的三个点

移动端的系统架构经常被低估，因为多数人只把它当成界面开发。其实从APK的安装包结构到Binder通信机制，三个点一样不少。组件划分上，一个应用要考虑壳工程、基础库、业务模块、动态库（.so）之间的布局；关系设计上，各模块之间的跨进程通信走了Binder还是LocalSocket，决定了安全性和性能的取舍；约束上，API版本、系统版本、arm64-v8a还是armeabi-v7a的指令集选择、SDK包体积上限，每一条都在约束你的架构决策。很多App在不同Android版本上出现闪退，往往就是在第二个点（关系设计）引入了对某个系统API非预期版本的依赖，同时第三点（兼容性约束）没有覆盖被依赖版本的变动。

5. 三个点之间的动态关系

5.1 先后顺序：提出的顺序并不是随意的

在实际做架构设计时，我的习惯是先定约束，再划组件，最后理关系。为什么？因为约束是外部世界给的硬边界，你没法改变它，只能适应它。先想清楚“什么不能做”，才知道“能做的空间长什么样”，再在这个空间里做组件划分，才会做出真正可行的东西。最后再理清组件之间的关系，因为关系是在边界和空间确定之后才能最终定型的。

但理解一个现有系统时，顺序要反过来：先从组件划分去读系统的结构，再从关系设计去读系统的行为，最后倒推出这个系统当初是被什么样的约束限制着。这就像读一个人的档案，先看学历经历（结构），再看做事方式（行为），最后才能推断出是什么环境塑造了他（约束）。所以“三个点”不仅是一个设计框架，还是一个读系统的分析框架。

5.2 相互制约：任何一点的改变都会波及另外两点

三个点不是孤立的。约束变了，组件和关系必须跟着变。比如性能约束从P99延迟100ms收紧到50ms，你可能需要拆出更细的缓存层组件，或者把同步调用改成异步消息，组件划分和关系设计同时改。组件变了，关系和约束也可能被迫修改。比如把一个单体组件拆成两个服务，原本的内存调用的关系就变成了网络调用的关系，新的网络开销可能让延迟约束失守。关系变了，组件也要调整。比如协议从REST改成消息推送，那么接收方组件就需要新增消息消费能力，甚至调整自己内部的模块划分。

在做任何架构评审时，我都要项目组回答一个固定问题：“你这个改动，动的是三个点里的哪一个？另外两个会受到什么影响？”能清晰回答这个问题的团队，架构演进基本是可控的；回答不上来的，说明那个改动还停在一厢情愿的阶段。

5.3 一个把三个点落地到评审会议的提问清单

如果你也在做架构评审，不妨把下面这些问题列成模板，逐项过一遍：

这份清单不是拿来凑数的，而是每一个问题都能逼出实际情况。我带过几轮系统架构设计师备考的人，经常发现大家能背出各种架构风格的定义，但一问到“这个项目里谁和谁交互、什么变了会爆炸”，就说不出来了。原因很简单：他们是在背知识点，不是在理解架构。三个点框架真正的作用，就是让你在描述任何一个系统时不跑偏、不悬浮——每一步都踩在结构、行为、规则的具体事实上。

6. 常见问题与避坑经验

6.1 新手最容易犯的五个错误

一、把组件划分当成项目管理分组。很多团队按“前端组负责的模块”“后端组负责的模块”去划分组件，而不是按业务域或技术层次。这样划分的结果是，组件的边界被人为耦合进了组织结构，组织变了架构就乱了。

二、只画图不讲关系语义。架构图上的箭头每个人都有自己的理解，有的表示调用，有的表示数据流，有的表示部署依赖。标准做法是画图时配合一张接口清单表，明确每条箭头的协议类型、调用方向、同步还是异步、数据格式、异常处理方式。

三、把约束当成限制而不是资产。这是认知问题。约束不是给你添麻烦的东西，恰恰相反，约束是帮你降低决策成本的。你告诉团队“这里只能用公司统一的消息中间件”，他们就不用再花时间和精力去比较五花八门的方案。约束越多，选择空间越小，反而更容易做出正确的决策。

四、忽略非功能性约束。很多时候团队只看功能需求——要支持什么业务动作——而对性能指标、数据保留周期、安全合规这些非功能约束视而不见。这类约束往往是最难迁移重构的，到了系统上线前才突然被验收标准打回，代价极大。

五、没有持续的架构守护。很多团队做完一次架构设计后就再也不管了，直到两三年后代码腐化到不可维护，才想起“当初不是定了架构吗？”架构不是一次性的产出，而是持续演进过程中的约定。它需要被定期检查、持续对齐。

6.2 如何用三个点去拆解别人的架构

理解别人的架构是架构师的基本功。拿到一个陌生系统，从头到尾读源代码是不可行的，我一般按下面这个流程走：

先找组件边界。看顶层目录、看部署清单，找出系统由哪些独立运行或独立部署的部分组成。接着看主要入口和出口，比如对外暴露的API列表、消息队列的Topic清单、数据库的表结构归属，把这些当成关系设计的暗号。再倒推约束，从部署环境、技术栈、运维脚本、SLA承诺里倒推出系统当时面临的硬约束。

这个流程很管用。比如你在麒麟系统上看到某个服务的部署脚本里写了针对aarch64架构的判断逻辑，就能立刻推断出系统跨架构部署的约束；你在Android项目的gradle配置里看到abiFilters只留了arm64-v8a，就知道团队对32位老设备的兼容策略是什么。看到约束，再回头看组件和关系，很多“为什么要这样设计”的问题就自然有答案了。

6.3 备考系统架构设计师时三个点怎么用

系统架构设计师考试是很多从业者都会面对的一道坎，2017年下半年的案例分析试题一就是典型的架构分析题。我发现用三个点框架去解答案例分析题特别有效——拿到题目先不要急着看细节，先抓三点：系统的模块边界在哪里、模块之间通过什么交互、系统在设计时受到哪些硬性约束。把这三个点明确了，再做问题回答，思路会很清晰，也不容易漏答关键得分点。

当然考试只是阶段性的目标，我更希望大家把三个点的理解用到平时的工作里。面试的时候被问到“介绍下你做过的最复杂的系统”，先用三个点搭框架，再说细节——第一部分说自己怎么划组件，第二部分说组件之间怎么交互，第三部分说自己处理过哪些约束冲突。这个回答结构比从早到晚按时间线流水账好太多了，面试官一听就知道你是真的懂架构，而不是只会熟练“服务发现那一套话术”。

最后再分享一个我自己长期使用的习惯：每当接手一个新系统，不管大小，我会先在黑板上写下三个词——组成、连接、限制——然后强迫自己用半小时把三个词填满。填写的过程就是对这个系统建立真正认知的过程。如果半小时后发现某一个问题填不出来，说明我对这个系统的架构理解还没有到位，这时候要做的不是继续讨论，而是去查代码、查部署文档、查上线变更记录，把事情弄清楚再继续。这个东西看似简单，但在无数的项目里帮我避开了大量“看起来没问题、一上线就出事”的陷阱。架构是人写出来的，也会被人改坏，但只要你始终盯着组件、关系和约束这三个点，系统在你眼里就不会失控。