作者:时文涛
部门:电商移动
作为移动开发的我们经常会遇到两种需求:
为了解决以上问题,就需要App侧具备一定的动态化能力。目前增强App端的动态性方式,通常来说有下面几类:
在面向商家端的 App 上,商家需要保证线上功能的稳定性,在功能迭代较快的场景下,如何保证 App 端上线后可以动态调整,不影响用户的使用呢?
在微商城 App 中,Hybrid 和 Weex 都有在使用,但是常用功能为了用户体验及改造成本,大家一般还是会使用原生开发。那么如何使得原生页面的 App 端每次上新功能的时候,可以让少部分的数据动态变更呢? 在这一点上后端的 Apllo 给了我们灵感,App 侧其实也是可以使用类似的方案,来实现线上业务的降级配置的。当线上新功能出现问题时,使用配置中心进行降级处理,待 Weex 发版或热修复下发后,重新打开新功能,可以最大限度的降低 App 端线上业务的影响。同时,业务方也可以利用配置的下发能力来限定功能的升降级范围,以对业务进行灰度测试。为了补齐原生侧的这部分能力,我们开始了对配置中心的设计。
从开发的角度获取了配置中心需要提供以下能力:
配置中心自开始开发以来,一共进行了两次大的迭代,分为了 1.0 和 2.0 两个版本:
在配置中心后端下发的整个过程中,大体分为4个步骤:
其中,组件是配置中心配置下发的场景下使用范围抽象出的一个概念,可能是一个 App ,也可能是一个 SDK 。配置单则是配置下发的单位,每次发布会新建一份配置单,内部包含了多个 KV 数据,是下发时的最小单位。下发状态匹配的流程,是为了通过检查告知 SDK 是否需要更新本地缓存的配置,减少组件 KV 较多的情况下,每次更新重新啦取所有 KV 造成的重复读写和网络流量的消耗。
具体配置中心的下发流程,可以参照下图来进行理解:
除了以上下发流程的调整外,配置中心还通过接入移动基础保障平台来完成配置发布的审核,防止出现线上数据被误操作导致故障的场景出现。
SDK侧整个下发流程也就可以简化为下图所示:
虽然配置中心上线后大家在使用过程中没有遇到线上问题,配置中心很好的完成了它的任务,但是这一版本的配置中心还是有着明显的优缺点的:
优点:
缺点:
虽然配置中心 V1.0 的版本有部分缺点,但是对当前配置使用并没有什么影响,尽管在使用过程中也有同学提出,A/B Test 的支持的需求,由于改动成本比较高,所以这项需求的优先度并没有提的很高,直到项目并行越来越多,发现配置中心由部分场景开始难以满足新的需求了。
随着业务的告诉迭代,很多项目已经开始习惯于使用配置中心来进行新功能的降级以及灰度,在同一个组件同时有多个项目在灰度的过程中,由于灰度条件的限制不同,导致了大家需要相互妥协。也就是在这个时候开始,我们发现现有的设计已经无法满足大家的需求了,大家目前需要的灰度范围不是整个分发配置单,而是具体某个 KV 。所以经过了新一轮的需求的收集,我们决定对配置中心的组件进行一次升级,以满足多项目并行的灰度场景和A/B Test 的测试场景。 在这次的组件升级中,我们对组件的下发流程进行了一次比较大的优化:
新组件发布后,配置中心的整个下发流程有了较大变化:
同时,在管理平台发布新组件的逻辑处理流程也变得相对复杂了一些,着些新增的处理逻辑是为了减少 SDK 检测配置更新时减少 DB 查询等待的时间,变更后的 KV 发布时数据库变更逻辑见下图:
使用展示
在配置中心的最新版本中,每个 KV 都能清晰的展示出其 KV 的类型、功能及适用版本
点击进入后,可以查看到具体的具体的 KV 发布记录,可以进行回滚、同步、复制等操作
编辑 KV 的过程中,用户可以选择下发的范围及下发 KV 的格式
对于客户端而言(以 Android 为例):只需要初始化和获取 KV 值两部分代码即可使用配置中心。接入示例:
ConfigCenter.init(this).setConfigKey(configKey,moduleVersion,CONFIG_FILE,CLIENT_ID,CLIENT_SECRET,otherInfo)
取值示例:
var result =
ConfigCenter.getInstance().getStringByKey(STUDY_CONFIG_CENTER_KEY, configKey, "")
经过简单的配置,客户端的业务逻辑即可实现动态切换的效果。
以上是我们整个配置中心的建设方案,通过配置中心的使用,对原生 App 动态性的短板进行了补齐,也可以帮助业务方对新业务的线上灰度提供帮助,高效快捷的控制灰度范围,希望可以和广大开发同学一起交流改进。