暴雪这事儿一出，我团队里几个做海外游戏社区工具的小伙子彻底慌了。他们那个 SaaS，核心功能就是抓取《炉石传说》的玩家对战数据做分析，API 调用量一个月上千万次。现在源头可能说没就没，整个业务逻辑直接归零。
这已经不是第一次了。去年我们给一个跨境电商客户做价格监控，亚马逊反爬策略一升级，整个爬虫架构就得推倒重来，三周时间全搭进去，客户还觉得是我们技术不行。现在团队养了十几号人，每天一睁眼就是工资、服务器、办公室租金，现金流看着漂亮，但命脉全捏在别人手里。这种焦虑，比 2017 年我一个人单干时那种对技术的焦虑，要致命十倍。那时候大不了重写代码，现在是一船人等着你找方向。
出海 SaaS 的合规，从来不是简单的“遵守用户协议”那么简单。它是个动态的、充满政治和商业博弈的灰色地带。暴雪和网易的协议纠纷，本质上和 Facebook 突然调整 Graph API 的权限、Google 修改搜索算法没有区别，都是平台方基于自身利益的规则重置。我们这种寄生在平台生态里的开发者，就是最脆弱的那一环。你以为你在做产品，其实你只是在规则的缝隙里捡面包屑。
技术剥离，必须提上日程了。不是那种“多接几个数据源”的浅层方案，而是从架构层面，让业务逻辑和具体的数据获取方式解耦。我们正在把数据采集层彻底模块化、服务化。比如对战数据，不再是写死调用暴雪 API，而是抽象成一个“游戏数据采集服务”，内部定义好数据结构和更新频率。底层可以是官方 API，可以是经过合规处理的社区数据，甚至在极端情况下，可以切换到模拟客户端协议采集（当然，这得在法律框架内死磕）。上层的数据分析和展示业务，完全不需要知道数据是怎么来的。
这需要巨大的重构成本。团队里有人抱怨，说现在功能开发都忙不过来，还搞这种底层改造，是不是太理想化了。我理解，这就是管理毒打的一部分：你明知道什么是对的，但眼前的生存压力逼着你只能去补那些漏水的窟窿。但这次我强硬了。我算了一笔账：如果暴雪 API 真断了，我们现在的代码就是一堆废铁，团队立刻无事可做，崩溃只在一瞬间。而投入两个月做架构改造，即使暴雪没事，我们也获得了接入其他游戏数据的能力，风险被分摊了。
具体到技术，我们在用消息队列把数据采集任务异步化，每个采集源都是一个独立的 worker，通过配置中心动态启停和切换。认证信息、频率限制、重试策略全部集中管理。前端所有数据展示的模块，对接的是一个统一的数据聚合网关，网关后面才是千变万化的采集集群。这相当于在业务和危险的“围墙花园”之间，筑起了一道缓冲壕沟。
Flovico 这个品牌，未来不能只是一个接外包项目的团队名字。它得代表一种生存模式：通过技术架构的设计，让自己在多变的环境里获得一点可怜的主动权。这不是什么高大上的中台概念，这就是数字时代的手工业者，为了不被平台掐死而必备的狡兔三窟。赚流水的时候觉得自由，现在才明白，没有抗风险能力的自由，都是幻觉。
炉石的风波或许会平息，但平台的重锤永远高悬。我们能做的，就是把自己的房子，建得稍微离悬崖远那么一点点。今晚又得跟技术骨干熬到后半夜，把新的采集服务部署文档敲定。身体又开始报警了，但没办法，这坑是自己当初扩大规模时亲手挖的，现在含着泪也得填。
