How is the service side compatible with multiple versions of the app?

The technical personnel who have done the app product know that the app belongs to a C/s architecture, so it is more troublesome to deal with it in many versions, and it is not as easy as Web application. Here are some common scenarios and coping styles to analyze:
minor changes or new additions.
In this case, the database structure and API programs are generally compatible with multiple versions, so there is no need to force the upgrade to sit in multiple versions coexistence.
The application layer is compatible as much as possible with new fields and APIs at the database level. Of course, the API layer can also deploy multiple versions to provide at the same time, but this is not required
But most importantly, the database-level table structure is compatible with those.

Or:

Summary:  
database level, try to use the new field instead of modifying the principle of the field to avoid affecting the previous business.  
at the service-side level, the API layer is designed to be as flexible as possible, and the access layer can support "routing" best. There are several main ideas, 1. In the API method, either by adding a new parameter or by directly adding an API method (which can also be understood as overloading).  
Fewer changes can be handled in this way, but more changes will be cumbersome and do not take advantage of extensions.  
2. The code is divided into different branch versions, and the API deploys different subwebs. Access is accessed through API.XX.COM/V1 and api.xx.com/v2, or by means of apiv1.xxx.com,apiv2.xxx.com. Of course, can also be in different versions of the app request when the identity, the server through Nginx or Apigateway, etc. to implement service routing.  
This is more visually clear, the workload will be larger, will increase the maintenance and management costs.   the
back-end atomic service also needs to support multiple versions as much as possible.

if it is a big change, the underlying data structure is incompatible, it can only prompt to force the upgrade
If this is a forced upgrade, there will be no more than one version coexistence problem.
There will not be more than one set of databases, and there will be no data synchronization issues.
You only need to do this:
Before Apple submits the audit, we prepared "new version of the data structure and objects (view, proc, function, etc.) scripts, migration scripts or programs, program release files, etc.".
1. Deploy 1 Test databases with new table structures and objects (pre-release environment).
2. Deploy 1 new API sites (different domain names, it is recommended to use the version number in the Domain name distinction. or using a different subweb), configure the Connection test library and test (API site, DB, Cache, ES, Nosql ... These stand-alone pre-release environments)
3. After the Apple audit, update the latest program, the database structure to wait for the production environment, and the API address of the domain name to switch to the production environment (website, admin background, etc. can be published directly), operators in the Apple Store click on the shelves, The server upgrade is complete (there will be a prompt for mandatory updates on the app side). Of course, this process may cause a short period of downtime, so the general choice is to operate at night.
4. Put the latest Android apk into our download station or mirror station, after the completion of the 3-step service program and so on, launch the Android version of the mandatory upgrade prompt (download apk upgrade from our download station or mirror station) in operation background.
In this way, older Android users will be forced to upgrade to the new version without affecting the use.
At the same time, operators also need to distribute and shelves the latest APK packages in each of the Daan markets, providing the latest other channels to download, preventing users from downloading to the old program, and then prompting for a mandatory upgrade impact experience.

• If it is a big change, the database structure and API programs are incompatible, do not want to do a mandatory upgrade, there will be multiple versions coexistence problem

That can only deploy two sets (or more versions) of the database, and for users to produce content and timeliness requirements, need two-way (or even multi-directional) to do synchronization. The core issue is the fact that the database is stateful, which is difficult.
This is prone to problems, conflict, and inconsistent data.
And the data structure is not the same case, it is difficult to go compatible.

Therefore, for the larger changes, the product added new heavyweight features, the business level or the underlying table structure is incompatible, the proposal is to do a mandatory upgrade.

Or:

2. If the underlying data structure is incompatible with large changes, you can only prompt to force the upgrade
If this is a forced upgrade, there will be no more than one version coexistence problem.
There will not be more than one set of databases, and there will be no data synchronization issues.
You only need to do this:
Before Apple submits the audit, we prepared "new version of the data structure and objects (view, proc, function, etc.) scripts, migration scripts or programs, program release files, etc.".
1. Deploy 1 Test databases with new table structures and objects (pre-release environment).
2. Deploy 1 new API sites (different domain names, it is recommended to use the version number in the Domain name distinction. or adopt different sub-sites. by API.XX.COM/V1 and API.XX.COM/V2, configure connection test libraries and tests (API site, DB, Cache, ES, Nosql ...). These stand-alone pre-release environments)
3. After the Apple audit, update the latest program, the database structure to wait for the production environment, and the API address of the domain name to switch to the production environment (website, admin background, etc. can be published directly), operators in the Apple Store click on the shelves, The server upgrade is complete (there will be a prompt for mandatory updates on the app side). Of course, this process may cause a short period of downtime, so the general choice is to operate at night.
4. Put the latest Android apk into our download station or mirror station, after the completion of the 3-step service program and so on, launch the Android version of the mandatory upgrade prompt (download apk upgrade from our download station or mirror station) in operation background.
In this way, older Android users will be forced to upgrade to the new version without affecting the use.
At the same time, operators also need to distribute and shelves the latest APK packages in each of the Daan markets, providing the latest other channels to download, preventing users from downloading to the old program, and then prompting for a mandatory upgrade impact experience.

3. If it is a large change, the database structure and API programs are incompatible,
And don't want to do a mandatory upgrade, there will be multiple versions of coexistence issues
That can only deploy two sets (or more versions) of the database, and for users to produce content and timeliness requirements, need two-way (or even multi-directional) to do synchronization. The core issue is the fact that the database is stateful, which is difficult.
This is prone to problems, conflict, and inconsistent data.
And the data structure is not the same case, it is difficult to go compatible.

Therefore, for the larger changes, the product added new heavyweight features, the business level or the underlying table structure is incompatible, the proposal is to do a mandatory upgrade.

Http://www.cnblogs.com/dinglang/p/6092405.html

How is the service side compatible with multiple versions of the app?