老张是某中型电商公司的运维主管，十年前刚接手服务器时，公司所有业务都跑在一台 IBM 小型机上。那时候系统叫“商城1.0”，数据库、前端页面、订单处理全挤在一个进程里。每当大促一来，机器风扇狂转，机房温度飙升，硬盘 IO 直接拉满，客户下单延迟严重。这种把所有功能打包在一起的做法，就是典型的单体架构。
单体架构的硬件瓶颈
早期的架构设计简单直接，开发快，部署也方便。但对硬件要求越来越高。当访问量突破每天十万级请求时，CPU 使用率常年保持在90%以上，内存频繁告警。扩容只能靠堆配置——换更贵的 CPU、加内存条、上 SSD 硬盘。可再强的单机也有极限，这就是所谓的“垂直扩展天花板”。
向模块化演进：服务拆分与硬件解耦
后来团队决定把系统拆开。用户管理、商品展示、订单处理各自独立成服务，跑在不同的物理服务器上。比如订单服务专门配了一台 32 核 CPU、64GB 再加 RAID 10 硬盘的机器，专攻写密集操作。这种按功能拆分的方式，称为“分层架构”或“水平拆分”。每块服务可以根据负载选配硬件，不再一刀切。
这时候老张发现，原来塞在一台机器里的日志输出，现在分散到了五六台设备上。排查问题得登录多台主机，查看不同路径下的 log 文件。他写了个脚本自动同步日志到中心存储：
rsync -avz user@server1:/var/log/app/ /local/logs/server1/ rsync -avz user@server2:/var/log/order/ /local/logs/server2/微服务时代的硬件弹性需求
随着业务继续扩张，他们进一步转向微服务架构。每个小功能（如优惠券计算、库存扣减）都变成独立服务，甚至能动态启停。这时候传统固定配置的服务器撑不住了。一台机器可能上午跑推荐引擎，下午就被调度去处理支付回调。
硬件维护的重点从“修故障”变成了“保供给”。老张开始用 Docker 配合 Kubernetes 做容器编排，服务器不再绑定具体应用。新采购的机器统一规格：双路 CPU、128GB 内存、万兆网卡、NVMe 固态盘，只为适应随时变化的服务部署需求。
边缘计算带来的反向趋势
最近公司上了 IoT 项目，仓库里的温湿度传感器要实时上传数据。如果全都传回中心机房处理，网络延迟太高。于是他们在本地部署小型工控机作为边缘节点，运行轻量化的服务实例。这些设备体积小、功耗低，但必须耐高温高湿。架构又出现“回归集中”的迹象，只不过这次是分布式的集中。
老张现在买硬件前，第一反应不再是看参数表，而是问开发：“这个服务属于核心链路吗？峰值 QPS 预估多少？要不要持久化？” 架构的设计变了，硬件的选择逻辑也跟着变了。
未来：软硬协同的演进方向
现在很多新服务直接按 Pod 资源申请单提交需求，比如“需要 4核8G 内存，挂载 GPU 卡”。运维人员根据集群空闲资源调度部署。硬件不再提前分配，而是按需调用。像阿里云的神龙架构、AWS 的 Nitro 系统，都是把虚拟化损耗降到最低，让软件架构能更贴近物理层运行。
架构设计的每一步演化，背后都有硬件支撑方式的调整。从独占服务器，到资源共享，再到异构加速，这条路还在继续往前走。