很多人觉得服务端架构师是“高大上”的角色，好像整天都在画蓝图、做决策。其实真实情况没那么玄乎，更多时候是在处理接口性能、数据库压力和系统稳定性这些具体问题。
写接口只是开始
刚入行时以为服务端开发就是写API，传个参数返回个JSON就完事了。但真正参与项目后才发现，一个简单的用户登录接口，要考虑并发量、密码加密、token刷新机制，还得跟前端对字段、定错误码。比如公司做过一次秒杀活动，没加限流直接被打崩了，后来才在代码里补上Redis计数器。
if (redis.incr("login_attempt:" + userId) > 5) {
throw new RateLimitException("登录尝试过多，请10分钟后重试");
}拆服务不是赶时髦
原来整个系统都在一个大工程里，改个支付逻辑要全站重启。后来把订单、用户、商品拆成独立服务，用HTTP或者gRPC通信。虽然运维复杂了点，但至少哪个模块出问题不会全挂。有一次商品服务数据库慢查询拖垮连接池，其他模块还能正常运行，老板没急着打电话骂人。
数据库不能随便增删字段
有次运营说要加个“用户标签”功能，我在用户表直接加了个text类型的字段。结果数据一多，alter table锁表十几分钟，线上交易卡住。现在再改表结构都会先建影子表，用binlog同步过渡，最后切流量。哪怕只是一个字段，也得考虑数据量和主从延迟。
日志和监控才是救命稻草
系统上线后最怕半夜被叫醒。后来统一接入ELK收集日志，关键接口埋点上报QPS和响应时间。有次发现某个API平均耗时从50ms涨到800ms，查监控图发现是第三方地址解析服务超时，赶紧切了备用方案。要是靠用户反馈才知道问题，投诉早就炸了。
和前端吵架变少了
以前前端说接口慢，我们说网络问题；我们说数据不对，他们说格式没对齐。现在定了Swagger文档规范，字段类型、是否必填都写清楚。还约好每周三下午一起对需求，避免“你传个null我这边没判空”这种低级锅。
服务端架构不是一个人闭门设计，而是在一次次线上事故、需求变更和技术选型中慢慢磨出来的。每天面对的都是具体的技术选择和协作问题，没有太多理论光环，但每解决一个小问题，系统就更稳一点。