稳定、灵活、高效，美团点评运营配置平台的设计与实践之道

编者按：本文来自微信公众号“InfoQ”（ID：infoqchina），作者 蒋国宝、小智。36氪经授权转载。

两年前，我以听众身份参加了一次 QCon 大会。那次大会提升了我自己在技术的深度和广度，让我受益匪浅。今年很荣幸作为受邀讲师参加 QCon 上海站，在这次主题中我分享了自己这几年来做运营配置平台的一些经验和感悟。希望能给同行在解决类似问题的时候一些新思路和新方向。

1 打造好一个运营配置平台最重要的点是什么？

运营配置平台是满足产品在迭代过程中不断变化的一些配置资源（包括图片、文本、链接等）的管理。主要有三个关键点：

• 第一个是高效，如何理解高效？简单来说就是好用，运营配置平台是给产品同学用的。交付给产品的工具，你不可能说这个东西你去改改数据库它就生效了。那肯定行不通，产品同学也不知道数据库如何操作。况且，你不可能让产品同学去写 SQL。

• 第二个是灵活。灵活怎么理解？因为产品的需求是不断变化的，我们很难琢磨产品整个业务形态的发展变化，所以运营配置平台要做的足够灵活才能满足产品不断迭代的需求。

• 第三点是稳定，我是做移动后端的，为 C 端用户提供数据服务。从后端的角度来看稳定性是第一位的，无论什么时候都不能挂。即使挂了，接入方还能正确获取到你的数据。做到这点，稳定性就有很大的保障。

2 高效的工具平台可以从哪几个点入手？

通过这些年积累的经验，我觉得可以从以下几个方面进行着手。

第一点就是所见即所得的可视化界面，这样能大大提升操作的便捷性，也易于理解。在这里，我通过一个商户页的模块化例子做了详细的说明。如下图所示，对商户页做一个模块化的拆分，拆分后的模块可进行自由的组装和排序，从而达到运营可配置。

在运营配置界面，我们做了一个可视化的操作界面（如下图）。操作界面的最左边是可复用的模块池列表，这些可复用的模块列表是 C 端同学开发并积累起来的。操作界面的中间部分是动态化的配置管理，运营同学可对模块进行灵活的调整，包括模块的添加、删除、以及顺序的调整等。操作界面最右边是实际在 C 端显示的效果。

第二点是上线的流程化，  配置完成之后是不是直接生效？我们最开始做的版本就是配置完成后点提交就生效。这样的流程会有什么问题？大家想一想，如果我配置错了，那是不是会影响生产环境？对用户造成困惑，这是一个关键点。另外，在不同的商户页里它所需要的配置是不一样的。比如说餐饮如果配置一个亲子的模块，那就是一个很大的失误。所以在这里面我们引入了审核机制来保证上线的可靠性。在实现上，我们将数据切分成三大块：后台数据、流程数据和线上数据。在数据层面做隔离，在流程上做把控，保证了上线的稳定性。

第三点是提前预览，也称之为测试预览。产品有这样的诉求，希望配置在发布上线之前看到实际上线后的效果。那如何实现呢？其实很简单，我们每个设备它都有一个唯一的标识，我们称之为设备 ID。APP 发起数据请求，数据进入到业务接入层，再调运营配置服务拿到数据。在这个调用的过程中我们会判断一下这个设备是不是测试用户的设备，那如何判断它是否为测试用户设备？产品在上线路过程中如果想测试的话，必须把自己设备的 ID 加入到测试用户集里面去。这里我们提供一个扫描二维码的功能，把自己的设备 ID 直接加入到测试用户集里。流程如下所示：

3 在快速迭代过程中，如何保证运营配置平台的灵活性？

越复杂的需求我们需要做越简单的设计，我们怎么做的呢？其实很简单，数据存储我们采用 JSON 格式，保证能应对需求的灵活变化。我们知道 JSON 有一个很大的特点就是灵活，K/V 可以随时增删。但是这里面还有一点，但光存储还不够，因为 JSON 的 K/V 结构。这里 K/V 如何定？必然需要有一个字段管理的流程。如下图，从右边运营人员看到的运营界面是一个动态化的界面。这个动态化界面由两部分组成，第一部分是数据，第二部分是控制这个页面展示的一个字段。通过这两点，最终生成一个动态化的渲染页面（运营人员实际操作的界面）。C 端用户通过不同的业务接入层，业务接入层再通过 SDK 获取我们的配置数据，最后在 C 端显示。

