背景
随着达达业务的快速发展，产品上经常需要对APP的逻辑进行更精准快速的变更，最初通过发布新版本的方式来调整逻辑，由于APP版本更新覆盖需要一定的周期，这样做的效果不是很理想。后面我们采用了友盟在线参数来对一些参数进行动态配置，但友盟的在线参数只是一个简单的key－value配置，无法为配置的key附带更多的业务逻辑（比如限定城市和用户），并且配置变更以后也无法立即通知APP，因此我们设计了达达APP配置系统。
目的
从产品上来说，APP配置就是需要准确及时的针对不同类型的用户，执行不同的业务逻辑。在达达的业务场景下，我们经常会对APP按城市和用户的维度做一些配置。例如：
控制一个功能入口的显示和隐藏
比如我们会对某些优质配送员开放达达商城入口，让他们可以购买达达装备；而有些配送员则不开放。
配置APP中的文案
根据不同的运营策略，我们经常要实时调整我们APP内的文案。
下面左图是显示达达商城功能，右图是隐藏达达商城功能：
从技术上来讲，需要满足如下要求：
实时性
服务端的配置发生更新，必须要在尽可能短的时间内通知APP进行配置的变更，尤其对于需要尽快生效的配置更为重要，比如线上服务器压力比较大，需要及时通知APP增加刷新订单的等待时间以降低服务器压力，如果该配置通知到APP的时间比较长，那这条配置也就没有什么意义了，所以实时性也是非常重要的一个要求。同时配置变更通知也需要对用户保证透明性，让用户在无感知的情况下进行配置变更。
高并发
该系统面向的是达达公司所有的APP设备，设备数量是非常多的，如果配置发生更新，必须要考虑大量设备同时访问服务端来更新配置对服务器造成的压力，以及在这种高并发访问下如何保证服务的可用性。
低客户端流量使用
因为该系统主要面向APP端，流量因素也是需要考虑的一个问题，为了节省客户端流量，APP获取更新时不需要每次更新都获取全部配置，只需要获取在上次更新后发生变更的字段，需要支持配置的增量删除/新增/修改等功能
设计及实现
根据需求我们设计并实现了达达APP实时配置系统，包含服务端，Android端和iOS端。
APP配置系统的设计如下图所示：
服务端的架构主要分为数据库层／缓存层（本地缓存层＋Redis缓存层）／配置计算层
配置信息存储在数据库中
使用Redis存储缓存配置信息减小直接读取数据库的压力，同时使用本地缓存与Redis同步，配置直接从本地缓存读取，减少网络IO次数，提高系统性能，减少请求响应时间
配置计算层主要用来进行配置的筛选工作，根据不同的请求条件筛选对应配置，并实现配置的增量更新等功能
在与APP的交互方面，在安卓端我们主要使用了HTTP＋推送的方案，每当配置发生更新，会通过信鸽推送发送一条透传消息给APP，APP收到推送后，执行HTTP请求拉取配置。iOS端因为APNS推送的字节限制，以及APP离线时无法控制让推送内容不在通知栏显示等原因，所以采用了Socket长连接方案来实现，APP启动时会建立一条长连接通道，每当配置发生更新，服务端会主动将更新的配置发送给客户端。
实时性
为满足实时性的要求，我们原来打算使用推送来实现，但是使用推送会面临两个问题：
推送到达时间无法估计
iOS推送如果应用不在线，会在通知栏展示，无法满足对用户透明的需求。
因为以上两个问题，我们对iOS使用了长连接来实现配置的主动推送，APP启动后会建立一条与服务器端的长连接，并维持心跳，每当服务器发生配置变更，会实时的通知在线的APP更新配置，如果APP离线会在在线后收到配置更新的推送，保证配置更新的通知不会在通知栏展示，既解决了实时性的要求，也满足了对用户透明的需要。
高并发
为了解决前面所描述的短时间高并发的问题，我们主要从两个方面来解决这个问题:
APP端：收到配置变更的通知后，会随机延迟0-30s再去服务器拉取配置，防止瞬间的高并发访问导致服务端异常
服务端：为了提升服务端性能，减少网络IO的时间，增加了本地缓存层，数据直接从本地缓存存取，本地缓存与Redis保持同步更新，使用Zookeeper的节点监听功能，当Redis发生修改时主动让Zookeeper通知本地缓存进行配置数据的更新同步;
低客户端流量使用
为了解决节省流量的问题，我们使用了如下两个方案:
使用ProtocolBuf进行数据传输
使用该工具的原因主要有以下两点：
序列化和反序列化性能非常高
序列化后字节数少，非常适合移动端的数据传输
基于以上两个特点，使用该框架可以很好的解决流量和性能的问题。
配置增量更新
所有的配置都带有一个版本号，配置变更会基于版本号进行变动，APP端会持有一个本地的版本号，每次更新请求，在请求服务端时会将APP本地的版本号提供给服务端，服务端根据APP的本地版本号与服务器的版本号进行配置的计算和合并后将发生变动的配置发送给客户端，避免每次将所有配置发送给客户端，只要发送发生变动的配置即可。
服务端
为了实现前面所描述的低流量的需要，我们使用了增量更新的方案来减少客户端的流量消耗，基于版本号的方式实现了配置的增量更新，方案如下：
配置版本（增量更新）的设计
客户端保存一个版本号用于标识APP当前配置的版本，每次APP增量更新配置的时候会将这个版本号发送给服务端，服务端返回该版本号之后发生的所有变动
服务端实现逻辑：
计算从版本0开始到最新版本之间的有效配置
计算从APP版本号到最新版本之间删除的配置
将生效配置和删除配置作配置合并操作，生成最后需要更新的增量配置
配置合并的逻辑如下：
有效配置中有,删除项中没有,若版本≤APP的本地版本号，该配置无变动，不需要通知客户端
有效配置中有,删除项中没有,若版本＞APP的本地版本号，该配置有变动，需要通知客户端更新配置
有效配置中有,删除项中也有,配置可能变动，需要通知客户端更新配置
有效配置中没有,删除项中有,配置项被删除，需要通知客户端删除配置
Android端
设计结构图如下：
要点如下：
使用了推送的方式来保证APP能够实时更新配置
使用了sqlite来同步更新服务器的配置，作为客户的读取配置的数据源
为了安全性和灵活性，使用了本地广播（LocalBroadcast）的方式来通知前台页面（Activity）实时更新界面
核心代码如下：
ConfigList configList = responseBody.getContentAs(ConfigList.class);
if(!Arrays.isEmpty(configList.getResult())) {
for(Config config : configList.getResult()) {
config.setUserId(HttpInterceptor.getUserId());
Config localConfig = getConfig(config.getParamName());
Intent intent = new Intent();
intent.setAction(action(config.getParamName()));
if(config.isDelete()) {
//本地有，但服务器配置已被删除，本地也要被删除
if(localConfig != null)
db.delete(Config.class
, WhereBuilder.b("paramName","=",
config.getParamName())
.and("userId","=", HttpInterceptor.getUserId()));
intent.putExtra(Extras.CONFIG, config);
}elseif(localConfig == null) {
//本地没有，则新增一个配置
db.save(config);
intent.putExtra(Extras.CONFIG, config);
}else{
//本地有，服务器上配置被修改，本地也要被修改
localConfig.setParamValue(config.getParamValue());
db.update(localConfig,"paramValue");
intent.putExtra(Extras.CONFIG, localConfig);
}
localBroadcastManager.sendBroadcast(intent);
}
}
代码主要逻辑如下：
如果从服务端拿到一个删除的配置，则删除本地配置
如果从服务端拿到一个新增的配置，则插入本地数据库
否则，则更新本地的配置
最后，发送配置变更广播通知相应的界面更新UI
iOS端
设计结构图如下：
要点如下：
与服务端维持长连接，保证配置实时更新到客户端
archive配置信息，优先从本地读取，减少异常情况下对业务的不利影响
业务逻辑通过KVO方式使用配置信息，保证客户端配置更新时，业务逻辑及时响应
核心代码如下：
- (void)readCommonConfigWithKey:(NSString*)keyString
configType:(configType)type
Finish:(finishReadConfigInfo)finish {
if(isEmptyString(keyString)) {
finish(nil);
return;
}
DDAppConfigModel*configModel = nil;
if(type==configTypeCommon) {
configModel = [self.commonConfigDictInfo objectForKey:keyString];
if(configModel == nil) {
[self updateConfigWithKey:keyStringtype:typefinish:finish];
}else{
dispatch_async(dispatch_get_main_queue(), ^{
finish(configModel);
});
}
}elseif(type==configTypeAppoint) {
[self updateConfigWithKey:keyStringtype:typefinish:finish];
}
}
代码主要逻辑如下：
业务逻辑请求配置时，优先从内存读取
内存没有，从本地数据存储中查找
本地没有，向服务端拉取配置信息
最后，通过block方式通知调用方，并返回结果
小结
根据上面的设计，达达APP配置系统已经实现了如下功能：
可以针对所有用户、某个城市的用户、某个平台（iOS,Android）的用户、某个APP(达达，商家，派乐趣)的用户以及某些指定id的用户配置参数，来实现不同用户不同客户端的业务逻辑定制
配置生效后，可以给配置用户发送推送，让APP主动获取配置的变更，并实时对APP的逻辑进行调整
APP每次去服务器拉取配置的时候，服务器会根据客户端已有的配置信息返回配置变更的增量，以便节省流量。
更多关于达达技术的文章，敬请关注达达技术公众号。
