我在帮几个团队做技术复盘时反复听到同一个问题代码不是不能跑是改不动。改一个字段要顺着Controller、Service、Mapper摸一遍换一个存储中间件要动核心业务流程新增一个功能得在if-else里再塞一段逻辑。团队里不是没有设计而是缺少一个能统领全局的整体架构。这篇架构篇总览我想把多年项目里对架构的理解拆开讲清楚架构到底在管什么、主流架构风格各自解决什么问题、站在新项目或重构的起点时应该先想清楚哪几件事。适合的读者我猜大概是这三类从功能开发往系统设计转型的工程师刚带小团队的技术Leader以及正在被“要不要上微服务”“要不要上DDD”这类问题困扰的决策者。这篇不教具体框架的配置项先把脑子里那张架构地图挂起来。1. 架构到底在管哪四件事功能切分、通信协作、部署形态与演进约束以前我带项目喜欢先画一张架构图后来越发觉得画图不是目的落得下去才是。真正让我想明白“架构在管什么”的是一次做设备接入系统的经历。系统里有设备接入、订单、库存、调度、报表如果一开始不把每个模块的职责说死后面做设备接入的人会顺手把库存也改了做订单的人会往数据库里塞一张跟业务无关的临时表。所以我把架构归纳成四件事你在面对任何系统时都能拿这套框架去套。架构关注点要回答的问题典型产物功能切分系统由哪些组件构成各自负责什么模块图、组件清单、服务清单通信协作数据在组件之间如何流转同步还是异步接口契约、消息主题、时序图部署形态组件如何部署故障边界在哪里部署拓扑、容器编排配置、容灾方案演进约束未来如何加功能、换组件而不破坏现有结构架构决策记录、扩展点设计、演进路线1.1 功能切分决定系统由哪些组件构成功能切分解决的是“系统由多少块拼成每一块干什么”。这里的块可大可小大到一个微服务小到一个类。比如MySQL内部架构就是教科书式的功能切分连接器管协议和鉴权解析器管SQL语法树优化器管执行计划执行器管存储引擎调用存储引擎管数据落盘。你读MySQL源码多费劲都会先从这几层进去因为架构就是那个阅读目录。嵌入式系统同样如此。STM32的系统架构里内核、总线矩阵、AHB/APB外设桥、各外设IP层级清楚到你不看原理图也能猜到外设挂在总线的哪一侧。LVGL源码架构也值得拿出来看display驱动、输入设备、对象树、绘制引擎分层管理才让它能在几十KB内存的单片机上跑得动。至于网络上反复出现的“基于matlab oop架构的多算法融合数字图像处理系统”我理解它本质也是同一件事图像预处理、分割、特征提取、分类识别每个算法封装成一个类通过统一的接口注册和调用新增算法时不改动老代码。OOP在这里的意义不在于用了面向对象语法而在于把算法模块的边界划出来了。判断一次切分好不好看两句话高内聚一个模块只做一类事低耦合模块之间只通过明确接口说话。如果做到这两点哪怕整个系统部署在一个进程里也是一套健康的架构。如果做不到先别急着补中间件先把边界梳理清楚。1.2 通信协作数据在模块之间是怎么走的切完之后必须回答第二个问题模块之间怎么传数据。同步请求-响应是最简单的方式适合查询和强一致场景。但模块数量上去了以后同步调用会串成一条长链路一个环节慢就拖垮全部这时就会出现异步事件流、消息队列、最终一致的思路。很多领域里都有“单流双流架构”之争。拿多模态数据处理来说“单流”是在入口把多种数据拼成一种统一输入“双流”是各自走独立分支到最后再融合。表面看是模型结构差异本质还是数据协作时机与耦合度的取舍。业务系统也一样把订单状态变更直接调库存服务接口跟发一个“订单已支付”领域事件给库存服务对模块之间关系的塑造截然不同。这里有个我踩过的坑早期做消息化改造只想把“通知”异步化结果把核心业务状态变更也发进了消息队列。排错时数据流断在半路消费者逻辑一出问题脏数据蔓延到好几个服务。教训是通信方式搭配的业务场景要写清楚哪些必须同步强一致哪些可以异步最终一致不要凭感觉混用。1.3 部署形态与演进约束不只画图还要留好扩展点架构方案最终要落到部署形态——是一个进程里跑完全部还是拆成多个进程或容器各跑各的。部署边界直接决定了故障半径单体一挂全挂微服务一个节点挂掉只影响部分链路前提是你有足够的观测能力。演进也非常关键。加缓存的时候调用方要不要改代码换掉一个算法引擎接口层能不能不动这类问题要在初始设计时留好扩展点。我见过太多团队第一版就把系统设计成微服务架构结果服务之间互相调用关系比业务还复杂后续演进改都改不动。架构不是一步到位的但方向要对。2. 架构演进这条主线单体、服务化到微服务到底在解决什么问题很多团队在架构选型时首先想到的不是业务需求而是“现在流行什么”。所以我习惯把架构演进这条主线完整讲一遍让大家知道每一步背后到底在解决什么痛点。2.1 单体架构被嘲笑但依然能打我发现很多人把单体架构当成“落后”的代名词其实不是。一个几十万行代码、几百张表、部署在一台应用服务器上的单体系统只要内部边界清晰、数据库规范、测试完整它的交付效率可能比微服务还高。为什么没有网络调用事务是数据库本地事务调试可以直接断点部署就一条命令。单体真正的敌人不是“单”而是无边界。当所有代码堆在同一个工程里架构边界只存在于口头上、没有任何硬性约束时改一坨就会引发连锁改动这时候才需要想办法拆分。热词里MySQL架构、各类系统内部架构之所以常被讨论也是这个道理一个整体内的架构同样需要精心设计。2.2 从SOA到微服务拆的是责任边界不是技术炫技随着业务变大单体的痛点逐渐浮出团队协作冲突多、发布互相牵制、某个模块的高流量把整台机器压垮。于是先有SOA通过ESB企业服务总线做服务编排与集成。SOA思路本身没错但集中式ESB很容易变成性能与维护上的单点故障不少团队被沉重的中间件压得喘不过气。微服务可以理解为SOA的轻量化、去中心化版本每个服务按业务能力划分独立开发、独立部署、独立伸缩。相比SOA微服务更强调去中心化治理服务间通过轻量级API通信数据存储也倾向各自独立。带来的直接好处很实在一个推荐服务流量暴涨可以只扩它一个服务发版不需要拉着全部应用一起重启。但微服务不是免费的午餐它把原来单体内部的方法调用变成了网络调用于是网络超时、重试、幂等、分布式事务、分布式锁这些话题全部冒出来。网上经常能看到“SpringCloud架构中关于分布式定时任务的解决方案”这类热门问题恰恰说明不少人都是上了微服务之后才开始补课。分布式环境下定时任务要考虑的不只是“能跑起来”而是多实例下如何避免重复执行、任务失败如何补偿、调度中心挂了怎么办。对比维度单体架构微服务架构交付效率初期高后期随规模下降初期低边界清晰后稳定故障影响全局影响局部影响依赖可观测性事务一致性本地事务简单可靠分布式事务复杂团队要求低适合小团队高需要运维和平台能力2.3 服务网格与云原生把基础设施从业务代码里抽走再往后演进团队发现服务治理逻辑比如熔断、限流、负载均衡、链路追踪写在业务代码里会和业务逻辑越缠越乱。于是服务网格出现把网络通信能力下沉到Sidecar代理业务只写接口逻辑治理规则由代理统一执行。这是架构演进的又一层抽象把“基础设施能力”从“业务代码”中抽离。再配上容器与编排平台就构成了云原生底座。K8s管理实例数量与滚动发布Prometheus负责指标采集业务团队的关注点可以收缩到纯业务逻辑。但丑话说在前面这套链路对运维能力要求不低小团队硬上一整套云原生栈反而会被平台故障淹没。架构选型永远要跟团队规模和运维能力匹配。3. 系统内部的结构形状分层、六边形、DDD与事件驱动聊完宏观的分布式演进回到单个系统内部。这里的架构风格决定了一个工程代码是越写越整洁还是越写越像毛线团。几种主流形态我都试过说说各自的适用范围和坑。3.1 分层架构最普及也最容易腐化的结构绝大多数系统的第一版都是分层架构Controller、Service、DAO或者UI层、业务层、数据访问层。分层最大的好处是单向依赖上层调用下层职责逐渐下沉新人上手容易。但分层也是最容易腐化的架构。当开发同学图省事在Controller里直接写了查询SQL当Service层变成“万能中转站”事务、缓存、消息发送、权限判断全塞进去当Repository层的接口混入大量业务逻辑时分层也就不存在了。所以检查一个分层系统健不健康我通常看两件事依赖方向有没有乱掉每层是否只做本层的事。3.2 端口与适配器架构把核心逻辑从外部世界隔离六边形架构也叫端口与适配器架构要解决的正是分层架构的一个痛点别让数据库、消息队列、第三方SDK这些外部细节污染核心业务逻辑。它把系统看成核心、端口、适配器三层核心是纯业务规则端口是业务定义的接口适配器负责把外部世界变成端口实现。举个例子你要做一个订单金额计算模块核心只依赖“汇率接口”和“税率接口”完全不感知这些接口是调用REST接口、读数据库还是查缓存。将来换掉外汇服务商只需要新增一个适配器核心一行不动。在业务系统和外部服务耦合严重的项目里六边形架构特别值得引入。它和Clean Architecture是同一个思想核心都是依赖倒置依赖关系永远指向核心核心不依赖任何外部框架。3.3 DDD业务复杂度高到一定程度后的战略级方案当业务规则本身非常复杂、界限模糊不清时就该请出领域驱动设计了。DDD分两块战略设计和战术设计。战略设计强调不要试图用一个模型描述整个系统而是用限界上下文切出多个模型语境。比如订单、库存、结算各自有独立的领域模型模型之间通过防腐层交互。战术设计是一套落地规则实体、值对象、聚合、仓储、领域服务、领域事件。我看到很多团队把DDD理解成“建一堆entity、repository文件夹”其实远不是。真正的DDD第一步是跟业务专家坐下来把业务流程、规则、术语统一成“通用语言”再划分限界上下文。没有这一步后面的战术模式全是空中楼阁。DDD反过来又天然支撑微服务拆分每个限界上下文就是一个候选服务边界这也是它和微服务总被一起讨论的原因。3.4 事件驱动与异步流解决同步调用搞不定的场景事件驱动架构让模块之间不直接互相调用而是通过“事件”进行事实广播。订单状态变成“已支付”发布一个OrderPaidEvent关心的服务各自订阅处理彼此不需要知道对方存在。这种架构特别适合跨模块低耦合、业务链路较长、要求高可用的场景。但也要诚实面对事件驱动的代价事件丢失、顺序乱、重复投递、最终一致窗口排查问题的难度比同步链路大得多。我做这类架构的准则越靠近用户强体验的路径越用同步越偏内部异步协作的越可以事件化。单流双流的取舍逻辑放在这里也成立——数据只有一条流简单好排错拆成多条流再组合灵活但复杂。4. 新场景带来的新架构物联网、AI应用与算力集群除了传统业务系统这几年新增的架构热词基本集中在物联网、AI应用和算力集群三个方向。这些场景乍看离业务开发很远但底层思路和经典架构完全相通。4.1 物联网三层架构感知、网络、应用的分工逻辑物联网的经典三层架构能沿用这么久是因为它精准反映了设备、传输、业务的自然分层。感知层是各种传感器、执行器、边缘设备负责数据采集与动作执行往往运行在STM32这类嵌入式MCU上算力和存储极其有限网络层解决设备如何联网、数据如何上传下达涉及网关和协议适配应用层则是数据存储、处理、展示与业务逻辑。真实项目里还会叠加“平台能力”层但它仍然可以挂在应用层内部。这套架构最值得学习的地方在于清晰的职责分割设备端只关心数据上报与指令执行不关心云端业务云端只认统一协议不关心传感器具体怎么出数据。这就是软件架构里“抽象隔离变化”思想的硬件版。4.2 LLMAPI、Agent与MoEAI应用架构的几种形态AI应用这几年走向工程化架构问题一下子变得现实起来。最简单的形态是LLMAPI把大模型当成一个外部能力重点在于围绕模型做好上下文管理、工具调用和缓存策略。再往前走当需要让模型自主规划任务、调用多个工具、记忆多轮状态时就进入了Agent架构的范畴。一个典型的智能体平台架构至少要包含模型接入层、工具注册层、记忆模块、规划与执行编排层、用户会话管理。它跟传统中台架构没有本质区别只是把“业务服务”换成了“技能和工具”核心仍然是调度与编排。Agent背后的大模型自身也在做架构演进。Transformer是基础MoE混合专家架构则通过路由器把不同Token分配给不同专家网络把超大模型拆成多个相对小的专家协同工作实现训练和推理效率的提升。从外部看调用接口时不需要感知内部是不是MoE但从平台架构角度不同模型的KV Cache、Batch策略、显存管理差异会直接影响推理服务是单机部署还是多机流水线。4.3 算力集群视角指令集、大内存与多机协同最后说一个容易被业务架构师忽略的层算力本身。底层是指令集架构x86和ARM在服务器领域的并存映射到软件上就是适配成本类似“aarch64架构装某个软件”的折腾很多工程师都经历过顶层则是GPU集群、存储网络与高性能计算资源池。这类架构的共性是把资源、数据、任务三层分开调度资源层管计算节点和存储节点数据层管缓存与预取任务层管模型推理的拆分与并行。很多经典架构经验在这里依然有效只是把“服务实例”换成了“任务单元”把“数据库”换成了“分布式缓存与对象存储”。做AI平台架构的团队如果能从经典系统设计视角看这些问题会比纯算法背景的团队少踩很多坑。5. 落到选型决策四个问题、三个误区、一条学习路径讲了这么多架构风格最后落到最实际的你手上有一个新项目或者一次重构到底该怎么选型。我给不了万能答案但可以分享我的决策习惯。5.1 选型前先回答四个问题第一业务复杂度卡在哪里。是流程复杂适合DDD配合事件驱动深挖领域是规模复杂流量大、并发高适合缓存、队列加服务化拆分还是技术复杂算法多、协议杂适合抽象接口层加插件化设计。第二团队规模和协作方式。康威定律说系统架构往往复制团队的沟通结构。五个人以内单体加清晰分层就够硬拆微服务只会增加沟通成本几十人以上按业务能力拆团队和服务的边界才划算。第三部署环境与运维能力。能不能自由上云有没有专职运维或SRE决定了你敢不敢用云原生全家桶。没有运维能力的团队强行上Service Mesh线上问题会多到怀疑人生。第四数据一致性和时效性要求。强一致场景多用同步调用和本地事务最终一致场景才考虑事件流和消息队列。这四个问题答完架构的大方向基本就定了剩下的只是细节。5.2 我见过的三个选型翻车误区误区一为了技术简历好看而上微服务。一个小团队做内部管理系统硬上Spring Cloud全家桶服务节点数量比业务模块还多分布式事务把简单业务变成一天到晚修数据。单体没有原罪清晰的分层比炫技的架构有用得多。误区二把DDD用成了包结构。只建了entity和repository目录没有限界上下文、没有通用语言最后变成“披着DDD外衣的传统三层”复杂度没降反升。DDD的切入点是业务理解不是代码目录结构。误区三忽略演进直接大爆炸式重构。看到老系统不爽想着重写一个完美架构。现实是老系统里藏着无数需求细节重构期间业务方还不停提新需求翻车概率极高。更稳妥的做法是绞杀者模式新架构在旁边长新系统逐步把旧能力迁移过来老系统慢慢退网。5.3 从总览到落地我建议的路径与文档沉淀如果你刚接触架构别一上来就啃微服务大部头。我建议的路径是先把一个已有系统的源码结构读透比如MySQL、LVGL或者公司内部的核心系统能画出它的模块图和请求时序图然后回到自己的项目里练习分层和依赖倒置尝试局部引入六边形或DDD有了单系统架构手感之后再学分布式、服务化和云原生最后回头看AI应用与算力集群这些新场景。还有一个很值得养成的好习惯让架构决策可追溯。用什么架构、为什么不用另一个方案写进ADR架构决策记录哪怕只有一页纸。时间长了它的价值会超过任何一张架构图。我之前带的一个项目组就是靠这种“先画地图、再定边界、边做边记录”的方式把一团乱麻的遗留系统慢慢理顺的。架构这件事听起来很大做起来都是一步步来的。这篇总览就是那张地图的开头剩下的路需要你拿自己的系统一个个去踩出来。