越复杂的需求，就要做越简单的设计

即使后台数据服务挂了，C端还是能拿到数据的。

美团点评高级架构师 蒋国宝 如是说。

《打造稳定、灵活、高效的运营配置平台》的学习笔记。

为每一个应用场景开发一个页面，效率是非常差的，设计一套可灵活组合的动态化运营后台，才能更好地满足多变的业务需求。

运营平台是什么？

• 打断是扼杀搞效率工作的一大原因

  • 让产品自己发布

• 高效

  • 难点：多样展示、跨团队
  • 方案
    • 模块化拆分，达到可配置
    • 不同模块进行组合，称为商户样式
      • 商户样式什么决定？
        • 版本
        • 商户类型
        • 城市
  • 模块化配置运营
    • 可复用的模块列表（模块池）
    • 运营通过后台可以配置模块组合

• 灵活

  • 为每一个应用场景开发一个页面？
    • 缺点：需求易变，开发效率低，维护成本高
  • 构建多个维度下的动态运营界面
    • 优点：界面动态声场，无需开发，界面灵活可定制
  • 方案：Json存储页面配置

• 稳定

  • 配置内置到app内部一套，保证没有拉取到最新配置

  • 配置完成流程

    • 审核 + 测试预览 = 上线的可靠性

  • 数据域划分 & 审核上线

  • 测试设备注册，保证上线前预览效果

  • 第一个版本

    • C端 -> 业务接入层 -> 配置后台数据服务 -> Redis缓存/数据库

  • 演进1

    • C端 -> 业务接入层 -> 配置后台数据服务/本地缓存 -> Redis缓存/数据库
    • 优点：解决Redis抖动造成的问题
    • 缺点：单击内存大小限制，中心化带来堵塞问题

  • 演进2

    • C端 -> 业务接入层/数据缓存SDK，做部分数据缓存 -> 配置后台数据服务 -> -> Redis缓存/数据库
    • 优点：各业务缓存各自的数据，去中心化
    • 缺点：数据一致性如何保证？数据时效性如何实现？SDK本地缓存如何监控？

  • 演进3

    • 将SDK植入C端，正在开发