先废话上几句吧。
终于开始写这一篇了。这篇是规划的SDK总结系列的最后一篇,也是比较难写的一篇了。之前以为经过了这么多的坑,再来写这个系列没那么难,规划的就比较多。真的开始写的时候发现问题还是很多,加上中间一些个人的事情耽误,陆陆续续就写了两个月了(最近有点碎碎念,发现时间过的太快了)。希望这个周可以第一次完结!
和之前规划一致,这篇文章主要是对SDK的前路的一些思考。也是自己一直在思考,感觉团队也在思考的事情。从去年开始,我们的SDK就开始进入了稳定期,不会再有太多的新功能,很大的版本。这个时候SDK的主要功能,或者所有功能都已经完成以后,基于这个SDK我们还可以做什么?这里就说一说我们现在在做和自己认为还可以做的东西吧。
除非一开始有一个比较牛逼或者有经验的开发来设计一套有效的成熟的架构(很可惜,我觉得我们当时设计的架构并不是很好),一般SDK前期的开发时间都很紧张,而且更多的精力聚焦在功能的实现上,因此很多时候采用的都是最快的解决方案,紧工难出细活,因此时间久了就会积累一些问题。而当SDK的功能开始稳定的时候,就该是划出时间和精力来通过重构优化代码模块和一些具体的实现了。
这部分主要是针对SDK的一些技术上的改善和优化。通过模块化和插件化,SDK的开发者和使用者都可以很大的提高开发效率。
模块化
将SDK代码进行重构,让SDK可以更加容易扩展,尽量减少模块之间的耦合。让各个功能模块更加独立,甚至可以做到轻松的添加和删除模块而不会对别的模块有任何影响。这种做法可以轻松应对下面两种很常见的需求:
插件化
模块化主要是为了方便SDK的开发者适应各种需求的变化。而插件化则更主要的是为了方便SDK的使用者。当SDK的功能越来越多带来的最直接的问题就是SDK的包也会越来越大。对于有些开发者他只接入部分SDK功能却要集成整个包其实是不合理的。
插件化就是指SDK开发者可以根据使用者需求提供接入相对应功能的差异化的SDK包,开发者可以自由动态生成SDK包来适应不同的需求。
这部分主要是针对SDK的云端控制、业务隔离等的一些思考。通过全局限频、配置管理等模块一方面可以降低业务之间的相互影响,也更有利于SDK一些简单问题的修复。
后台控制
这部分主要是对于后台接口的调用的控制。包括权限控制、和全局限频等。权限控制用于控制应用对于接口访问的合法性,全局限频主要是针对每个APP,对于调用量应该给出限制。防止单个业务被攻击或者流量突然升高引起其余业务接口调用的不稳定。
这里额外补充两点点关于全局限频的。
全局限频怎么做:
最简单的就是有一个地方记录调用额度,定时刷新额度,在接口调用时,每调用一次去减一。这种对于单台服务器比较容易,当分布部署以后就比较复杂,需要考虑更多的细节。
因此一般的分布部署都是通过另一种方法:分布部署必然会有负载均衡,因此根据机器的数量将应用调用总量均分到每台机器上,当对应机器的限额用完,就提示超频。
全局限频怎么限
首先所有的应用会有一个预先的配额,作为预警配额,这个配额是根据应用情况预估的;其次除了预警配额还会有一个阈值的配合
客户端配置
云端配置是指客户端的一些开关、关键是配置值可以通过后台来修改。这样做可以:
关键日志
关键日志上报同样是为了SDK的开发方便问题定位。主要用在以下场景:
当游戏客户端遇到问题的时候,打开指定用户的日志控制开关,他就可以把本地日志远程上传。协助开发者分析错误,定位问题。
对于业务逻辑下的某些异常逻辑增加关键日志自动上报,就可以协助开发者提前发现和定位解决问题,不再被动。
数据上报
数据上报的意义更加重大了,尤其是当数据上报和关键日志、云端配置配合,就是客户端问题定位的神器。这个地方的数据上报不包括一些接口调用数据等正常数据的上报。
通过异常数据的实时上报,我们可以:
建立一套客户端的监控和告警机制,实时了解客户端版本情况。当某一接口异常的时候,提前开启关键日志分析问题。
除了解决问题,客户端的异常上报如果包含了后台接口的返回异常,就可以同时监控后台接口的稳定性,尤其是当后台接口的监控和告警不可信的时候,可以及时通知后台。(别不信,现实中这种情况太多太多)
网络请求、配置、DB数据存储等,采用更高效、更安全的处理措施。具体的例如:
网络请求
可以使用https,既可以提高安全性,还可以防止国内运营商常见的DNS劫持等问题。
配置、DB数据存储
这部分主要包括:
具体的做法可以有:
上面讲的都是当SDK的基础功能开发结束以后,技术侧还能做什么。当技术相关的优化工作都做完的时候,还能继续做什么呢?下面主要是从非技术的角度进一步分析一下:
分级服务是指对与接入SDK的业务进行分级支持(当然如果你的人力充足,完全不用分级)。分级服务的原因就是给开发者提供更多有利于他开发的支持。比如:
SDK详细介绍
SDK的接入教程,甚至是视频的,图文的等。
面对面的联调支持
一般的游戏开发者都只熟悉引擎,不熟悉Android系统,所以协助游戏解决一些他们遇到的系统相关的问题等
熟悉开发者常用的框架或者工具,了解SDK与这些框架和工具结合的时候会有哪些问题,怎么解决
对于这部分工作,个人其实是比较有争议的,虽然我也认同SDK发展到最后就是提供服务,就是做服务。但是应该有一个红线或者一个度在里面。我们应该是尽最大的努力做好份内的事,而不死越俎代庖去协助开发者解决开发者开发中遇到的问题。
这部分内容主要说一下SDK相关的数据分析和数据挖掘相关的内容。这部分内容本来计划用一篇文章来规划说明的,竟然忘了。那就简单汇总一下添加到这里吧。
接口调用数据
接口调用数据,包括接口调用的成功率,失败率,调用次数等。这部分主要用来监控接口的稳定性,及时的发现问题。另一方面这些数据也是SDK的品牌数据,用于进行数据推广等。
开发者、接入应用相关数据。
开发者和应用相关的数据包括,开发者的地域分布、接入应用的类型、单开发者接入应用的数量等等。这部分数据有助于了解当前开发者的活跃地带,为商务提供支持,了解目前的接入应用的分布,可以了解应用市场的走向。
SDK的使用习惯数据。
SDK的使用习惯数据包括某个功能开发者一般用来做什么等,例如SDK面向用户的公告,开发者一般用来发公告还是活动,一般同一时间内有效的会有几条,发送的频率一般是多久等。这部分数据可以协助新的开发者更有经验的使用SDK的相关功能,同时将SDK的功能最大化。
SDK的用户数据。
用户数据内容比较多,再细分一下,包括用户个人数据,用户设备数据,用户使用习惯数据、用户和应用的相关性数据。
在大数据的时候,数据的拥有者是大有可为的,基于SDK的数据分析,可以为SDK的开发者,SDK的使用者提供更多的基于数据分析的运营、开发、决策等建议。然而这部分缺又是最容易忽略的。
另外做大数据的前提是,SDK的接入量要足够多,使用用户要足够大,这是一个持续而且旷日持久、前人栽树,后人乘凉的过程。