欧美风格网站特点,wordpress 阿里云 漏洞,网站开发 瀑布结构,女生做sem还是seo前言 随着美团配送业务的飞速发展#xff0c;单量已经达到千万级别#xff0c;同时每天产生的资金额已经超过几千万#xff0c;清结算系统在保证线上服务稳定可靠的前提下#xff0c;如何系统化的保障资金安全是非常核心且重要的课题#xff0c;配送清结算系统经过近3年的… 前言 随着美团配送业务的飞速发展单量已经达到千万级别同时每天产生的资金额已经超过几千万清结算系统在保证线上服务稳定可靠的前提下如何系统化的保障资金安全是非常核心且重要的课题配送清结算系统经过近3年的建设和打磨在资金安全保障的多个方面均有一些总结和实践保障资金安全是值得系统思考的课题只言片语难以全面概括需要更多的着墨才能较完整阐述本文侧重点会阐述“对账”的概念在支付清结算领域这是一个非常重要的专业名词下文将介绍“对账”在分布式系统建设中的实践和解决方案力求在系统覆盖度、资金准确性、时效等多个维度为系统资金安全保驾护航实现更健壮可靠的资金履约。 背景问题 随着美团外卖配送事业的蓬勃发展配送清结算业务的复杂性也在不断的增高总结起来主要有以下几个特点 场景多包括专送、众包、快送、跑腿、外部单等多条业务线订单补贴、活动发放、奖惩、餐损、打赏、保险等多种结算场景对接外部十多个系统。链路长清结算内部经历定价、记账、汇总账单、付款等多个流程。单量大目前日单量已达到千万级别。在这样的业务背景下我们的系统可谓险象环生。因业务高度复杂稍有不慎就会出现问题面对千万级的日单量同时还要确保结算金额的准确这就让我们对问题的容忍度变得极低。这也给我们的资金安全保障造成了巨大的挑战。下面我们列举了一些系统日常运行过程中出现的问题。 可以看出这些都是一些上下游交互的边界场景以及遇到的问题。当然不仅限于这些场景凡是有系统交互、数据交互边界的场景都会出现此类问题我们称之为“一致性问题”。经粗略统计我们清结算系统建立以来有70%左右的问题都属于一致性问题。 导致一致性问题的原因有很多诸如 幂等、并发控制不当。基础环境故障比如网络、数据库、消息中间将发生故障。其他代码bug。目前配送的日结算金额已达到千万级别每个一致性问题都有可能给我们整个美团造成巨大的损失。因此如何解决系统的一致性问题成为我们保障资金安全的重中之重。关于一致性问题业内已经论述的非常成熟了搜索引擎中搜索“一致性问题”随处可见此概念的定义、问题阐述、意义以及解决思路诸如 强一致性协议: 两阶段提交、三阶段提交、TCC (Try-Confirm-Cancel)等最终一致性: 主动轮询、异步确保、可靠消息、消息事务等 这些手段的目标都是在事中避免问题的发生。但是在实际场景中无论是系统的内部逻辑还是外部环境都十分复杂多变、不可预知我们很难完全避免问题。因此事后对于问题数据的发现以及修复就显得尤为重要。这些也正是我们这篇文章要论述的“对账”的核心使命。我们力求总结对账领域内最专业的思路和方法并结合自身的业务特点建设配送清结算的对账体系构筑配送资金安全的坚固防线。在系统的整个构建过程中我们主要围绕以下几个目标 场景覆盖的完整性无死角覆盖清结算业务涉及的各个场景。问题发现的准确性能够准确的发现问题保证不漏报不误报。问题处理的实时性尽可能缩短问题处理的周期极力避免可能造成的损失。下面开始正式介绍美团配送清结算对账体系的构建经验。 对账的定义 对账的概念随着金融、互联网行业的发展定义上也经历了几个阶段的变化如下 stage 1 对账最初来源于会计核算是为保证账簿记录正确可靠对账簿中的相关数据进行检查和核对的工作。stage 2 随着互联网金融或电商行业的发展对账也扩大了应用范围这一时期对账是指在固定周期内支付使用方和支付提供方银行和第三方支付相互确认交易、资金的正确性保证双方的交易、资金一致正确。stage 3 从广义来看所有的跨端系统之间的数据核对都应该叫对账主要是检查和发现数据在流转过程中的不一致问题。通常分为信息流的核对和资金流的核对。信息流核对主要是对业务数据之间的核对资金流是对资金交易数据进行核对。对账系统的构建思路 系统概况 配送结算做为核心交易履约系统上游对接了订单、奖惩、活动等十多个外部系统下游又承担了对接支付平台、财务系统的职责不仅“承上启下”而且涉及业务复杂。而系统内部又历经定价、计费清算、记账、汇总账单、付款等多个环节系统的高度复杂性给对账的全面性和准确性造成了极大的困难如图 为了系统更加专业化的实现对账、做好对账我们对支付、清结算等资金领域进行了体系化的调研和学习并结合业务的自身的特点总结了一套对账系统构建的思路方法并基于该思路进行了较完整的系统化实现。 设计思路 从整体来看按照时序维度的先后系统对账主要分为三阶段的工作。分别是数据准备、数据核对和差错处理。在对账专业概念中数据核对和差错处理又叫轧账和平账。三个环节紧密相连从前期准备、问题发现、问题处理三个角度展开对账工作。 数据准备 数据准备顾名思义我们需要把对账所需的全部数据接入到我们的对账系统。该模块主要实现两个目标 为不同的外部系统提供多元化的接入机制。通过数据适配的手段把外部数据以统一的格式进行转换和存储。在数据接入层我们会针对不同的数据接入方提供三种不同的数据接入模式。 数据拉取我们主动拉取数据并通过数据适配的方式将数据存储到对账数据池中。数据推送由数据接入方将数据通过ETLExtract-Transform-Load等方式直接推送到我们的对账数据池中数据格式由数据接入方自行适配。文件上传我们会提供标准的文件模板由数据接入方填充数据通过文件上传的方式将数据接入到我们的数据池。其中第二种方式是我们最优选择的因为数据推送这种形式对于数据接入方来说只需要一次性编写相关的代码定期运行一劳永逸减少了人工上传的成本。对于我们结算来说也不需要感知对方的数据格式以及业务逻辑。 数据核对轧账 数据核对是对账中最核心的一个阶段。其目标是发现问题数据。数据核对阶段我们的两个目标是保障数据核对的覆盖度和准确性。经过总结和梳理数据核对过程可以分为以下5个环节。 1. 问题梳理 由于数据核对的目标是发现问题那么我们进行数据核对就要从问题出发首先明确我们要通过对账发现哪些问题只有这样才能保证数据核对的覆盖度。经过梳理我们发现在数据流转中过程中数据的不一致问题可以统一归结为三类分别是漏结、重复结、错结。我们可以从这三个角度去统一进行问题梳理。下面介绍一下这三种错误类型的具体含义。 漏结发起方有数据而接收方没有数据。举个例子目前清结算系统会在订单送达时给骑手结算。如果订单的状态是送达而没有给骑手生成对应的结算数据。就是一种典型的漏结算场景。重复结接收方重复处理。还是上面的例子如果订单送达给骑手结算了两次产生了重复的结算数据就是重复结算。错结发起方和接受方数据不一致。一般会发生在金额和状态两个字段。比如说订单上的数据是用户加小费3元。结算这边只产生了2元的小费结算数据就是错结。2. 对账方式 对账方式主要分为两种单向对账和双向对账。 单向对账以一方数据为基准进行对账。比如结算跟支付平台以结算数据为基准和支付平台核对用来发现结算数据为支付成功支付平台支付失败等问题。双向对账以双方的数据互为基准对账。既要保证结算数据为成功的支付平台也要成功又要保证支付平台数据为成功的结算数据也要成功。显而易见双向对账更能够全面的发现问题。因此在条件允许的情况下我们会优先选择双向对账。 3. 对账粒度 对账粒度也分为两种分别是明细对账和总数对账。 明细对账对双方的每条数据依次进行比对。它的优点是可以准确定位问题数据。缺点是对账口径的设计比较复杂。因为我们需要同时针对漏、重、错三种错误类别设计不同的对账口径同时还要考虑到业务的边缘场景。稍有不慎就会影响对账的准确性。总数对账选择一个维度进行总数级别的对账。总数级别的对账好处是对账口径的设计比较简单可以快速实现不易出错。缺点就是无法定位问题数据一旦对账发现问题。还需要进一步寻找问题数据。 因此推荐的做法应该是以明细对账为主定位具体问题。以总数对账为辅对明细对账的结果进行复核兜底。 4. 对账口径 对账口径也就是具体的对账逻辑的设计。我们会提供固定的对账模板供不同的对账场景选取。如果某些特殊场景对账模板不能覆盖也可以采取对账逻辑自定义的方式进行对账。 经过总结我们发现对账的形式无非就是两方比对和自身异常检测两种。两方比对又可以细分为一对一、多对一、一对多。比对方法也主要是分为条目匹配和金额匹配。自身异常检测主要是重复性和异常状态的检测。我们把这些通用的对账逻辑模板化减少重复的开发工作。 5. 对账时机 数据核对的最后一步就是对账时机的选择。分为离线对账和在线对账。离线对账主要是通过固定的周期进行对账。最短周期为。它的好处是适用性较强基本可以覆盖所有的对账场景。而在线对账又分为实时对账和准实时对账。实时对账和准实时对账的区别主要是实时对账耦合在结算链路中可以在发现问题数据时对结算流程进行拦截而准实时对账是异步进行的不具备拦截能力。在线对账有一定的局限性一方面它依赖于对账数据是否能实时的准备好另一方面也比较占用系统资源。因此我们的做法应该是以周期对账为主在某些实时性要求比较高且条件满足的场景使用在线对账。 差错处理平账 差错处理主要是对数据核对过程中发现的问题数据进行处理。我们会建立一个统一结构的差错记录将数据核对发现的问题进行统一存储。差错记录中的数据会进行二次核对避免由于日切等原因造成的问题错报。对于那些真实存在问题的数据我们会提供两种解决模式如果是常见的问题且有一套标准的解决方案的话我们会把它系统化采取系统自动修复的方式如果系统无法自动修复那么我们会进行系统报警并进行人工处理。 对账系统设计实现 总体架构 综上所述对账体系的整体架构分为三个模块分别是离线对账平台在线对账平台和平账中心。完全是按照我们上面的对账思路设计的。三个模块互相协作一体化的完成数据准备、数据核对、问题处理三部分工作。由于我们整个清结算系统是围绕不同的费用项建立的因此费用项也是我们设计对账、执行的对账一个最小粒度的单元。 具体介绍下三个模块。 离线对账模块 离线对账分为三个子模块分别是数据接入层、对账管理层和对账执行层。 在数据接入层我们提供拉取和推送两种模式经历一个数据适配的过程将数据存储到我们统一的对账数据池当中。 在对账管理层当中我们抽象出了一个对账场景的概念我们基于对账场景进行对账属性的配置首先要选取对账双方的数据源然后进行对账口径编辑这里提供了自定义和模板选择两种方式最后配置对账的周期。这里我们是通过cron表达式来进行周期配置的。 在对账执行层我们会拉取对账数据池和对账核心配置中的相关数据经历配置解析数据抽取策略执行的过程最终输出对账结果。 在线对账模块 下图左边是在线对账平台的架构图右边是在线对账的实例。我们通过RPC、监听消息队列(MQ)、监听数据库binlog三种方式进行对账接入。在线对账平台分为管理层和执行层。管理层主要是承担策略编辑、策略绑定和拦截管理的相关工作。而执行层分为异步准实时对账和同步实时对账两个模块。 右边两图分别是分别是异步对账和同步对账的实例。在异步对账的实例中是运单和结算单元的对账。 运单是什么对应外卖订单作为配送内部的基础交易数据。结算单元是什么 清结算系统内部的模型和运单是一对一关系记录运单各个节点的结算状态。 ①异步对账我们分别监听运单和结算单元的Binlog通过Kafka-Storm的经典架构进行对账策略的执行。实际的流程比较复杂这里只是一张简图大概就是细节可以忽略 收单运单消息后我们会把对于的运单以List的形式存储到Squirrel(Redis)中当结算消息来了以后就把对应运单记录Delete掉。如果有运单记录一直停留在List当中也就是说明结算消息没有来应该是发生了漏结算。我们通过过定时任务轮询运单List将问题数据输出。 ②同步对账示例中是结算内部的流程经历结算单、账单、付款几个流程。因为付款是最后一个流程如果这个时候数据存在问题那么就会造成实际的资金损失。因此我们会在付款环节之前对前面的数据进行对账。如果发现账单和结算单的数据不一致我们就会进行数据拦截。 差错处理模块 在差错处理阶段我们会建立一个统一的差错记录模型核心字段包括对账场景、对账批次数据来源错误类型编码和数据处理状态等。通过定时任务定期轮询差错记录的方式发起差错处理流程首先对差错记录的数据进行二次核对如果二次核对确认这条数据并没有问题我们就会回更差错记录的处理状态。如果二次核对发现数据确实有问题。我们会提供两种处理模式。一种是通过系统的手段自动修复。另外一种是通过报警的方式人为介入。此外我们还建立了一个问题的人工处理模块。可以对一次结算流程的整个生命周期进行回放并针对特定场景提供一键修复的能力。 小结与展望 按照计划实施后系统的各个节点都会有行之有效的对账手段覆盖实现资金安全、数据一致性的保障示意图 本篇文章的内容是我们根据业务的特点经过长期的思考和外部调研总结的一套关于对账的思路以及实施落地方法。目前我们对账体系还在分布实施阶段我们最终的目标是 覆盖度实现全链路无死角的对账。处理效率对于问题的处理尽可能的去人工化实现自动化或者工具化。接入成本后续新的业务场景实现对账尽可能的降低成本。目前外卖配送的单量与日剧增资金安全所面临的挑战越来越大。需多次强调的是资金安全是一个很大的课题需要投入大量的时间和精力去系统思考对账只是其中一环。我们目前围绕资金安全进行了一系列的治理动作未来还将会继续加强我们对于资金安全的理解深度通过更多的对外交流和学习丰富我们保障资金安全的手段。 作者简介 甄超2015年9月加入美团配送清结算系统核心成员专注于清结算架构建设、资金安全治理工作。宏伟2015年4月加入美团配送清结算系统负责人参与了美团配送系统建设的全过程。招聘信息 外卖配送是个挑战与机遇并存、荣誉与艰辛同在的业务优秀的项目也同样需求优秀的同学配送订单调度、清结算系统长期招聘资深工程师、技术专家、架构师等岗位欢迎各位志同道合、能力优秀的人加入。如果有意向请发简历至 zhanghongwei#meituan.com
