在很多公司都会面临同样尴尬的境地:

App属于一种C/S架构,并不像B/S架构那样,web应用比较便捷,带来的苦恼也是接憧而至

1.存在新的改动和新功能增加

(1)面临这种情况,数据库结构和API程序一般是可以兼容多版本的,所以不用强制升级,可以坐到多版本共存。
(2)尽量采用数据库层面新增字段和API的方式,应用程序层面就可以兼容了。
(3)API层面也可以部署多个版本来同时提供,这个是可以选的,但最重要的是数据库层面的表结构那些能够兼容到。

如图:

或者多版本共存

要想实现多版本共存,前期考虑工作需要做到以下几点:
1、数据库层面,尽量采用新增字段,而不是直接修改字段的原则,避免影响以前的业务。
2、服务端程序层面,API层尽量设计灵活,接入层可以支持“路由”最佳。主要有几种思路,1. 在API方法中通过新增参数或者直接新增API方法(也可以理解为重载)

以上只适合,改动较少的情况下,改动频繁,导致不利于扩展

1、代码分不同分支版本,API部署不同子站点。通过api.xx.com/V1 和api.xx.com/V2方式访问,或者通过apiV1.xxx.com,apiV2.xxx.com等方式区分访问。当然,也可以在APP不同版本中请求时传入标识,服务端通过Nginx或者APIGateWay等来实现服务路由。
2\这种直观上更加清晰,工作量也会大一些,会增加一定的维护和管理成本。
3、后端的原子服务,也需要尽可能支持多版本。

如果是大改动,底层数据结构都不兼容,那只能提示强制升级了
如果是强制升级,就不会有多版本共存的问题了,
也不会有多套数据库,也不会存在数据同步的问题。

打赏作者

Leave a Reply

Your email address will not be published.