做过技术架构评审的人都有这种体会聊业务架构的时候大家都很顺畅一说到技术架构会议室里往往会安静几秒然后有人开始画乱七八糟的连线图。我做了十多年架构设计与落地带过电商、物联网、AI平台各种类型的项目今天借这个“架构三大分类”系列的最后一讲把技术架构彻底聊透。它是三大分类里的第三块拼图也是被误解最多、背锅最狠的一块。什么是技术架构我常用一句话概括业务架构告诉你要造一辆能载货的车数据架构告诉你货物怎么装、货单怎么记而技术架构就是决定用什么底盘、什么悬挂、什么发动机让这辆车跑起来不散架、过急弯不翻车。这篇文章适合三类人看准备考系统架构师证书的正在从研发往架构方向转型的以及被领导要求“画一张架构图”却被问得说不出话的技术管理者。1. 为什么说技术架构是“稳底盘”1.1 架构三大分类的“分工暗号”架构分类的口径很多TOGAF把企业架构拆成业务架构、数据架构、应用架构、技术架构四大领域。但实际项目里应用架构经常并入业务或数据架构一起讲这时候就变成了常见的三大分类业务架构、数据架构、技术架构。本系列前两篇分别拆解了业务架构和数据架构这一篇补上最后一块拼图三块拼起来一张完整的架构全景才能立住。用电商系统举个例子。业务架构回答的是“谁来买、买什么、怎么促销、如何结算”它产出的是流程、角色、规则数据架构回答“用户、订单、商品这些信息长什么样状态怎么流转权限怎么划分”技术架构回答的则是“这些流程和信息跑在什么算力、什么存储、什么网络、什么平台组件上流量大了怎么扩容出故障了怎么恢复”。三者从来不是先后关系而是互相约束的。数据架构要求消息不丢失技术架构就要引入确认机制和重试链路业务架构要求支付接口做到 99.99% 可用技术架构就得设计多级降级、异地冗余。业务架构和数据架构是愿景技术架构是让愿景落到地面的那个“底盘”。1.2 技术架构管的四件事算、存、通、治技术架构的职责归纳成四件事计算、存储、通信、治理。计算CPU 核数、内存大小、算力类型。通用业务和 AI 计算对算力的需求完全不同前者看并发吞吐后者看矩阵运算和显存带宽。存储数据库、缓存、文件存储、对象存储、大数据存储核心是容量规划、持久化一致性和数据生命周期。通信网络拓扑、内网入口、消息队列、RPC 框架既管流量也管延迟。治理监控告警、日志追踪、配置管理、发布回滚、容量预估。这是最容易被忽略的一环也是把“底盘”跑坏的重灾区。“稳底盘”就是这四件事的合力。底盘不稳的症状非常典型业务代码一行没改系统却越来越卡流量一涨就雪崩一停就恢复发布一次就出一堆问题。这些事九成出在技术架构层而不是那几百行业务代码上。所以我做架构评审时有个习惯先不看代码质量先看技术架构图和监控水位图太虚、水位看不见后面大概率要出大问题。2. 技术架构的分层体系从芯片到接口面2.1 最底层是“地基课”指令集架构、硬件与操作系统技术架构的底座是硬件和操作系统再往深处是指令集架构ISA。指令集架构是 CPU 和软件之间最原始的契约决定了指令怎么编码、寄存器怎么用、内存怎么寻址。我们平时说“x86 架构”“ARM 架构”“RISC-V 架构”严格来讲说的就是这个层面的东西。x86 复杂指令集擅长高性能通用计算ARM 精简指令集强调低功耗RISC-V 则是开放式生态的新变量。为什么技术架构师要懂这一层因为上层所有软件都跑在指令集和操作系统之上。我踩过一个很典型的坑在 aarch64 架构的服务器上部署应用下意识下载了 x86 的二进制安装包一跑就段错误后来才发现要选 arm64 版本。比如 openEuler、Kylin 这类操作系统在 ARM 服务器上跑 KVM 虚拟化需要确认 libvirt-daemon-kvm 这些内核模块和驱动已经正确安装安装 Node.js 18 也要找对应架构的二进制包。这些听起来很“运维”但架构层面不重视指令集和操作系统的适配后面做容量、做灾备都会受到连锁影响。再往上一层是操作系统内核与虚拟化层核心任务是资源隔离和抽象。进程调度、内存管理、I/O 栈、KVM/容器运行时这些都是把一台裸机变成可任意切分的计算资源池的“魔法”。Kubernetes 之所以能成为主流正是因为它把这层抽象做到了极致让应用变成可调度、可漂移的“负载”而不是绑死在某台机器上的“孤儿”。2.2 中间件层是技术架构里“最值钱”的部分从企业视角看技术架构真正让人头疼的不是 CPU 交换机而是中间件。数据库、缓存、消息队列、注册中心、配置中心、定时调度、搜索引擨……中间件选型和使用姿势直接决定了系统的上限和下限。选型背后的逻辑不是“谁火用谁”而是匹配场景读多写少、热点数据用 Redis 做缓存但必须处理穿透、击穿、雪崩三道坎异步解耦、削峰填谷用消息队列比如秒杀场景用 Kafka 或 RocketMQ 把瞬间峰值挡在上游分布式事务Spring Cloud 体系里常见方案是 Seata或者结合消息队列做最终一致性分布式定时任务Spring Boot 自带的 Scheduled 只适合单机场景分布式环境要引入 xxl-job 这类调度框架否则多实例下同一个任务会被重复执行服务发现与配置中心Nacos、Consul、Eureka 这类组件本身就是高可用组件生产环境务必按集群部署不能为省事只拉起一个节点。中间件选型还有一个隐形标准团队是否会维护。技术架构师在中间件上的责任不光是选一个“好”的而是选一个团队能扛得住故障的。再好的中间件没人会排障出了问题就是架构的锅。2.3 应用支撑层架构风格决定“上层姿态”应用支撑层承担两件事承载业务代码的运行框架以及定下代码之间的组织方式。常见架构风格就那么几种单体、SOA、微服务、事件驱动、Serverless还有 DDD 战术设计里的六边形架构。单体不是落后而是最稳的起步方式。模块化单体保留清晰的拆分面一旦性能或团队边界撑不住再提升到微服务。微服务的本质不是“拆得细”而是“每个服务可以独立部署、独立伸缩”。如果你只有一个团队业务量也不大硬拆微服务只会增加运维负担和故障概率。六边形架构非常适合业务复杂系统。它把业务逻辑放在最内层数据库、消息、UI 都变成“适配器”从外层插进来核心逻辑不依赖任何框架和基础设施。依赖方向始终指向圆心业务永远不会被技术绑架。这个思想和干净架构一脉相承在前几年 DDD 火热的时候被大量落地现在回过头看它确实能解决“业务规则被框架搞乱”的长期问题。3. 技术架构选型与设计一个可以抄作业的实例3.1 先算数字再做决定我一般建议技术架构设计按三步走理需求、算容量、定高可用方案。很多人上来就画部署图结果图是画完了连目标峰值都说不清。这不是架构设计是画着玩。容量估算有个实用口诀峰值 QPS ≈日总请求量 ÷ 86400× 峰值放大系数。假设一个电商系统日订单量 50 万下单接口占总请求的 10%那么日请求量约 500 万平均 QPS 约 58。加上峰值放大系数 5下单接口的峰值 QPS 约 290。一台 4 核 8G 的应用服务器纯逻辑计算一般能扛 5001000 QPS考虑到下游依赖耗时、内存回收、日志写入等开销给到 30005000 QPS 的目标时需要准备 58 台实例才能带上冗余。再看数据库一次下单事务涉及用户表、订单表、库存表多次读写写放大按 3 倍算下单接口 290 QPS 对应的数据库写 TPS 约 1000。单库 MySQL 在固态盘上的写性能大概在 30006000 TPS看起来够但一旦大促或营销活动叠上来立刻要吃紧所以要在设计阶段就想清楚分库分表或读写分离的边界。没有数字的架构是拍脑袋。数字不用百分之百精确但量级必须对这决定了你买多少机器、要不要上缓存、要不要上消息队列也决定了成本预算是几万还是几十万。3.2 风格选型能单体的不微服务要拆分先留边界我之前带过一个实际项目容量算完发现初期峰值 QPS 只有几百数据库写入也不高。技术方案讨论会上有人提议直接上微服务说“现在新系统不用微服务以后没法改”。我坚决否掉了第一团队只有六个人第二业务边界还没有被验证第三运维体系尚未就绪。最后选了模块化单体Maven 多模块内部严格按领域划分包边界模块之间通过接口调用严禁跨模块直接引用实现类。半年后订单模块的流量涨了十几倍我们把订单模块单独拆出来做成微服务数据表也随之拆出独立库整个过程非常平滑没有重写一行业务代码。这次成功经验告诉我们三条选型原则能用单体解决的问题不上微服务拆分的边界跟着团队和流量走不跟着代码行数走每次拆分都要提前定义好数据隔离方案和接口兼容方案否则拆完就是把故障面扩大。3.3 一套可落地的部署架构参考以典型互联网业务系统为例给一套可以参考的技术架构样本层级组件职责接入层Nginx / OpenResty反向代理、负载均衡、SSL 卸载、基础限流网关层Spring Cloud Gateway路由、鉴权、灰度发布注册与配置中心Nacos 集群服务发现、配置管理至少 3 节点缓存层Redis Cluster会话缓存、热点数据、分布式锁消息层Kafka 集群订单事件、异步削峰、日志采集数据层MySQL 主从 ShardingSphere主写从读、分库分表监控追踪Prometheus Grafana SkyWalking指标监控、告警、全链路追踪日志平台Elasticsearch Filebeat Kibana日志检索与聚合这套样本部署在 Kubernetes 上各环境用 namespace 隔离每个服务的资源请求和限制按容量估算结果配置。值得多说一句网关层和注册中心我见过很多部署事故都是因为这几个组件只部署了一个节点还美其名曰“够用了”。典型的单点故障就是从这里来的。核心组件双节点起步集群节点至少 3 个这样才能说底盘稳。4. 不同领域的技术架构观察4.1 互联网系统堆叠与解耦的极致抖音这种量级的系统技术架构已经从普通微服务进化到服务网格、分布式缓存集群、自研存储、大规模调度平台。但无论多复杂的系统分层骨架始终不变接入层兜流量服务层做业务数据层管状态。对中小公司而言参考它的分层思路即可不需要复刻组件数量。我在不少小团队里见过照着大厂架构抄了一份几十个组件的技术方案最后连部署都部署不起来。记住架构是服务于业务节奏的不是用来“对标”的。4.2 物联网系统三层架构的现实投影物联网领域最经典的口径是“三层架构”感知层、网络层、应用层有时再加一层平台层。感知层是各类传感器和 MCU常见的有基于 ARM Cortex-M 内核的 STM32网络层是 NB-IoT、MQTT、CoAP 这类通信协议平台层负责设备接入、数据存储、指令下发。物联网技术架构的约束很独特设备算力小、网络不稳定、协议碎片化所以边缘计算在靠近设备的地方做数据预处理越来越重要。纯粹把数据全量上云既不经济也不现实这是物联网技术架构区别于互联网系统的核心思维。4.3 智能汽车与嵌入式系统架构正在重新“收敛”汽车电子里有一个绕不开的标准叫 AUTOSAR它的作用是把底层驱动、运行时环境、应用软件分层隔离让应用不依赖特定芯片。从整车的角度讲传统分布式 ECU每个功能一个控制器让线束越来越复杂、算力无法共享所以新一代电子电气架构往 ZCU区域控制器方向收敛一个 ZCU 同时管车身、动力、座舱多个域。这个思路和微服务化很像——把分散的小部件合并成几个可集中升级、集中供电、集中算力的“大节点”。智驾领域还有一个“基于规则智驾架构方案”的说法核心特征是感知、决策、执行分层决策模块用规则引擎把驾驶行为一条条写清。相比纯端到端模型规则方案胜在可解释、好验证适合渐进式的辅助驾驶场景。这些领域说明技术架构不是互联网专属任何“多组件协作、需要可靠运行”的系统都有技术架构问题。4.4 AI 与大模型系统的技术架构热点这两年接触最多的技术架构需求来自 AI 算力平台。一个 AI 算力集群通常包含异构计算节点GPU/NPU 服务器、高速互联网络RDMA / InfiniBand、并行文件存储、GPU 共享调度与任务调度系统。生态上还有容灾链路与弹性伸缩。做 AI 平台架构和做业务中台架构的差异很明显业务系统瓶颈通常在下游数据库和外部依赖AI 系统的瓶颈往往在算力利用率、数据吞吐和模型推理延迟上。大模型领域的 MOE混合专家架构也很火把模型拆成多个专家模块每次推理只激活部分专家大幅降低算力需求Agent 架构强调“模型 工具 记忆”的编排让模型能调用外部工具、自主规划任务LLMAPI 架构则是把模型能力封装成标准化接口通过网关统一接入业务方不关心模型部署细节。还有大内存架构把热点数据尽量放到内存或持久化内存里减少磁盘 IO这些本质上都是用技术架构手段解决资源与成本的矛盾。4.5 算法系统的“轻架构”MATLAB OOP 的启示热词里有一串“基于 MATLAB OOP 架构的多算法融合数字图像处理系统”是高校毕业设计里常见的题目。乍看离互联网架构很远但本质完全一样用 OOP 思想把多种数字图像处理算法封装成可扩展的类体系定义统一接口让新算法能“即插即用”。这就是一种技术架构设计只是它面向的核心指标从高并发换成了算法复用性、可扩展性和可视化交互。我特别想强调这点技术架构不一定是微服务、不一定是云原生在所有“系统”里都存在架构问题。哪怕是写一个 MATLAB GUI 工具你把算法、界面、数据输入三者的耦合关系处理好也是一种架构能力。这个意识很多初入行的朋友没有总觉得架构是大厂的专属名词其实自己做一个小工具时第一次感受到“加一个新算法只需要继承一个父类”的爽感时你就已经入门了。5. 常见问题与排查技巧实录5.1 问题速查五大类故障先对号入座技术架构落地里常见的问题我整理了一下基本逃不出这几类问题类型典型症状常见根因排查方向规避建议单点故障一台机器挂掉全链路瘫痪组件只部署了单节点、负载均衡没生效看监控里该节点指标是否断崖核心组件至少双节点集群节点 3 起容量不足高峰期大量超时、报错容量估算偏小、扩容滞后对比 QPS 与资源水位曲线定期压测做容量水位管理性能毛刺请求偶尔变慢时好时坏GC 停顿、慢查询、网络抖动链路追踪定位慢节点设置超时与重试优化慢 SQL扩展困难加机器没效果性能不升反降有状态服务、数据库耦合、session 在内存盘点状态存储位置状态尽量外置服务无状态化架构腐化改一处牵全身发布频繁出事循环依赖、模块边界模糊架构一致性检查工具定期做依赖检查反模式扫描5.2 排查思路先看指标再看链路我处理线上架构问题有一个习惯先看指标再看链路。技术架构的问题八成能靠监控指标缩小范围。CPU、内存、磁盘 IO、网络带宽、QPS、错误率、RT 七个指标先过一遍哪个异常就往哪个方向钻。第二层用链路追踪SkyWalking、Zipkin 这类工具从入口请求找到最慢的那一跳会非常直观。分享一个真实案例订单系统偶发超时服务端 CPU 和数据库看起来都正常。最后用链路追踪排查发现某个 Redis 分片发生了主从切换导致读请求延迟大幅上升切换完成后延迟又自动恢复。问题诡异在“偶发”两个字单纯看平均指标根本发现不了。后来给 Redis 集群加了分片级的延迟监控和切换告警问题复现率归零。这就是架构治理的一部分——你得先知道自己管的地盘上哪个环节没有监控。5.3 三条原则别把底盘玩坏做了这么多年架构我发现“稳底盘”最后拼的不是技术是原则。简单优先复杂要有成本账。新增一个组件意味着多一个运维对象、多一排告警、多几个故障点。没有解决明确问题的组件一律不上。冗余兜底任何核心链路都要降级方案。底盘不是“不出事”而是“出事能接住”。预案好不好开一次故障演练就见真章。演进优先于重构。把存量系统推到重来听起来很爽实际是技术架构的“卡版本”操作数据迁移、接口兼容、业务平滑任何一环出了问题底盘就会在重构过程中散架。最后说点个人的体会吧。我评审过不少技术架构方案真正稳的团队往往不是技术最炫的而是每一层都有人清楚资源水位、扛得住故障的那拨人。技术架构平时没有存在感但每次线上出大事它一定被反复点名。做架构的人练的不是画图而是在那种吓人的时刻还能冷静做降级、摘流、扩容的肌肉记忆。希望这篇能把“技术架构”这层窗户纸捅破一些让你下次聊架构的时候心里是有底的。