1. 序
当前的中文互联网商业模式千变万化，业务模式纷繁多样，但反映到其背后的计算机技术实现，大体可以划分为两部分——运行时、运营时。
运行时，即对于业务领域内各种业务功能的技术实现，可以简单理解为——数字化业务活动的执行方；而运营时，即业务领域运营人员对业务功能进行灵活组装选用和控制，从而能让业务功能够适配于繁复多样的业务场景，发挥其对应的效用，满足人们的衣食住行的各方面需求，可以简单理解为——数字化业务活动的控制方。运行和运营的关系可以总结为：运行决定运营，运营控制运行。
在国际支付数字化业务领域内，业务运营主要聚焦于数字支付能力的管理、控制和对外开放，大体上主要涉及到四方角色——商户、用户、IPAY支付机构、下游支付渠道，四方交互的链路错综复杂，需进行控制的运营节点数不胜数，如何做好支付运营，使得支付运行时功能得到100%的释放和利用，是每一个互联网业务运营侧研发的技术使命。
个人过去一年致力于建设国际支付领域运营核心基建，对于参数的运营模式和运营能力的演进与发展方向有了更深入理解和认知，在此作为过去一年的工作总结，记录和分享至此。
2. 参数运营模式
2.1. 参数特性梳理分类
从支付业务领域出发来看，参数大致可以分为两类：
- 系统级参数， 系统级别参数和业务系统自身的代码结构息息相关，主要是对系统代码结构中关键节点信息进行抽象和提取，通过参数化的形式进行合理管控和推送，从而对系统底层的代码能力进行控制、复用或者切换，例如系统的机房配置信息、系统的元数据等。此类参数多数情况下用于系统层面的运维操作。
- 业务级参数， 业务级别参数脱离单个业务系统而存在，和展业业务强相关，其主要对业务活动中的关键信息进行管控和投放，覆盖和业务活动相关的所有系统而不是仅仅被某个系统所消费。业务参数通常会对其赋予一层业务概念，从而达到增强其可解释性、通俗性的目的，例如合约、支付方式，但其本质还是由一组参数组合而成，通过对系统上层的服务能力进行控制和复用从而执行不同的业务活动。
对于参数配置的管理和运作称之为参数运营。参数运营按照组成结构来看大概可以分成三大部分组成：
- 参数运营服务端，主要负责参数的变更投放等核心能力的构建
- 参数运营客户端，由业务系统进行集成，对参数配置数据进行消费查询
- 参数运营管控端，提供平台能力供运营人员操作，提供参数的可视化管理能力
对于系统级参数和业务级参数而言，不同类型的参数根据其特性的不同会衍生出不同的参数运营模式，下面就从参数的变更投放、参数的可视化管理、参数的系统消费三个部分，对应到参数运营体系中的服务端、管控端、客户端分别介绍参数的运营模式在两种参数类型中的应用与差别。
2.2. 参数变更投放
2.2.1. 灰度IP维度生效
对于系统级参数而言，由于其和系统代码的强关联性，注定了其主要面向系统研发/运维人员进行管理，同时由于其“业务无关”的特性，同时变更往往由于其和系统底层运作原理相关联，影响面往往难以准确评估，具有较大的不稳定性和不可预知性，参数变更的过程更加需要小心谨慎，要求采取最为严格、风险可控性最高的变更模式，即机器IP维度的灰度推送投放方式，进行极细粒度的参数变更生效：分批次将配置顺序推送至目标机器，逐步生效配置数据。
2.2.2. 即时生效
对于业务级参数而言，其和具体业务有着较强的关联性，往往特指某个业务概念（合约、支付方式等），其主要由业务运营小二或者直接由外部的商户、用户进行维护和管理。业务参数的变更往往不会涉及到对系统的底层运作作出改变，而是对系统的服务能力进行选择和控制，其影响范围通常会被业务服务对象所框定，所以其变更具有较强的稳定性和可控性。根据参数特性衍生出来的变更推送要求有以下两点：
- 运营效率要求，由于此类业务参数的变更操作为产品/运营、外部商户等角色在业务门户进行变更操作，对于参数的变更往往有着效率的要求，同时变更角色没有技术知识基础，因此要求运营流程做到简单、高效。
- 运营履约要求，由于业务参数的变动往往受业务契约条款的履约限制，需要根据条约的生效条件严格生效，不允许出现模凌两可的“灰度逐步生效过程”，从而尽可能避免造成同一时间出现的多种业务执行结果情况。
结合以上两点要求，无论从运营流程合理性还是业务限制层面出发，机器IP维度进行灰度推送由于其推送流程复杂、推送效率低、推送期间的数据不一致敞口大的特点决定了其不适于作为业务参数的推送方式，针对于此类业务型参数，最佳的参数变更方式为即时生效推送变更：即对于所有的目标机器进行配置参数的快速生效，从而能够提供运营效率，缩短业务参数生效的不一致敞口，降低违约风险。
2.2.3. 流量实验
既然业务级参数不适合机器IP维度的灰度生效方式，以即时生效的方式取而代之，那如何实现业务级参数的测试验证诉求，从而避免变更过程中存在的各种风险呢？
这种情况下往往选择除机器IP灰度外的其他验证策略——流量实验，即隔离生产环境的正式流量，通过流量模拟或者灰度规则引流的方式在风险系数可控的环境条件下对参数进行实验性质的测试验证，一旦参数完成了流量实验，即可在生产环境进行开量处理，全范围生效。
简单解释一下流量模拟和灰度规则引流的基本原理：
- 流量模拟，即将参数置于仿真环境，通过流量录制的方式将生产流量进行复制并回放至仿真环境，以此验证参数在模拟流量下是否能达到预期效果。
- 灰度规则引流，即将参数置于生产环境，但通过灰度规则（一般为白名单或布尔式）的方式控制参数对于生产流量的可见性，即仅对命中灰度规则的流量生效该参数，以此对参数进行灰度验证。
2.3. 参数可视化管理
参数的可视化管理即在参数的管控平台上对参数的配置元信息、参数数据信息进行可视、可管、可控。这本来是一个非常简单增删查改的问题，但是当我们把参数的数量级作为一个变量考虑在内之后，就有不小的技术空间可以进行挖掘。
2.3.1. 配置虚拟表
对于系统级参数而言，此类参数的数量级往往是可控的。单个配置项的数据量往往不会超过百级，一般而言十级即为常态。此类型参数的管理往往使用最简单的KV模型即可，配置模型结构稍微复杂一点的使用主流配置管控平台中常见的虚拟表结构也能解决问题。对于此类参数的查询可视诉求，在配置项维度从存储源中全量查询其对应数据，在管控平台上分页展示即可。
这里简单介绍一下何为配置虚拟表，配置虚拟表是配置平台对于配置模型结构进行定义和管理的一种常见主流方案，即针对于配置模型结构纷繁复杂的业务场景下，使用schema化的配置结构定义对不同配置模型的字段结构进行应用层的强管控，并在此基础上定义配置模型的查询索引，实现应用层面的索引化查询。此种方案的关键在于对于配置结构的schema管控都是在应用层进行的，其在存储层依然采取统一的存储方式：
- 配置项的schema在底层配置项元信息表中统一存放。
- 配置项的具体数据以序列化的方式“压缩抹平”，统一存储至底层配置数据表
根据存储层统一存储的虚拟表存储特性，其基于索引的查询能力也是只能通过应用层的计算检索完成，其检索的数据来源为存储层的全量配置数据。
2.3.2. 海量数据检索支持
对于业务级参数而言，此类参数的数量级是不可控的，参数的数量会随着业务展业范围的扩大，涉及到的业务对象的数量增多而不断增长，例如商户、用户层面的参数和支付渠道层面的参数。单个配置项的配置数据往往能达到万级甚至百万级的程度。而由于业务级参数往往和业务场景息息相关，往往会衍生出较为灵活的参数可视诉求，例如“聚合查询某商户ID的所有参数数据”，或是“聚合查询某支付渠道的所有参数数据”。
在查询的数据量庞大的情况下，不可避免的需要在存储源层面对数据进行索引过滤、聚合查询等一系列存储引擎层计算动作。但无论是KV模型还是传统的配置虚拟表模型而言，都无法支持此类较为灵活且庞大的查询场景：
- 对于KV模型而言，KV模型在存储层采用非模型化设计，仅支持简单的数据类型，无法支持配置数据索引的构建。
- 对于配置虚拟表模型而言，虽然基于虚拟表的配置模型化设计，在虚拟表索引定义合理的基础上能够支持较为灵活的配置查询业务诉求，但其底层对应的依然是是关系型数据库的单表结构，配置虚拟表数据的结构差异性会通过JSON格式序列化的方式进行“压缩抹平”，从而存储于底层关系型数据库的实体单表，虚拟表索引能力的实现是基于全量加载，内存计算完成的，显然这种方式无法对海量数据的灵活检索进行支持。
此时问题的核心就来到了如何解决配置虚拟表的索引结构在存储层丢失，导致无法高效检索的问题。有三种较为可行的解决方案：
- 方案一：虚拟表转实体表，即将配置项的虚拟表结构转换为底层存储层的实体关系表，即可将虚拟表的查询索引结构下沉至存储层，从而解决管控端的检索效率低下的问题。
- 方案二：读写异构，管控端读模型接入搜索存储引擎，例如ElasticSearch等，实现灵活高效参数检索能力。
- 方案三：虚拟表转文档，以schemaless的文档结构将虚拟表索引结构轻量化下沉至存储层并保留高效的检索能力。
三种方案各有利弊，具体利弊分析如下：
- 方案一，虚拟表转实体表的方式过于繁琐沉重，参数中心当前维护了成百上千个配置项虚拟表结构，如果全部通过转实体表的方式存储于关系型数据库，对参数中心这种基础平台的核心代码的通用性、用户对于配置项结构维护的高效便捷性都会造成极大的冲击。
- 方案二，以读写异构的方式将管控端的检索接入搜索引擎，即一个配置项维护两套数据，两份数据的一致性维护是不小的挑战，一旦一致性出现问题，极大可能影响到管控端用户操作参数数据的正确性，同时搜索存储引擎无法支持事务和高可用性，加大了双边数据不一致的风险。
- 方案三，虚拟表转换成轻量化且Schemaless的文档型存储结构，此种方案看似可行性最高，在通用性、用户体验、数据性一致性保障层面均优于方案一和方案二。但目前开源的主流文档型数据库mongodb在吞吐量和稳定性上面均不如OB、MySql等SQL数据库，会对运行时的吞吐、运营时的稳定带来不小的考验。
综合分析下来，方案三——虚拟表转文档的参数存储方式其实是可行性最高的一种，针对于mongodb的吞吐量和稳定性欠佳的问题有很多非功能性设计可以去治理和防范，例如多级缓存，请求合并等技术手段，这里不在详细展开。
2.4. 参数消费方式
2.4.1. 持久化近端缓存消费
参数的消费方式决定了参数在运行时系统中以何种非持久化缓存介质进行承载，何种查询方式供业务系统查询实际的参数数据。在参数消费方式的决策上，也会受参数的类型、变更方式、持久化存储介质的影响，演进出不同的参数消费和加载手段。
针对于系统级参数，由于其数量级可控，单条数据的查询可复用性高，基本具备近端缓存消费的条件，因此适合查询性能最佳的近端缓存查询模式。由配置变更通知点对点推送、业务系统启动时的全量加载保证近端缓存中的参数配置数据的完整性和正确性，以此支撑后续系统运行状态下完全依赖于本地近端缓存对参数配置进行消费。
2.4.2. 多级缓存消费
而对于业务级参数而言，其数据量级存在一定的不可控性，且单条配置数据仅作用于单商户或者单个支付渠道，在全量业务流量的角度上看，单条配置数据的可复用性不高，若使用近端缓存消费的方式存在对业务系统造成一定的JVM空间浪费和空间过度占用导致FGC的风险。因此针对此类业务级参数数据，使用多级缓存的方式（基于LRU的近端缓存 + 分布式缓存），虽然牺牲了一定的查询性能，但在合理性和适用性上更优。
3. 一体化参数运营
3.1. 一体化运营理念
以上分析其实是对参数运营的广义理解，但只有站在广义维度认知事物，才能还原事物的本质并发现其共性，从而发挥杠杆效应，从底层撬动问题，实现针对于问题的颠覆性突破。
虽然系统参数和业务参数在参数运营各个方面的运营策略上存在较大的差异性，但如果对参数的类型根据其作用范围进行细化梳理分类，并对其运营模式进行差异整合。即可得到两种参数运营模式：
- 业务参数运营模式，针对于主体、产品、商户参数的参数运营模式，以面向产品/运营人员为主，提供业务参数的投放、可视、消费策略，以基于文档型数据库的海量数据存储、即时变更能力、多级缓存作为技术支撑。
- 系统参数运营模式，针对机房、应用参数的参数运营模式，以面向技术研发人员为主，提供系统参数的变更、可视、消费策略，以IP灰度变更能力、本地缓存能力作为其技术支撑。
如果对业务参数运营模式、系统参数运营模式进行进一步的整合，即参数中心内化两种参数模式并对其差异性进行封装，从而能够让用户在参数中心平台上自由的一键化选择参数配置模型的运营模式，即可极大的提升参数运营的效率，同时避免烟囱化的对参数运营能力进行定制化的自建，导致业务技术域内在参数管理领域下的一个个信息孤岛。
3.2. 运营产品化
什么是产品？即基于统一的规范和质量标准，能够实现大批量、规模化的对市场需求进行高效率生产和交付的产物。标准化、规模化、高效化是产品的三个基本特征。如果能够对业务的运营流程进行产品化沉淀，就能在展业的各个运营环节充分发挥杠杆效应，充分释放运营产品化所带来的高效能，最大化运营流程的稳定性和效率。
实现运营产品化的必要条件是一体化运营，一体化运营能够在产品的三方面都提供强有力的支撑：
- 标准化，一体化参数运营整合的了两套标准化的参数运营模式，以此支撑运营流程的标准规范
- 规模化， 基于文档型存储模型的参数存储方式在容量和灵活性上都为运营的规模化提供了存储能力支持
- 高效化， 一体化参数运营对于运营模式的差异封装，在此基础上提供高效的可视运营操作平台，为产品的交付高效提供了保证
在实现一体化运营的基础上，如果能在业务运营场景和领域维度对参数进行梳理和同类聚合，实现业务运营的场景化、领域化，即可使用一体化参数运营的技术红利在不同的业务场景、领域构建出具体的运营产品实例，释放产品的标准、规模、高效优势。
4. 后记
运营是互联网各种形态的业务模式都不可或缺的一环，运营作为业务的控制端，往往对展业效率和展业稳定性都起着至关重要的作用。如果说在一个大的业务领域内，运营层面缺少底层统一基建的一体化运营支撑，各细分领域以五花八门的方式自建运营平台，缺少统一的运营模式规范，在前期的投入成本和后期的维护成本上都会面临一定的风险和挑战，而且会造成运营项的散落于各处的现象，在机房建站、横向业务项目建设等需要整体性运营的场景会极大的增高运营投放的梳理成本。
一体化运营的建设希望能整合一个大的领域内的各子域运营项，形成合力。在减少上层运营平台建设和维护的基础的同时，能够规避运营项散落的问题，真正实现运营的标准化、规模化、高效化。正如阿基米德所说：给我一个支点，我能撬动整个地球。
一点关于运营的思考，分享给各位，以上。
