企业官网建设流程全解析

做过技术架构评审的人都有这种体会：聊业务架构的时候大家都很顺畅，一说到技术架构，会议室里往往会安静几秒，然后有人开始画乱七八糟的连线图。我做了十多年架构设计与落地，带过电商、物联网、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 的应用服务器，纯逻辑计算一般能扛 500～1000 QPS，考虑到下游依赖耗时、内存回收、日志写入等开销，给到 3000～5000 QPS 的目标时，需要准备 5～8 台实例才能带上冗余。再看数据库：一次下单事务涉及用户表、订单表、库存表多次读写，写放大按 3 倍算，下单接口 290 QPS 对应的数据库写 TPS 约 1000。单库 MySQL 在固态盘上的写性能大概在 3000～6000 TPS，看起来够，但一旦大促或营销活动叠上来，立刻要吃紧，所以要在设计阶段就想清楚分库分表或读写分离的边界。

没有数字的架构是拍脑袋。数字不用百分之百精确，但量级必须对，这决定了你买多少机器、要不要上缓存、要不要上消息队列，也决定了成本预算是几万还是几十万。

3.2 风格选型：能单体的不微服务，要拆分先留边界

我之前带过一个实际项目，容量算完发现初期峰值 QPS 只有几百，数据库写入也不高。技术方案讨论会上，有人提议直接上微服务，说“现在新系统不用微服务以后没法改”。我坚决否掉了：第一，团队只有六个人；第二，业务边界还没有被验证；第三，运维体系尚未就绪。最后选了模块化单体：Maven 多模块，内部严格按领域划分包边界，模块之间通过接口调用，严禁跨模块直接引用实现类。

半年后，订单模块的流量涨了十几倍，我们把订单模块单独拆出来做成微服务，数据表也随之拆出独立库，整个过程非常平滑，没有重写一行业务代码。这次成功经验告诉我们三条选型原则：

• 能用单体解决的问题，不上微服务；
• 拆分的边界跟着团队和流量走，不跟着代码行数走；
• 每次拆分都要提前定义好数据隔离方案和接口兼容方案，否则拆完就是把故障面扩大。

3.3 一套可落地的部署架构参考

以典型互联网业务系统为例，给一套可以参考的技术架构样本：

这套样本部署在 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 架构强调“模型 + 工具 + 记忆”的编排，让模型能调用外部工具、自主规划任务；LLM+API 架构则是把模型能力封装成标准化接口，通过网关统一接入，业务方不关心模型部署细节。还有大内存架构，把热点数据尽量放到内存或持久化内存里，减少磁盘 IO，这些本质上都是用技术架构手段解决资源与成本的矛盾。

4.5 算法系统的“轻架构”：MATLAB OOP 的启示

热词里有一串“基于 MATLAB OOP 架构的多算法融合数字图像处理系统”，是高校毕业设计里常见的题目。乍看离互联网架构很远，但本质完全一样：用 OOP 思想把多种数字图像处理算法封装成可扩展的类体系，定义统一接口，让新算法能“即插即用”。这就是一种技术架构设计，只是它面向的核心指标从高并发换成了算法复用性、可扩展性和可视化交互。

我特别想强调这点：技术架构不一定是微服务、不一定是云原生，在所有“系统”里都存在架构问题。哪怕是写一个 MATLAB GUI 工具，你把算法、界面、数据输入三者的耦合关系处理好，也是一种架构能力。这个意识很多初入行的朋友没有，总觉得架构是大厂的专属名词，其实自己做一个小工具时，第一次感受到“加一个新算法只需要继承一个父类”的爽感时，你就已经入门了。

5. 常见问题与排查技巧实录

5.1 问题速查：五大类故障先对号入座

技术架构落地里常见的问题我整理了一下，基本逃不出这几类：

5.2 排查思路：先看指标，再看链路

我处理线上架构问题有一个习惯：先看指标，再看链路。技术架构的问题，八成能靠监控指标缩小范围。CPU、内存、磁盘 IO、网络带宽、QPS、错误率、RT 七个指标先过一遍，哪个异常，就往哪个方向钻。第二层用链路追踪（SkyWalking、Zipkin 这类工具）从入口请求找到最慢的那一跳，会非常直观。

分享一个真实案例：订单系统偶发超时，服务端 CPU 和数据库看起来都正常。最后用链路追踪排查发现，某个 Redis 分片发生了主从切换，导致读请求延迟大幅上升，切换完成后延迟又自动恢复。问题诡异在“偶发”两个字，单纯看平均指标根本发现不了。后来给 Redis 集群加了分片级的延迟监控和切换告警，问题复现率归零。这就是架构治理的一部分——你得先知道自己管的地盘上哪个环节没有监控。

5.3 三条原则，别把底盘玩坏

做了这么多年架构，我发现“稳底盘”最后拼的不是技术，是原则。

• 简单优先，复杂要有成本账。新增一个组件，意味着多一个运维对象、多一排告警、多几个故障点。没有解决明确问题的组件，一律不上。
• 冗余兜底，任何核心链路都要降级方案。底盘不是“不出事”，而是“出事能接住”。预案好不好，开一次故障演练就见真章。
• 演进优先于重构。把存量系统推到重来，听起来很爽，实际是技术架构的“卡版本”操作，数据迁移、接口兼容、业务平滑任何一环出了问题，底盘就会在重构过程中散架。

最后说点个人的体会吧。我评审过不少技术架构方案，真正稳的团队，往往不是技术最炫的，而是每一层都有人清楚资源水位、扛得住故障的那拨人。技术架构平时没有存在感，但每次线上出大事，它一定被反复点名。做架构的人，练的不是画图，而是在那种吓人的时刻还能冷静做降级、摘流、扩容的肌肉记忆。希望这篇能把“技术架构”这层窗户纸捅破一些，让你下次聊架构的时候，心里是有底的。