facebook客户端_【连载】Facebook如何管理移动客户端的配置项

本系列文章由作者翻译整理，并加入了一些各种大会分享的一些材料。但大部分内容来自于 Facebook Research 网站一篇名为 《holistic configuration management at facebook》，如想查看英文版本，请自行在网上搜索。

内容如下：

03.26：Facebook配置管理(一)：海量服务配置项的管理挑战

03.30：Facebook配置管理(二)：配置管理所用的工具集

04.01：Facebook配置管理(三)：配置的编写和错误预防

04.03：Facebook配置管理(四)：可靠的配置项分发

04.08：Facebook配置管理(五)：强大的滚动发布工具GateKeeper

04.10：Facebook配置管理(六)：移动端配置工具MobileConfig(本篇)

04.14：Facebook配置管理(七)：配置项管理的经验与工程文化

04.16：Facebook配置管理(八)：给业界提出的一些总结和建议

前面几篇中讲了上图中的大部分工具。今天讲最后一个工具：MobileConfig。

一、Mobile Config 的架构

移动应用程序的配置管理不同于在数据中心运行的应用程序的配置管理，因为移动环境中存在独特的挑战。包括：

1. 移动网络就是一个严重的限制因素

2. 移动平台形式多样，至少要支持Android和iOS

3. 移动应用程序的遗留版本会持续很长时间，这给向后兼容性带来了挑战。

MobileConfig 解决了这些挑战，同时最大化了在数据中心运行的应用程序已经开发的配置管理工具的重用。下图显示了MobileConfig的体系结构。

在移动应用程序的本地中，每个配置都表示为Context类。应用程序调用Context类的getter方法来检索配置字段的值。支持Context类的客户端库使用C++中实现，以便在Android和iOS之间移植。

由于消息推送并不可靠，MobileConfig不能仅仅依赖Push模式来进行配置分发。

客户端库轮询服务器的配置更改(例如，每小时一次)，并将配置进行本地缓存，以供后面重用。为了最小化带宽消耗，客户端将配置架构的哈希(用于版本控制)和缓存在客户端上的配置值的哈希发送到服务器。

在未来的版本中，一个可能的提升是在服务端保存状态，例如记住每个客户端的哈希，以避免重复发送没有变化的值。(也不知道现在实现了没有？)

服务器仅发送已更改且与客户端架构版本相关的配置。除了pull之外，服务器偶尔会通过push通知将紧急配置更改推送到客户端，例如，立即禁用有缺陷的产品功能。推拉相结合，解决方案简单可靠。

为了处理移动应用程序的遗留版本，MobileConfig 将抽象与实现分离是头等大事。上图中的翻译层提供了一个间接层级来灵活地将 MobileConfig 字段映射到后端配置。这个映射可以更改。

例如，最初 voip echo 被映射到一个由GK支持的实验。在这个实验中，满足上篇图中不同的if-语句会给 voip echo 一个不同的实验参数值。实验结束并找到最佳参数后，可以将voip echo重新映射到Configerator中存储的常量。

从长远来看，所有的后端系统(如 Gk 和 Configerator )都可能被新系统取代。只需改变转换层的映射即可顺利完成迁移。

为了扩展到超过10亿个移动设备，翻译层运行在许多服务器上翻译映射存储在Configerator中，并分发到所有翻译服务器。

到这里为止，我们基本已经介绍完Facebook做全面配置管理所有的相关工具。从中我们可以看出，必须通过多种管理工具对配置项的全生命周期进行管理，而不是仅仅依靠单一工具，就能解决一切配置项的管理问题。

(未完待续～)

下图为前面一篇关于GateKeeper中提到的GK 级联开关依赖图。图有一点糊，但仔细看还是可以看明白。