客户端协议兼容性的踩坑教训

美拍在开放扩展性上关注五个点：代码功能的可扩展性、交互协议的扩展性、数据存储格式的可扩展性、应用的可扩展性、资源的可扩展性。其中交互协议的扩展性有一个和其他后端服务完全不同的特殊性——App客户端和服务端的交互协议，App的升级周期比服务端升级慢得多：服务端可以随时发布，但客户端版本发布后，如果用户一直不升级，这个滞后时间可能是几个月、半年甚至一年，这就必然会引入版本兼容问题，因此协议层面设计的关键点是要保证协议能够向前兼容、并提前预留好扩展点。数据存储格式的可扩展性上，美拍经历了一次典型演化：第一版每个属性在数据库中对应一个字段，为了留一点扩展空间，多加了几个预留字段；随着业务发展，这套方式演化成了把所有属性字段序列化为protocol buffer数据的方式，这样更能满足业务快速迭代的需求。但团队特别强调一个容易被忽视的教训：大家往往更关注服务端的兼容性问题，但实际上客户端有时候更容易踩坑——曾经踩过的一个具体坑是，客户端上有个ID字段的数据类型用的是int32，而客户端基本很难做强制升级，就这么一个看起来很小的类型选择问题，最终需要花很长时间才能消化解决，还得为此专门做一堆兼容工作。这条教训的可迁移价值在于：一旦某个字段类型或协议约定被写进了客户端代码、并且这份客户端已经分发到了大量无法被强制升级的终端设备上，这个决策就变成了事实上不可逆的——服务端出问题还能马上修、马上发版，但客户端出问题往往要背负很长时间的兼容包袱。这条经验直接给出了一条实践建议：任何要写进客户端的协议设计（尤其是数据类型这类细节），一开始就要多留意、尽量少给将来埋坑，因为客户端这一侧犯错的纠正成本，远比服务端高得多。