从 0 到 1, 构建达达快送自动化业务配置中心
1. 背景
2. 案例
3. 痛点和目标
3.1 痛点
3.2 目标
3.3 业界方案调研
4. 解决方案：达达快送自动化业务配置中心
4.1 架构
4.2 使用方式
5. 成果
6. 未来规划
作者简介
加入我们
1. 背景
在达达，有大量的业务性质的配置（后文简称“业务配置”）被存放在研发配置中心，占到了配置中心所有配置的 20%左右，占比不高，但却给系统运维带来了巨大的成本。本文将介绍如何从0到1，构建达达快送自动化业务配置中心。
首先，为什么会出现业务配置添加到研发配置中心中的情况？在设计时，我们一般会从三点进行考虑。
投入产出比，在产品设计阶段，为一个不常用的功能，或是只是短期存在的业务去研发一个配置管理页面，其投入产出比相对较低。
研发资源不足，需求较大时，受到了研发资源的限制，将需求进行拆分为多期，先保证核心流程，二期或后续再完成配置页面相关的研发工作。
需求的紧急程度，业务需求倒排，本次需求要完成上线。评估后，要达成该上线目标，只能做出妥协，将业务配置临时添加到研发配置中心，后续再完成配置页面相关的研发工作。
达达从成立至今，已经7年。7年间，不断有业务配置被以研发配置的形式添加到研发配置中心。7年间，公司业务不断的增长，系统复杂度也不断上升，目前，公司在业务配置的维护上投入的资源巨大，已成为公司的一大痛点。
2. 案例
在达达的物流配送业务中，需要对其配送平台下的众包骑士进行管控，保证配送服务的质量，而对骑士进行“服务质量强化”培训则是其中的一大抓手。
骑士服务质量的好坏，通常会以这个骑士被投诉而产生工单的数量进行衡量。骑士没有工单，说明骑士的服务质量好，无需参加培训；一旦产生工单，就会认为该骑士的服务质量需要提升，就需要参加培训。
不妨先来看这样一个案例：普通骑士张三，在北京跑单，有一天，张三被投诉不送货上门。按照规则，张三需要在接下来的工作中完成课程。不同的地域（城市、站点），不同类型的骑士，其服务的对象存在存在差异，被投诉的原因也不一样，需要培训的内容一不一样。因此在制定骑士参加培训的规则时，通常会从多个维度考虑。
如图 2-1 所示，从城市（站点）、骑士类型、投诉原因这些角度，共同决定了该骑士需要参加的课程是什么。
图 2-1 骑士培训配置
产品需求移交之后，进行方案评估，从投入产出比、研发资源、需求的紧急程度等角度考虑，在当时的业务场景下，提升骑士的服务质量刻不容缓，急需这款产品的上线。
为了达成尽快上线，需求进行了倒排，将配置添加到了研发配置中心中是当时不错的一个选择。于是有同学设计了如图 2-2 所示的配置，为了方便理解，我将一系列id都替换成了中文描述。
图 2-2 骑士培训配置JSON
以上只是众多业务配置和研发配置混在一起的一个场景，虽然解决了当时的问题，但是也给以后产品的维护带来了巨大的成本和麻烦。
3. 痛点与目标
3.1 痛点
将业务配置配置到研发配置中，这为产品研发和迭代带来了不少便利，解决了“燃眉之急”，而带来的“后遗症”也不少。
1. 影响系统稳定
业务配置没有和研发配置隔离，业务配置的修改需要发布上线，影响系统稳定性。
2. 鲁棒性差
业务配置的多被设计成JSON格式，甚至还带有竖线、逗号，下划线等分隔符，对配置的数据没有校验，无法通过前端的业务组件，让用户以可视化的方式进行配置，鲁棒性差。
3. 效率低
整个配置的修改上线流程长，导致修改一个配置需要的时间长，效率比较低。整个流程和参与的角色如图 3-1 所示。
图 3-1 配置流程与参与角色
4. 数据安全性低
凡是有研发配置权限的用户都可以查看该系统下的业务配置信息，如果涉及到一些重要的配置信息，数据的安全性得不到保障。
5 数据分析取数困难
受限于基础设施，分析师无法直接取到研发配置中心中的数据，导致数据分析取数困难。
3.2 目标
以上痛点，促使我们开始了对业务配置的治理。寻求合适达达的方案，解决以上痛点，最终梳理并需要达成下目标：
1. 提升稳定性
将业务配置和研发配置进行隔离，业务配置的修改不需要走上线流程，减少上线次数，提升系统稳定性。
2. 良好的鲁棒性
提供可视化配置的能力，集成业务组件，保证用户填写数据的正确性。
3. 提升效率
产品运营可以自助修改配置，提升上线效率。
新增配置，以低代码，0代码的方式生成配置页面，快速响应紧急需求。
研发读取配置，提供接口或API，使用方便，提升研发效率。
4. 提升数据安全性
新方案需要有权限控制能力，只有有权限的人才能看到相关的配置，保证配置数据的安全。
5. 高可用
通过去中心化的方式读取配置，不会存在单点问题，一旦配置系统发生故障，接入方也不会受到影响。
6. 实时性
配置一旦发生修改，接入方能及时的收到通知，并更新本地配置数据，完成配置变更。
7. 分析师取数方便
提供通用的解决方案，能让分析师获取到业务配置的数据
3.3 业界方案调研
实现以上的这些目标，即解决业务配置和研发配置混合带来的的痛。我们对业界的方案进行了调研，具体情况如下：
DMS，基于Json Schema的动态Json数据配置平台，现在重构中
逆向工程，能在线生成从数据库表到前端页面，具体业务逻辑只需稍加修改即可。
有的公司自己设计一个框架，核心思想是将配置序列化为JSON，然后使用一个大表来存储。
下面对比下这三个方案，如表 3-1 所示。
表 3-1 方案对比
通过对比，我们可以直观的发现，不管是支持高可用的DMS，还是逆向工程，还是简单的使用大表存储的方案，都不能达到我们的目标。因此我们决定自研解决我们的痛点。
4. 解决方案：达达快送自动化业务配置中心
在通过调研之后，决定自研达达自己的业务配置中心，来来解决我们遇到的所有痛点。下面将介绍达达快送自动化业务配置中心的架构和使用方式。
4.1 架构
图 3-1 达达快送自动化业务配置中心架构图
从架构图 3-1 中，左侧为达达快送自动化业务配置中心的portal，业务侧可通过portal进行配置管理，主要包括配置的新增、修改，集成了日志、权限、列类型管理、配置管理、业务组件、BI数据同步这6大模块。右侧为程序读取的配置，只要项目集成dada-biz-config这个jar包，即可通过BizConfigClient提供的API方法获取用户配置的数据。
看了上面的架构，相信会有人问，为何使用Apollo存储业务配置？主要从以下几点考虑。
运维成熟
稳定可靠，经历多次大促
配置去中心化，支持跨云同步
提供开放平台API
以上架构如何达成目标的呢？
稳定性：
将研发配置和业务配置隔离，保存业务配置的 Apollo 为单独的 project 和 namespace，提升了系统稳定性。
将业务配置访问Apollo的流量和研发配置访问Apollo的流量隔离，请求打到Apollo集群的两个不同的节点，即使业务配置的流量陡增，也不会对研发配置的Apollo服务产生影响，保证系统的稳定性。
鲁棒性：通过列类型管理模块、配置管理模块、业务组件模块，使得从配置的创建到配置的使用，全程可视化，通过业务组件模块，可以快速集成前端业务组件，提供友好的交互，保证用户配置数据的正确。
效率高：
按照开发一个配置的页面的工时进行计算，从产品编写PRD、UED设计、前端页面研发、后端接口研发、测试，总的工时在 3人/日 以上，通过达达快送自动化业务配置中心创建一个配置，只需要几分钟到数十分钟，极大的提升了研发效率。
产品运营自助上线配置，不在需要其他角色的参与，随改随生效，极大的提升了响应业务修改配置的效率。
安全性：通过权限控制模块，可以将配置控制到哪些用户可见、可修改，达成精细化控制，严格保证数据的安全。
高可用：自研了达达快送自动化业务配置中心的 client，底层依赖 Apollo Client，去中心化，不存在单点问题。
实时性：利用 Apollo client 的配置通知机制，使得配置能在秒级别内实现本地配置的更新。
分析师取数：通过BI数据同步模块，将配置数据以大JSON的形式落入mysql中，数仓侧解析数据后，转化成中间表供分析师使用，解决取数困难的问题。
4.2 使用方式
通过达达快送自动化业务配置中心，快速创建相应的配置管理页面，并通过BizConfigClient读取配置数据，其主要流程如图 4-1 所示。
图 4-1 创建配置流程
是的，你没有看错，只要三步就能创建一个配置，全程可视化，0代码，下面我们将以以骑士培训的案例为例，为其创建一个配置。
1. 新建配置
在配置管理页面页面，可以看到创建好的配置，点击，新增按钮即可新增配置，如图 4-2 所示。
图 4-2 配置列表
点击新增按钮之后，将出现图 4-3 的弹窗，填写配置的描述信息后保存，即完成了我们的第一步【新建配置】。
图 4-3 新建配置
2. 配置列项
在新建好配置之后，点击右侧操作列中的【配置列项】，即跳转至如图 4-4 的页面，可以为配置定义有哪些列。如果将配置想象成一个“表格”的话，那这一步的操作就是为这个表格创建表头。对于骑士培训的案例，需要配置城市、站点、骑士类型、工单类型、接单天数、培训课程6列。
图 4-4 配置列项
定义完“表格”的表头，第二步就完成了，如果你好奇为何在这里可以选择城市、站点、骑士类型、工单类型等，可详见4.2.4 业务组件 和 4.2.5 配置列项。
3. 配置详情
配置列项完成之后，回到配置列表页，点击右侧操作列中的【配置详情】。可看到如图 4-5 所示的页面，我么想要的配置页面就这样出现了，用户可以通过点击左上角的新增按钮或新增默认值按钮，配置具体的业务数据。
图 4-5 配置详情
点击此处的新增按钮，即可为我们的配置添加具体的配置。如图 4-6 所示，每一列的配置都有对应的前端组件进行渲染，保证数据输入的正确性。
图 4-6 新增配置行
到此为止，我们的一个配置就配置完成了，最终配置完成的数据如图 4-7 所示。
图 4-7 配置详情
在该页面，我们可以再次编辑或者删除配置数据，也可以看看日志，如图 4-8 所示。
图 4-8 操作日志
4. 权限管理
针对上述已经创建好的配置，我们可以对其权限进行管控。在配置列表点击【权限控制】可对该配置进行权限控制。一般创建人即为该配置的owner（管理员可以修改），owner和管理员可以为该配置添加有权限操作该配置的用户，如图 4-9 所示。
图 4-9 权限控制
5. 业务组件
为了交互的友好和系统的鲁棒性考虑，我们对系统的每一列的数据类型进行了区分，可以分为3类
自定义：包含boolean、string、number、decimal、date等基础类型
预定义枚举：如果当前列的数据是可枚举的，那用户可以先定义一个枚举，然后在配置列项时类型选择该枚举即可，最终用户在配置页面将看到的是一个下拉组件，详情请见
业务组件：针对现有业务已经在db中维护的数据，我们可以通过业务组件的方式接入系统，避免了多方维护基础数据。一般这种场景数据量较多，不适合做成枚举。
如案例中所使用的城市、站点这两个维度，是非常常用的维度，并且站点数据、城市数据相对较多，如果使用列类型枚举，则下拉框的交互方式就显得不是很友好，对于站点来说，下拉的方式的交互已经无法满足业务的需求了。
达达快送自动化业务配置中心的业务组件模块就是解决这一问题的，如图 4-10 所示，为我们选择站点的业务组件，和用户的交互方式得到了提升。
图 4-10 站点组件
6. 列类型配置
骑士培训这个配置中，还涉及到的骑士类型、工单类型两个维度，这两个维度的可选择的数据相对较少，达达快送自动化业务配置中心提供了定义列类型的能力，可以将需要配置的数据构造成一个枚举。如图 4-11，为列类型管理页面，点击新增按钮即可新增列类型，列表中的工单类型和骑士类型为已经新增好的数据。
图 4-11 列类型配置列表
图 4-12，图4-13 分别为点击新增按钮之后的页面，新增骑士类型和工单类型两大枚举。
图 4-12 配置列项-骑士类型
图 4-13 配置列项-工单类型
6. 默认配置
经过调研，我们发现很多业务都需要有一条默认的配置进行兜底。于是我们增加了默认配置的入口，允许用户配置兜底的配置，如图 4-14 所示，点击左上角第二个按钮可添加默认配置，配置方式和添加普通配置无异。
图 4-14 默认配置
7. 组合判重
我们再来看这个配置列项页面，其中有个选项为是否组合判重，图 4-15 中红框标注。我们经过调研发现，很多业务场景的配置，众多维度进行组合之后是唯一的。例如骑士培训这个案例中，上海的普通骑士，被投诉“不送货上门”时，应该只对应一条配置（需要参加哪个培训），即城市、骑士类型、工单类型应该组成唯一键。针对这样的场景，我们研发了组合判重功能，允许某些列组成唯一键，保证在这种场景下，系统在读取配置时，只会读取到一条配置。
图 4-15 配置列项-组合判重
8. 客户端读取配置API
为了方便接入，我们提供了友好的api供研发读取配置，如图 4-16 所示。
图 4-16 客户端读取配置API
经过调研，当前客户端提供了三种获取配置的方式，覆盖了获取配置的绝大多数场景。
getBizConfigsByKey，全量获取配置，即获取用户配置的所有数据
getBizConfigsByColumns，有条件的获取配置，入参conditionSet表示可以针对列进行过滤的条件，拿骑士培训的案例来说，假设我们要取上海的所有配置，则可以构造一个BizConfigCondition对象，指定需要城市这一列，指定需要匹配的值"上海"，在调用方法之后，只会返回上海的配置，如果匹配不到配置，则返回默认兜底配置。
getBizConfigByUniqueIndex，根据唯一性条件获取配置，和getBizConfigsByColumns类似，但是传入的conditionSet必须是在配置列项时指定的参与了组合判重的列，否则如果不保证唯一性，获取到的配置将不符合预期。
5. 成果
达达快送自动化业务配置中心自上线后，截止至9月底，为系统稳定性的提升和开发效率的提升，都做出了很大的贡献。
自上线以来总共接入配置296个。近2月新增配置80个，修改次数600+，预估节省200+人日。达达快送自动化业务配置中心诞生，为业务配置的实现提供了一种新的思路，尤其是需要快速迭代、时间紧急的项目，能节省研发时间，快速上线。
达达快送自动化业务配置中心经历了2021年618的洗礼，没有出现任何故障，稳定、效率、安全。
通过去中心化的方式，提升了系统的性能，且上限极高。
图5-1为某一应用通过客户端获取配置的请求量，图中【今日请求量-请求方式：all】表示通过客户端getBizConfigsByKey方法获取配置，请求量qpm在7k上下，没有出现任何的系统瓶颈，远远没有达到请求量的上限。
图5-1某一应用业务配置客户端请求量
图5-2为某一应用通过客户端获取配置的响应时间，纵轴单位为毫秒，图中【今日请求量-请求方式：all】表示通过客户端getBizConfigsByKey方法获取配置，平均响应时间大概在0.1ms上下，性能强劲。
图5-2某一应用业务配置客户端响应时间
6. 未来规划
突破Apollo单个key配置数据的长度限制，目前的架构中，一个业务配置对应Apollo中的一个key，这就要求我们配置的数据的整体长度不能超过Apollo单个key配置的最大长度。后期计划突破这一掣肘，使得单个配置可以保存更多数据。
跨环境配置同步，支持将配置从dev环境同步到qa或线上，减少常见配置时的重复工作，提升效率。
集成更多更丰富的业务组件，提供更多的配置维度，以支持更多的业务场景。
作者简介
周华剑，达达集团JAVA开发工程师，2018年加入达达，目前负责达达落地配业务的研发工作、达达快送自动化业务配置中心的负责人。致力于提升软件系统稳定性，寻找能提升研发效率的通用方案，为业务快速赋能。
加入我们
达达集团目前还处于高速成长期, 欢迎对技术有追求的同学加入, 可查看链接 https://app.mokahr.com/su/zlrxpe 投递简历。