更新 应用系统的设计与升级
parent
4665a3084f
commit
0bb01a1222
|
|
@ -1,6 +1,6 @@
|
|||
# 主要对象及相关关系
|
||||
|
||||
在oak-general-business的对象中，有以下几个数据结构和应用本身相关联：
|
||||
在*oak-general-business*的对象中，有以下几个数据结构和应用本身相关联：
|
||||
* application
|
||||
|
||||
表示一个前端应用（其*type*属性表达了该应用是App/网站/公众号/小程序类型）
|
||||
|
|
@ -18,13 +18,13 @@
|
|||
|
||||
# 应用启动过程
|
||||
|
||||
某个应用在初始化时，首先通过调用getApplication接口（src/aspects/application）去查询确定当前application。其主要依据是type和domain，同时传入当前app的version。
|
||||
某个应用在初始化时，首先通过调用*getApplication*接口（*src/aspects/application*）去查询确定当前*Application*。其主要依据是*type*和*domain*，同时传入当前App的*version*。
|
||||
|
||||
## 应用的version如何确定
|
||||
## 当前应用的version
|
||||
应用的Version在编译时确定，编译器会自动将项目目录下package.json中的version号注入到编译文件中，用之作为应用的版本号。
|
||||
|
||||
```tips
|
||||
如果在应用开发中需要取当前应用的版本号，可以编写一个oakGetPackageJsonVersion函数，函数体直接返回任意字符串。oak在前端打包时，会自动将package.json中的version注入返回（参见src/utils/appVersion.ts）。
|
||||
如果在应用开发中需要取当前应用的版本号，可以编写一个*oakGetPackageJsonVersion*函数，直接返回任意字符串。oak在前端打包时，会自动将package.json中的version注入返回（参见*src/utils/appVersion.ts*）。
|
||||
```
|
||||
|
||||
# 应用的版本号规定
|
||||
|
|
@ -41,7 +41,7 @@ Oak框架的前后端代码不分开，因此可以很优雅的保持前后端
|
|||
1. 尽管最新版本号中的a或者b已经变更过了，但应用（客户端）的历史版本仍然需要支持，不能强制客户升级；
|
||||
2. 某一个版本的应用（客户端）代码存在致命缺陷，需要强制客户升级。
|
||||
|
||||
第一种情况非常常见，由于Oak框架中绝大多数的前后端通信都是通过select/operate这样的接口来实现，因此要在数据结构已经升级了的情况下，仍然保证之前旧版本的应用可以使用。解决方案就是：在新的开发过程中，数据结构只增加属性，同时将（在新版本中）已经废除的属性通过trigger保持其数据的有效性（这类trigger应当加以特别的标识）；同理，已经废弃的对象，也一样通过trigger保持其数据的有效性。
|
||||
第一种情况非常常见，由于Oak框架中绝大多数的前后端通信都是通过*select/operate*这样的接口来实现，因此要在数据结构已经升级了的情况下，仍然保证之前旧版本的应用可以使用。解决方案就是：在新的开发过程中，数据结构只增加属性，同时将（在新版本中）已经废除的属性通过trigger保持其数据的有效性（这类trigger应当加以特别的标识）；同理，已经废弃的对象，也一样通过trigger保持其数据的有效性。
|
||||
|
||||
但很显然，这种做法随着版本的增多，会留存大量的垃圾数据（和少量的垃圾代码）。因此对于历史版本的支持也不能是无限期的。随着时间的流逝，历史最低支持的版本号被提升，此时比该版本号更低的版本所残留的数据结构（以及相应的trigger）就可以删除了。
|
||||
|
||||
|
|
@ -49,19 +49,19 @@ Oak框架的前后端代码不分开，因此可以很优雅的保持前后端
|
|||
|
||||
# 实现
|
||||
|
||||
在Application对象中，有三个属性：
|
||||
在*Application*对象中，有三个属性：
|
||||
|
||||
* dangerousVersions：表示此*application*强制升级的版本号
|
||||
* warningVersions：表示此*application*建议升级的版本号
|
||||
* soaVersion：此应用的最新版本
|
||||
* *dangerousVersions*：表示此*Application*强制升级的版本号
|
||||
* *warningVersions*：表示此*Application*建议升级的版本号
|
||||
* *soaVersion*：此应用的最新版本
|
||||
|
||||
在*component/application/upsert*组件中，可以对之进行编辑。
|
||||
|
||||
|
||||
|
||||
在System/Platform对象中，有一个属性：
|
||||
在*System/Platform*对象中，有一个属性：
|
||||
|
||||
* oldestVersion：表示此*system/platform*所支持的最低版本号
|
||||
* *oldestVersion*：表示此*System/Platform*所支持的最低版本号
|
||||
|
||||
同样，在*components/system/upsert*组件中，也可以对之进行编辑
|
||||
|
||||
|
|
@ -70,8 +70,8 @@ Oak框架的前后端代码不分开，因此可以很优雅的保持前后端
|
|||
|
||||
1. 当应用初始化时，后台会检查应用的当前版本号是否：
|
||||
|
||||
* 低于该*system/platform*所支持的最低版本号
|
||||
* 位于该*application*的*dangerousVersions*中
|
||||
* 低于该*System/Platform*所支持的最低版本号
|
||||
* 位于该*Application*的*dangerousVersions*中
|
||||
|
||||
如果满足其中之一，则会向应用抛出*OakApplicationHasToUpgrade*异常，此时框架根据自身的情况加以处理如下：
|
||||
|
||||
|
|
@ -79,12 +79,12 @@ Oak框架的前后端代码不分开，因此可以很优雅的保持前后端
|
|||
* 小程序自动更新
|
||||
* App提示用户去应用市场升级
|
||||
|
||||
2. 如果当前版本号位于*application*的*warningVersions*中，在初始化时，会返回此属性，暂时还未作进一步处理。
|
||||
2. 如果当前版本号位于*Application*的*warningVersions*中，在初始化时，会返回此属性，暂时还未作进一步处理。
|
||||
|
||||
## 应用初始化后的情况
|
||||
|
||||
如果系统在应用使用的过程中产生了升级，则此时应用可能会处于一个“不安全”的状态中（逃脱了初始化过程中的安全检查）。为了性能考虑，目前并没有在每次网络请求的时候都对应用版本加以检查，而是用了另一种策略：当应用产生了不可识别的异常时，系统会去检查应用的当前version和该*application*的*soaVersion*是否一致，若不一致，也会抛出*OakApplicationHasToUpgrade*异常使用户升级。
|
||||
如果系统在应用使用的过程中产生了升级，则此时应用可能会处于一个“不安全”的状态中（逃脱了初始化过程中的安全检查）。为了性能考虑，目前并没有在每次网络请求的时候都对应用版本加以检查，而是用了另一种策略：当应用产生了不可识别的异常时，系统会去检查应用的当前*version*和该*Application*的*soaVersion*是否一致，若不一致，也会抛出*OakApplicationHasToUpgrade*异常使用户升级。
|
||||
|
||||
|
||||
# 最新版本号
|
||||
前面说过，由于Oak是前后台代码一体化的开发框架，因此后台（System/Platform）和前台（Application）可以共用开发线上的package.json中的version作为其最新版本号，但各版本之间可能会有细微的差别，这体现在版本号（a.b.c）的最后一位c上。因为如果系统更新了a或者b，其应用必然要重新编译发布。但是更新c也即修正bug，可能只需要发布某一个应用，或者只更新部署后台，导致不同的*application*会有不同的最新版本号。因此，*application*的最新版本号*soaVersion*需要程序员在后台进行维护。
|
||||
前面说过，由于Oak是前后台代码一体化的开发框架，因此后台（*System/Platform*）和前台（*Application*）可以共用开发线上的package.json中的version作为其最新版本号，但各版本之间可能会有细微的差别，这体现在版本号（a.b.c）的最后一位c上。因为如果系统更新了a或者b，其应用必然要重新编译发布。但是更新c也即修正bug，可能只需要发布某一个应用，或者只更新部署后台，导致不同的*Application*会有不同的最新版本号。因此，*Application*的最新版本号*soaVersion*需要程序员在后台进行维护。
|
||||
|
|
|
|||
Loading…
Reference in New Issue