偷师大厂架构，意味着我得亲手把这台跑得吭哧吭哧的老爷车发动机给拆了。Python写的单体应用，现在每天处理几千个订单就开始卡死，数据库连接池动不动就爆满，客户投诉的邮件塞满了收件箱。这已经不是优化几行代码能解决的事了，这是物理极限，是架构层面的死刑判决。
我盯着监控图上的那些尖刺，脑子里就一个念头：必须拆。向有赞那种级别的架构靠拢，听起来很宏大，但第一步就是得承认自己过去三年堆的屎山代码到了该爆破的时候。选了Node.js，没别的，就图它事件驱动、非阻塞I/O那套理论上的高并发能力，据说能轻松扛住万级并发。但理论归理论，真动手就是另一回事了。
把核心的订单模块从庞大的Django项目里剥离出来，像做外科手术。首先就是数据模型的重定义，原来在Django ORM里一堆ForeignKey关联，现在得拆成独立的服务，通过API通信。光是设计订单服务独立的数据库表结构，就推翻了三版。原来的业务逻辑里到处都是隐式的依赖，比如计算优惠券时会直接去调用户表的积分字段，现在这些全得改成服务间调用。这不仅仅是写代码，这是在给自己的认知动刀。
然后就是通信和鉴权这座大山。服务拆开了，它们怎么说话？用HTTP REST还是RPC？最后选了REST，因为简单直观。但鉴权怎么办？每个请求过来，订单服务怎么知道调用它的“人”是合法的用户服务？开始研究JWT，搞明白access token和refresh token的流转机制。写中间件来验证token签名、检查过期时间、解析用户载荷。光是调试一个403 Forbidden错误，就能耗掉我整个下午，因为可能是token格式不对、签名密钥不匹配，或者是上游网关根本没把token传过来。
最崩溃的是调试分布式环境下的数据一致性。用户下单，调用订单服务创建订单，订单服务再去调用库存服务扣减库存。如果库存服务扣减成功了，但返回消息时网络抖动，订单服务以为失败了，怎么办？这就产生了脏数据。我开始接触“分布式事务”、“最终一致性”这些词，头大如斗。暂时用了个土办法，加了个消息状态表，配合定时任务去扫描和补偿，我知道这很糙，但先让系统跑起来再说，这是生存第一。
当我把订单、支付、用户三个核心服务拆完，用Docker跑起来，再用Nginx做一层简单的反向代理和负载均衡，最后用Postman去模拟并发请求时，手都是抖的。发了一百个并发创建订单的请求，监控面板上的响应时间曲线平得像条直线，CPU占用率也没怎么动。那一刻，不是高兴，是有点懵。我又加到五百，一千。服务依然稳如老狗。那种感觉，就像你一直开着辆破拖拉机在泥地里挣扎，突然给你换上了F1赛车的方向盘，你第一个反应是不敢相信，然后是极度的、近乎眩晕的掌控感。我知道前面还有服务治理、链路追踪、熔断降级无数座大山，但至少，我把引擎换掉了，这台车能上高速了。
