作为移动app的第三方插件，如何避免插件服务端版本爆炸？ 举报 理由 举报 取消 我们开发的应用是一个第三方支付插件，作为静态库（android是.jar,ios是.so）集成到商户自己的app上。现在的问题是一旦商户集成了我们的插件且投入使用，我们就几乎不可能要求商户更新插件，因为更新插件意味着要强制更新安装在用户手机上的商户app。这就导致了市场上同时有很多不同版本的插件在使用，导致插件的服务端要维护很多不同版本的api，随着插件的不断升级，且无法通过强制升级客户端丢弃旧版本的插件，导致服务端的api版本爆炸。 2018年2月6日 1 条回复 882 次浏览 产品,开发,支付,支付系统
回复 ( 1 )
1、在接口协议中带上客户端/SDK的协议号
通过接口协议版本号，标识调用的客户端/SDK，从而能够将请求路由到对应的业务接口/服务。服务路由的概念与接口分层和SOA有关。参考2、3点。
2、接口分层
粗略说来，对客户端/SDK的接口一定要与业务接口/服务分离开。
对于业务逻辑简单的应用来说，将客户端接口和业务接口掺杂在一起问题不大。但对于像支付等业务逻辑较为复杂且易变的应用来说，建议一定要及早将客户端接口与业务接口分离开。
3、服务器端架构设计及早考虑SOA及服务治理问题
服务器端版本爆炸问题，一般都与后端业务逻辑的新增/变更有关。
对于后端业务逻辑复杂的应用，如果服务器端系统功能间调用采用传统远程接口调用（RPC、Web Service、Thrift、Hession等）方式，系统变复杂后，接口之间的调用关系维护确实令人头大。此时侯采用SOA及服务治理就变得有意义了。
建议可以参考Dubbo+Zookeeper或ESB（例如Mule）模式，在架构设计早期及早考虑SOA及服务治理问题。尤其是Dubbo的服务路由、服务接口版本、采用Zookeeper进行服务注册，对于解决接口版本爆炸的问题还是挺有参考价值的。
4、客户端/SDK及服务器端做好日志处理及分析
在这里的主要意义在于分析各个版本客户端/SDK接口调用频率/活跃度，对那些调用频率极低的接口，可以与商家商量，采用强制升级的方式升级或停用。