4 怎样提供稳定可靠的配置数据服务？

经常有业务同学过来找我，问我们的系统能保证什么样的稳定性。我说我们的系统能保持这样的稳定性：即使我们系统挂了，你也能拿到数据，这样的话你是不是很放心？你肯定很放心。在稳定性方面，我们进行了三个阶段的演进.

最初的时候，我们采用的是经典的数据存储方案：C 端用户到业务接入层，到配置后台数据服务，最后到数据库。业务接入层去调配置后台数据服务的时候是通过 RPC 方式进行调用的。配置后台数据服务是怎么取的？首先会从 Redis 里取，当 Redis 缓存里没有数据，就去数据库里取，同时把数据库里的数据同步到 Redis 里面去，最后把数据进行返回。这种架构它有什么缺点？

我相信做过整体架构设计的同学有很多体会，任何架构都是为满足业务需要的。可能很多同学说这种架构是很完美的，其实它是有很多的缺点的。首先配置后台数据服务到数据库，或者到 Redis 缓存是通过（内部）网络的。这个虽然很快，但是它还是有网络时延的，这是第一个缺点。第二个缺点，如果哪天 Redis 抖动，我们提供的服务也会出现同样的抖动现象。因为我们提供的是一个很基础的服务，所以说这种现象我们是不能接受的，那我们怎么去优化？

针对第一阶段架构的问题，我们的架构演进到第二版。如下图所示，和第一版的唯一区别就是我们在配置后台数据服务里面加了本地缓存。看这个架构图，我们首先解决了配置后台数据服务到数据库这层之间的网络时延。因为配置后台数据服务它不再通过数据库拿数据，它是通过本地缓存拿数据。本地缓存数据的更新是通过一个异步线程完成。这样一种架构是不是完美的？我们解决了配置后台数据服务到数据库之间的时延。但是业务接入层与配置后台数据服务之间，这个网络时延还是存在。

还有一个很重要的点，业务接入层都往配置后台请求数据。这时，配置后台数据服务就成了一个中心节点，这样它的风险就很大了。另外，每台机器内存是有大小限制的，这也是一个瓶颈点。怎么解决这些问题呢？

针对第二阶段的三个问题：网络时延、中心节点、有限缓存，我们演进到第三种方案，如下图所示：

这是一个 SDK 的解决方案。之前我们的缓存是放在配置后台数据服务中。SDK 方案里我们把这个缓存移到业务接入层，并提供接入的 SDK。数据都是存储在业务接入层，这样有一个非常大的好处，所有的请求不会打到配置后台数据服务，而是请求到业务层获取到数据后就返回了。请求的链路变成：C 端用户请求过来到业务接入层，业务接入层直接取自己本地缓存的配置数据，返回给 C 端用户。这样的话解决了一个中心化的问题。

同样的，存储问题也解决了。之前我们数据都是存储在配置后台数据服务里，即存储在我们自己服务器缓存里。全公司所有的数据缓存在中心服务机器里迟早有一天内存会打满。如果数据存在 SDK 里面，它是在业务接入层，它把数据存储的压力分散化了，为什么这样说？举一个例子：亲子的服务不会用到外卖的数据，这样在亲子的服务器上就不需要缓存外卖的数据。这样就解决了数据存储层中心化的问题，下面的对比图可以形象说明这一点。

5 总结

本文通过美团点评移动运营平台的实践，介绍了我们在打造稳定、灵活、高效的运营配置平台过程中积累的一些方法论：通过数据 JSON 化，运营流程化，接口 SDK 化分别解决了运营平台的灵活性、高效性和稳定性。运营平台帮助产品、运营和研发提升 C 端的开发和运营效率，加速产品的迭代过程。