系统架构

<article class=“article fmt article-content”><p>领取是指为清偿商品交换和劳务流动所引起的债权债务，货币债务从付款人向收付人的转移的过程。领取能力是电商产品的外围能力之一，作为订单同学，有必要理解关联域领取的流程以及基本概念，同时领取畛域的很多设计思路与资损防控教训对订单域的零碎设计也很有借鉴意义。本文将从领取零碎的历史、基本概念、零碎设计、资损防控与订单与领取交互等方面予以介绍。</p><h2>一、领取零碎历史与演进</h2><p>领取的历史演进能够追溯到现金交易的起源。随着工夫的推移和科技的不断进步，领取零碎经验了多个阶段和改革。</p><h3>起源：票号与钱庄</h3><p>票号是应埠际汇兑需要而开设的金融专营机构，次要经营贷款、汇款、汇兑三大根本业务，是古代银行的雏形。客户在票号交了银子之后，票号就开出汇票给客户。客户能够随身携带汇票而不必携带大量的银子，只有凭票就能够到全国各地的分号兑出银子。分号给客户兑换之后先外部记账，各分号间定期会当面进行对账。镖局就专为票号来运送银子、为商人运送票据。在这种模式下，<strong>汇票+账本（手工记账）是票号在领取环节的信息载体，解决了信息流问题；镖局替票号运送资金，解决了资金流的问题。</strong></p><h3>第一阶段：手工联行（1989前）</h3><p>晚期，国内的金融环境没有达到让央行推广全国对立结算制度的客观条件。于是央行过后提出商业银行要“自成联行零碎，跨行间接通汇，互相发报移卡，及时清理资金”。同一家银行的总行及分支机构称为“联行零碎”。同一联行内的资金结算，由联行总行本人做。跨行业务能够由央行清理，也能够由商业银行本人清理。在这种模式下，各银行须要告知其余行的交易信息形成了特定的公文，加盖印鉴后在银行间传送。这种公文叫做联行函件，而过后的邮电局则承当了收发联行函件的重要业务。</p><p>联行函件整个过程根本都是手工解决，与明清期间的票号相比，并没有太大的改良。尽管运行老本较低，但容易呈现过错，且资金汇划效率仍旧不高，导致占压在途结算资金较多，如异地间资金的汇划，少则 10 多天、多则半年能力实现资金到账。</p><h3>第二阶段：电子联行（19892005）</h3><p>1990 年，中国人民银行清理核心建成，专门为金融机构提供领取清理服务。清理核心包含 NPC（National Process Center，国家金融清理总核心）和 CCPC（City Clearing Processing Center，城市解决核心）。1991 年 4 月 1 日，全国电子联行零碎（EIS）开始试运行。EIS 是基于金融卫星通讯网的，它是人民银行专门用于解决异地（包含跨行和行内）资金清理和资金划拨的零碎。它连贯了商业银行、央行、NPC 和 CCPC。以一位上海招行银行卡的用户要给持有北京工行银行卡的敌人进行汇款，应用 EIS 实现一次领取清理的案例如下图所示：<br/><br/>借助全国电子联行零碎，传票和凭证已变为加密后的电文，与纸质联行相比，提高微小。客户的资金在途工夫缩短到了一两天，大大提高了资金清理的效率，能够说是一个重要的里程碑。</p><h3>第三阶段：现代化领取零碎（2005至今）</h3><p>中国人民银行领取清理零碎（China National Automatic Payment System）是为我国金融机构之间以及金融机构与人民银行之间的领取业务提供最终资金清理的重要外围业务零碎，整体架构如下图所示：<br/></p><p>简略介绍下该零碎的几个外围子系统：<br/></p><p>在现代化领取零碎投产之前，即便是电子联行零碎也须要一到两天能力可能到账，而现代化领取零碎将领取后实时到账变为可能，极大的进步了领取效率，晋升了消费者的领取体验。技术改革往往会带来新的商业机会和改革，推动企业进行翻新。国内的支流电子商务与电子领取平台起也从 2003 年开始衰亡，这里现代化领取零碎的投产工夫（2002年、2005年）十分靠近，很难说两者之间毫无分割。</p><h2>二、领取零碎基本概念</h2><h3>外围概念</h3><p>领取零碎个别指提供领取清理服务、实现领取指令传送及资金清理的零碎，由有领取牌照的领取公司提供。领取零碎是连贯消费者、商户（或平台）和金融机构的桥梁，实现了领取、资金清理、查问统计等性能。这里零碎的解释一下波及到的相干名词，便于咱们后文开展具体介绍。<br/><br/></p><h3>罕用领取模式</h3><h4>平台领取</h4><p>用户提前注册并登录到第三方领取平台，并且曾经在该平台上实现绑卡等操作后，通过第三方领取平台进行领取。</p><h4>网银领取</h4><p>用户在实现必要的银行网银开明手续后，能够通过银行的网银零碎进行在线领取和转账。在进行网银领取时，用户须要登录银行网银零碎，输出相应的领取信息并进行身份验证，而后能够实现在线领取交易，挪动互联网时代较为少用。</p><h4>快捷领取</h4><p>一种简化了领取流程的领取形式。通常状况下，用户在首次领取时须要绑定银行卡或者进行一次认证，之后就能够应用该领取形式来实现交易，无需反复输出银行卡信息或进行繁琐的身份验证。在后续的领取过程中，用户只需进行简略的确认操作或者输出领取明码，就可能疾速实现交易。</p><h4>协定领取</h4><p>协定领取也称代收或者代扣，代收指渠道受权商户能够从用户的银行账户中扣款，个别用于定期扣款，如水电煤气、有线电视费、包月/包年会员费等。</p><h4>虚构货币领取</h4><p>不少公司会有本人的虚构币，这些虚币也能够作为一种领取形式。个别会有一些金额、品类的限度，如虚构领取不得超过每笔订单结算金额的 50%。</p><h4>余额领取</h4><p>为用户建设本地账户并应用账户来实现领取，账户反对充值、提现等操作。</p><h4>信用领取</h4><p>指应用信用账户进行透支，相似信用卡领取。须要较强的风控能力。</p><h2>三、领取零碎简介</h2><h3>整体架构</h3><p>在理解了领取零碎相干演进与基本概念后，咱们再来看一下领取零碎的整体架构。对于订单同学来说，在理论领取业务的接入过程中，能够接触到两类领取零碎：</p><p>第三方领取零碎：即订单同学了解里的“领取渠道”。比方咱们作为商户间接对接到微信、支付宝的领取零碎中，从而具备领取收款能力。整个零碎中的“外围零碎”性能往往是大家最为相熟的局部，它概括了咱们平时各种生产领取场景。咱们平时进行的电商交易、红包转账等都是“领取利用”的体现模式。<br/></p><p>实际中，三方领取零碎往往能够拆分为网关、金融替换、收单域、领取域以及账务域、会员域、营销域等多个畛域。</p><p>聚合领取零碎：即订单同学通常了解里的“领取”。次要性能为屏蔽各种第三方领取零碎的差异性，提供对立的接入形式和领取产品，比方得物的汇金零碎。<br/><br/><em>一个比拟典型的电商平台的领取架构</em></p><h3>领取流程</h3><h4>用户领取流程</h4><p>从流量角度来看，对于一次用户发动的领取行为，申请首先达到领取网关，通过必要的平安验证和流量限度后，被转发给对应的领取服务模块。随后用户跳转收银台页面抉择领取形式后确认领取，由领取零碎对接银行/第三方领取机构的领取接口进行后续的领取。<br/></p><h4>领取接口</h4><p>以业内某领取产品为例，其提供了多种集成领取能力的形式，其中「手机网页领取」实用于商户无独立 App，通过挪动端 H5 网站进行流传的形式。咱们以一次手机网页领取为例，理解领取的外围接口。<br/><br/>如上图所示，能够从交易领取的几个环节进行剖析。</p><ul><li>领取接口</li></ul><ol><li>在商户的 H5 网站下单并确认领取。</li><li>商户系统生成订单信息并结构领取申请发送到该领取产品零碎。</li><li>零碎校验通过后拼装本次领取所需参数返回给商户前端。</li><li>商户前端将页面跳转至该领取产品官网两头页，如果用户手机上安装了该领取产品 App，则主动唤起 App；如果未装置，则持续在以后页面进入官网 H5 收银台。</li><li>用户实现明码输出并领取。</li><li>零碎外部实现本次领取单解决流程。</li><li>解决实现后，以异步音讯模式告诉商户后盾 Notify_URL，确认此次交易胜利。</li><li>解决实现后，从官网两头页跳转商户自定义领取后果页 Return_URL，展现领取后果。</li><li>实现本次领取。</li></ol><ul><li>交易敞开接口</li></ul><p>针对须要的业务场景，反对被动勾销订单（针对未领取订单，已领取单可走退款流程）。</p><ol><li>用户发动/商户后盾管理员发动订单勾销申请。</li><li>商户零碎向该领取产品零碎发动敞开订单申请。</li><li>后盾判断解决后返回勾销后果。</li></ol><ul><li>交易查问接口</li></ul><ol><li>商户后盾发动交易查问申请。</li><li>零碎判断交易单存在，并返回交易后果。</li></ol><ul><li>退款接口</li></ul><ol><li>用户/商户发动退款申请</li><li>商户零碎审核解决退款申请是否非法。</li><li>非法状况下，商户零碎向该领取产品零碎发动退款申请。</li><li>零碎解决并返回后果。</li><li>相干渠道将资金返回（有肯定时间延迟）。</li></ol><ul><li>退款查问接口</li></ul><ol><li>用户/商户发动退款查问申请。</li><li>零碎解决后返回后果。</li></ol><ul><li>下载对账单接口</li></ul><ol><li>商户零碎依据业务对账须要，发动对账申请，查问最新的对账单下载地址。</li><li>零碎返回对账单下载地址。商户零碎依据对账单下载地址下载对账文件。</li><li>零碎返回对账单文件。</li></ol><h3>资金流与信息流</h3><p>央行在 2017 年 8 月公布《对于将非银行领取机构网络领取业务由直连模式迁徙至网联平台解决的告诉》，规定了非金融领取机构受理波及银行账户的网络领取业务全副通过网联解决。目前业内采纳的都是“间连”模式提供网络收单服务。这里以一次银行卡网络收单领取交易流程为例，整体资金流与信息流如下：<br/></p><ol><li>【信息流】步骤 1 用户通过电商领取收银台下单并领取，电商领取解决领取业务数据，并将领取申请发到第三方领取渠道。</li><li>【信息流】步骤 2 第三方领取将申请转发至网联。</li><li>【信息流】步骤 3 网联将领取扣款申请转发到发卡行。</li><li>【资金流】步骤 4 发卡行从用户银行卡扣款，用户银行卡金额缩小，返回领取胜利给网联。</li><li>【信息流】步骤 5 网联记录领取胜利数据，返回领取胜利给三方领取。</li><li>【信息流】步骤 6 三方领取回调电商领取零碎，更新领取状态和记录领取信息。电商领取回调订单零碎，更新订单状态，给用户返回下单胜利。</li><li>【资金流】步骤 7 网联周期性对三方领取业务做清结算，通过央行清理零碎做资金清理划拨到三方领取机构备付金托管所在银行。</li><li>【信息流】步骤 8 三方清结算服务对货款商户领取交易记录做清理和结算，具体细节如下：</li></ol><ul><li>清理服务依据交易因素对商户主体交易依照约定的计费规定进行清理，记录商户主体因为商业交易而产生的债权债务，周期性生成对应的结算凭证。</li><li>结算服务依照约定结算周期和形式对商户主体产生的债权债务进行清偿,申请网联结算打款。</li></ul><ol start=“9”><li>【资金流】步骤 9 网联通过周期性清结算形式模式做资金划拨到商户收款所在银行。</li><li>【信息流】步骤 10 商户结算收款银行账户显示货款到账。</li></ol><p>从上图看，步骤 1 到步骤 6 体现了付款方付一笔钱的流程，示意了三方领取一笔收单业务的信息流和资金流，其中步骤 4 中付款方的银行卡余额会被实时扣减，发卡行侧记应酬未付。步骤 5 网联记录领取交易相干数据作为跨行清结算业务的根据。步骤 6 三方领取侧更新领取交易后果并逐层告诉至订单零碎，同时把领取胜利音讯同步给三方的清结算，清结算根据交易领取的结算因素做清分分录，记录商户应结资金和应收手续费。步骤 7 属于资金流。由网联负责跨行周期清理，网联通过央行清理零碎实现资金划拨后资金到了三方备付金账户。步骤 8 属于资金流。三方领取实现周期性结算凭证生成后通过网联发动结算打款，最终资金到账工夫依赖于网联清理+资金划拨的工夫。自此，一笔电商交易通过用户银行卡扣款、网联清结算、三方领取清结算，最终实现钱货两清。</p><h3>资金结算</h3><p>清结算是对交易领取数据进行全面整顿、计算、汇总、查看核查和最终结算的过程，可拆分为清理和结算两个子域。清理域服务依据交易推送的信息，依照约定的计费规定进行清分、汇总，记录主体因商业交易而产生的债权债务，并定期生成相应的结算凭证。结算域依据约定的结算周期和形式，对商户主体产生的债权债务进行清偿。清结算确保了金融交易的安全性和准确性，保障各方权利。</p><p>形象的来看，领取波及业务次要可分为收、付、退、提、转、充等 6 大类（<strong>对于订单同学来说更关怀的是收、付、退三大性能，对应订单的购买、履约、售后三个子域</strong>）。资金结算个别分实时结算与定期结算，咱们以定期结算为例，剖析整体资金结算的简版流程。<br/></p><h4>计费</h4><p>计费为通过对应的计费规定将业务流水音讯转换为清结算的资金语言，生成对应的结算资金明细。</p><ul><li>匹配 以交易业务的流水信息路由匹配到相应的计费规定。</li><li>清分 依据计费规定，将资金划分给交易中的不同角色，生成对应的计费后果与资金摊派明细。简略来说就是算清楚哪个费用项，多少钱，谁给谁。</li><li>分录 落地计费明细与结算明细变更。</li></ul><h4>汇总</h4><p>依据清理明细，依照资金指令以及时间段进行汇总操作。</p><h4>校验</h4><p>次要是对整个结算的模型、指令以及单据、工作的完整性校验，以及账务资金核查查看等，确保最终结算前的数据无误。</p><h4>结算</h4><p>生成账单并执行相应的资金指令，实现最终的资金转移。</p><h3>资金平安</h3><p>领取业务的资金平安次要能够从精确、合规两个方面了解：</p><ol><li>精确</li></ol><ul><li>信息精确：即信息不错不漏不重。应答思路为流程上的容错机制以及核查来实现。</li><li>机会精确：即不早不晚，应答思路为核查以及监控预警。</li></ul><ol start=“2”><li>合规</li></ol><ul><li>二清合规</li></ul><h3>流程容错</h3><p><strong>单据关联</strong></p><p>正如某些订单域外部的多种单据间存在关联关系一样，领取设计上也有单据间关联的设计。例如从流程上来说所有的逆向过程都必须持有正向的单据，因而退款必须要关联到原来的领取，退款领取单要关联到原领取单。单据之间的关联只有有以下用处：</p><ul><li>状态一致性：正如订单域中的订单单据如果胜利，则订单关联的营销单、领取单肯定胜利一样。领取场景的各个单据的状态也存在关联关系，例如创立退款领取单的前提是所关联的原领取单必须胜利。</li><li>金额一致性：金额管制是退款的一个外围问题，管制不好很容易产生资损。因为反对屡次局部退款，金额必须避免退超，这里蕴含两个维度，一个是总金额不能退超，一个是各个维度的资金组成组成不能退超。具体的做法是，每一笔退款的金额，都会在原单上累加记录到已退金额，记录已退款的总金额，校验不可超。</li></ul><p><strong>幂等</strong></p><p>通过惟一键实现幂等是较为常见的实现形式。例如订单侧常见的反复领取退款是以订单号关联 PaymentNo 做反复领取校验的惟一键，领取侧交易单以内部单号 + 商户号为惟一键，领取单以交易单号 + 操作码作为惟一键。幂等能够无效的避免操作不反复，这里须要额定留神的是，幂等的可重入问题：例如对于一笔整单退的申请，上游申请退款 200 元，领取域曾经解决胜利，上游因为超时基于同一笔领取单号进行进行退款重试，此时应该返回胜利而非业务校验异样。</p><p><strong>重试</strong></p><p>最大致力告诉是领取畛域常见的流程容错伎俩，分布式环境下，网络抖动、服务临时不可用等都会造成业务流程解决异样，常见的策略为将申请放入 MQ 进行异步重试，重试距离逐次拉长，重试如果胜利，则回调交易，如果失败或者解决中，则持续重试（所以接口幂等反对可重入很重要，对重试更敌对）。</p><ul><li>例如订单收到领取胜利回调后，开始解决订单流程。如果在下单阶段仅锁定库存、营销等资源，须要在领取回调流程真正扣减资源的话，这里须要对超时等场景进行重试（调用上游须要做好幂等），如资源扣减失败则关单退款</li></ul><p>重试指定次数如业务单据仍未达到终态，则将订单信息长久到数据库中，告诉人工进行解决。</p><ul><li>例如用户卡登记，会员销户等问题导致退款退不进来，重试肯定次数后领取单只能置为失败。期待产运分割用户后，在领取层从新生成退款领取单进行退款。</li></ul><h4>核查</h4><p>核查是保障资金平安的重要机制。从时效角度来看，次要有（准）实时核查与离线核查（如 T+1 核查），实时核查的准确性不如离线核查，且须要相应的实时核查平台建设（例如得物的 DCheck 平台）。离线核查次要的问题是发现问题的机会较为后置，局部场景会影响零碎的时效性。例如清结算与账务侧的每日资金核查失败会影响结算时效性。</p><p>从核查维度来看，次要能够有如下几种核查形式：</p><p><strong>一致性核查：</strong></p><p>资金在从业务端终点（数据由业务产生）到财务端起点（最终流入财务零碎）中，在链路中的各个系统/表中都留有相应的凭证。例如交易一笔订单的实付金额对应着领取的一笔领取单的领取金额，商户一笔收单或领取退款会在对应的商户待结算户产生一笔动账，对应在清结算会做一笔有资金方向的清分分录。对这些金额咱们能够建设相应的一致性核查工作进行核查验证。<br/><br/>一致性核查包含双向一致性核查和单向一致性核查两种，单向一致性核查无奈发现单边数据缺失问题。</p><p><strong>业务正确性核查：</strong></p><p>在特定的业务场景下，业务有本身的业务规定，能够针对这些业务规定进行校验。常见有以下四种形式：</p><ul><li>个别正确性校验：例如某些领取业务只能用于特定的商品类型，则能够通过自定义SQL校验规定来进行校验。</li><li>总分校验：各个子金额汇总该当等于总金额。</li><li>程序性核查：业务流程中有顺次执行的解决流程，则能够校验是否有流程缺失。</li><li>幂等性核查：校验是否有业务被异样的反复解决，如反复退款等。<br/></li></ul><p><strong>时效性核查：</strong></p><p>次要核查时效相干，如未领取的领取单在超时后是否及时敞开，结算机会是否满足时效要求等。<br/></p><p><strong>危险额度核查：</strong></p><p>对一些可能有高风险的要害配置与金额相干额度进行校验，如分账比例 <=30%、不能负佣、总营销金额不能超过每日下限等。<br/></p><p>总的来说，对实时性较高的工作采纳实时核查，而日终查看等采纳离线核查，通过对领取全过程的监控预警以及失败 case 产研及时染指解决，从而保障了资金平安的准确性。</p><h4>资损攻防</h4><p>也就是咱们业内常说的混沌工程，通过注入故障能够无效的验证咱们的零碎是否足够强壮以及监控核查是否及时无效，常见的实现形式有：</p><ul><li>通过模仿外围依赖超时等异样场景，验证容错重试流程是否能够失常工作。</li><li>模仿资损外围字段落库异样的场景，验证监控核查是否能够及时发现。当然也能够通过旁路攻打的形式，如批改数据库的binlog字段而非间接批改数据来查看是否触发告警，这样对线上业务的影响会更小一些。</li></ul><h4>二清</h4><p>对订单同学来说，二清就是在下单时查问商户对应的领取二级商户信息并传递到领取与结算。那么什么是二清？二清合规问题是如何解决的？</p><p><strong>什么是二清？</strong></p><p>首先咱们通过几个案例来理解下什么是二清。<br/><br/>二清问题实际上能够分为“资金二清”与“信息二清”：</p><ul><li>资金二清：指无证机构通过平台或大商户模式截留积淀了应间接结算给二级商户的资金，再通过其余形式实现二次清理，实质性的管制整体结算资金。</li><li>信息二清：信息二清层面，监管不仅要求平台不能进行“资金二清”，同样也要求其提供的交易信息实在可追溯，且分账信息是商户实在志愿。</li></ul><p>信息二清次要为了防止平台应用了合规的三方领取机构，尽管不触碰具体的资金结算，但把握了原始的交易订单数据、分润信息和商户资金结算的入账规定，使银行或领取机构依据其提供的分账规定、指令为商户入账，本质上通过平台分账指令传输主导了结算资金的方向。</p><p>电商公司晚期求生存是更次要的问题，在整体领取零碎演进过程中，往往都采纳二清的模式。这外面用于公司对立收款的账号咱们称之为“大账户”。资金通过用户流向公司的大账户，在通过结算最终流向卖家。这里存在肯定的合规危险：</p><ul><li>资金挪用危险：平台代为几种收款，有擅自挪用的危险</li><li>资金监管危险：无证机构向平台入驻的商家结算资金，游离于监管体系之外</li><li>交易信息危险：无奈保障平台提供交易信息的真实性，有伪造的危险</li></ul><p>近些年随着监管越发成熟，电商公司因为领取不合规被责令整改的新闻不足为奇，随着公司业务规模的倒退，二清合规问题也愈发迫切的须要失去解决。</p><p><strong>二清解决方案</strong></p><p>对于二清问题，通常有两种解决形式：</p><ul><li>通过申请或收买的形式取得领取牌照，使平台取得非法的资金清理能力（牌照较低廉，老本较高）。</li><li>接入三方领取公司的二清解决方案（聚合领取零碎需配合接入革新）。</li></ul><p>目前得物采纳的是第二种计划，咱们以某宝的二清解决方案为例，简略介绍得物是如何通过某宝的互联网平台直付通产品解决二清问题。简略来说，得物平台上的二级商户须要入驻某宝成为某宝的商家，买家在得物的订单领取胜利（反对多个商家的订单合并领取）后，某宝记录对应商家待结算资金，待平台确认可结算时，某宝将资金间接结算至商家指定的收款账号。同时反对平台按订单灵便抽取佣金（也就是咱们常说的分账）。<br/></p><p>这外面有几个外围的概念：</p><ul><li><strong>分账抽佣</strong>：可依据理论业务场景将交易资金分账到其余业务参与方的领取产品账号（例如：平台抽取佣金、其余方服务费等）。目前反对单个平台<strong>最多 20000 个</strong>参与方的分账，单笔交易订单<strong>最高分账比例 30%</strong>。</li><li><strong>结算</strong>：买家确认收货后，得物通过资金确认结算性能，将整笔订单结算给二级商户收款账号，最长账期反对 365 天，超过 365 天订单主动结算。</li><li><strong>营销补差</strong>：平台举办平台出资的营销流动，如跨店满减、全场通用券等营销伎俩，资金结算后，平台向该领取产品发动补差指令，将营销资金补到二级商户的账号。</li></ul><p><strong>简版流程</strong>：</p><ul><li>买家领取订单，订单触发分账，将钱转入卖家待结算户，<strong>此账户金额对卖家不可见</strong></li><li>用户确认收款，得物平台发动结算指令，该领取产品将卖家待结算户的钱依照当时在该产品后盾配置的分成规定进行分账。别离流入得物的该领取产品账户与二级商家已结算户，<strong>此时卖家就能够看到本人的账户余额减少了</strong>。</li><li>卖家将二级商家已结算账户的钱提现等操作。</li></ul><p>当然这里还有一些撤销分账、补差等细节流程，这里就不做过多的开展了，感兴趣的同学能够浏览三方领取公司的二清解决方案相干文档。</p><h2>四、订单与领取</h2><h3>得物订单与领取交互</h3><p>因为监管 KYC 的要求，一笔领取单不仅须要领取相干信息的如领取形式、领取金额、领取无效工夫等，也须要订单的买家信息、卖家信息、商品信息等等。这些信息客户端无奈全副给到，且基于平安的角度，也不能由客户端通过公网传参的形式传递，须要订单域与领取域进行交互传递相干信息。目前得物领取提供了下单模式（业务方调用领取零碎创立领取单）和反查模式（业务方实现 PayInfo SPI，领取零碎反查业务方获取领取信息）两种模式，目前订单是依照反查模式与领取交互。<br/></p><h3>订单开发中常见领取相干问题</h3><h4>0 元订单</h4><p>微信/支付宝等常见三方领取文档里有阐明，领取金额 Total_amount 字段取值最小为 1（1 分钱）。因而如果 0 元订单还创立预领取单的话会失败。之前有订单域通过注册定时回调工作，伪装成一个收银台领取回调的形式来实现 0 元单回调，实际下来会踩坑（与理论业务流程不符，假装的回调须要不停适配领取回调的改变）。正确做法是对于 0 元订单，只走创立商户订单的流程，并间接更新订单状态，不走领取回调流程。</p><h4>领取订单过期工夫设计</h4><p>在电商交易系统中有两个过期工夫的概念：订单过期工夫和领取单过期工夫。这两个工夫会产生时间差的起因在于：用户在「确认订单页」点击「提交订单」就会创立订单并跳转至收银台，此时开始锁定库存并计时；而用户在收银台停留的工夫是不确定的，这部分不确定工夫造成了时间差。具体来讲，如果用户点击「去领取」创立预领取单时传递的过期工夫是个固定值，那么就有可能会呈现一种状况：在订单零碎该订单曾经过期生效了，但用户在领取平台内还能领取该笔订单（而此时领取胜利回调订单零碎，订单已勾销，零碎是不会进行后续发货流程的）。因而，领取单的过期工夫要联合领取单创立以后工夫和订单创立工夫一起动静计算得出，保持一致，从而给平台用户提供更好的生产体验。</p><h2>五、总结</h2><p>总的来看，理解领取零碎有助于订单交易方向的同学理清上下游，更加全面了解电子商务四流中的资金流。同时领取零碎在资金核查、流程容错方面有着十分经典的设计，值得咱们去学习借鉴。</p><p>参考文章：</p><p>1.银行、票号兴替与清末民初金融改革 <br/>2.https://baijiahao.baidu.com/s?id=1774618341934674551&wfr=spider&for=pc <br/>3.https://download.csdn.net/blog/column/9276612/108820800 <br/>4.https://www.sohu.com/a/314762715_348231</p><p><strong>*文/申尧</strong></p><p>本文属得物技术原创，更多精彩文章请看：得物技术官网</p><p>未经得物技术许可严禁转载，否则依法追究法律责任！</p></article> ...

作者：京东科技 倪新明 门面模式和适配器模式是代码级的设计模式，而防腐层实质是一种 防御型策略 ，在更高的层级对系统进行解耦1 对于防腐层Anti-Corruption Layer(ACL) 如下： Implement a façade or adapter layer between different subsystems that don't share the same semantics . This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems .在不共享语义的不同子系统间实现一个门面层或适配层，该层转换一个零碎到另一个子系统的申请，应用该模式确保一个利用的设计不被内部零碎的依赖所限度。 2 问题背景一个零碎不可能承当所有的职能，大多数状况下都会依赖内部零碎的数据或能力。这些内部零碎或者遗留零碎所关注的畛域以及技术选型不尽相同，特地是对于一些老旧的遗留零碎往往会面临是技术升级或淘汰的场景。所以，新零碎与老零碎间的集成往往须要适配他们的协定、数据模型、API或者某些性能个性，然而对于设计人员并不总是心愿将这些方面的 “渗入” 到以后零碎中。这种状况不仅仅呈现在新零碎和遗留零碎之间，对于零碎所依赖的第三方零碎也同样实用，因为这些第三方零碎可能存在由不同团队开发、技术选型及架构各异、畛域模型不统一、可控性差等等诸多不可控因素。 上述场景在理论的业务开发中常常遇到，咱们构建的零碎并不是孤立的，而是会融入到公司现有的IT零碎，甚至会依赖公司内部的三方服务，模式上可能基于HTTP协定的调用，也可能是外部的JSF或OPEN-API调用。这种场景下，内部零碎服务提供的模型与外部零碎畛域上下文下的模型不能确保保持一致。如果在零碎设计时不思考隔离，而是将内部模型间接穿透到外部零碎的外围域，则当模型语义产生不统一，或发生变化时，会净化本身畛域。 3 解决方案建设防腐层对不同的子系统进行隔离，该层负责转换两个子系统间的通信。通过引入防腐层，实现不同子系统间的解耦，隔离内部零碎的变动对以后零碎的影响，防止以后零碎的设计因为内部零碎的设计和技术实现形式而进行斗争。 防腐层个别会包含模型转换的职能： • 将以后零碎的模型转换成内部零碎的模型 • 将内部零碎的响应转换成以后零碎的模型 除此之外，通过在不同子系统间引入独立的 "层"，能够在该层进行例如： ...

作者：京东科技 杜晓玉前言数据库，交易系统中最外围依赖，数据长久化属于最外围服务。 随着互联网的遍及，大流量高并发的场景越来越多，7*24的交易系统对高可用要求越来越高，同时在“数据为王”大环境下，交易数据最终通过数据库进行长久化存储，数据库成为整个零碎最终重要服务，不能出一点问题，尤其外围P0零碎哪怕霎时的DB操作异样可能造成大量异样交易，可能产生致命的问题，所以外围零碎弱依赖数据库都是必须思考的。 数据库弱依赖的整体思路：将最牢靠链路再减少上备用链路替换，解决方案次要通过其余存储介质+弥补机制替换同步的DB操作，预期成果：数据库呈现故障期间也能保证系统运行失常不影响线上业务发展。 本期介绍下实际过的三种解决方案：DB灾备机制计划、DB高并发替换计划、财产零碎弱依赖DB计划。 一、DB灾备机制计划日常引发数据库操作出现异常的常见状况：网络链路异样、执行工单导致数据库性能降落、慢SQL导致数据库异样等，并且从发现问题到解决往往工夫不短，尤其外围交易链路都已无奈容忍短时间的异样故障，所以首先思考减少灾备机制，出现异常时间段内也要保障交易成功率，哪怕能够损失一点性能要求。DB灾备机制计划是2016年接触到并施行第一版弱依赖数据库计划。计划次要思路：DB操作故障时间段内，通过其余存储介质长期存储数据，并通过MQ异步弥补还原DB操作，达到最终数据一致性。 图1 DB灾备流程 具体革新点： 1.DB操作减少灾备解决逻辑，出现异常时将数据存储到缓存，并发送MQ，再通过生产MQ异步还原DB数据操作； 2.数据查问链路，必须反对先查缓存再查数据库，并且缩小内部查问申请； 3.数据库的DB操作性能十分好（毫秒级），灾备解决链路同步操作入缓存+MQ发送，整体性能耗时变高了，需正当设置MQ发送超时工夫，过后接入团队外部MQSender组件，解决发送失败后异步主动重发，晋升灾备解决链路的成功率，同时保障了MQ音讯无失落。 二、DB高并发替换计划数据库的连接数是贵重且无限，但凡连贯数据库的零碎，不可能有限进行机器扩容反对流量的增长，同时数据库反对TPS也是有下限，例如Mysql5.6.x版本倡议最大500~1000之间，尤其对高性能和高并发的零碎来说，在高要求的性能指标下，数据库吞吐量成为撑持大流量的瓶颈，如果通过减少数据库服务器，老本往往也是无奈承当。 2018年有幸参加到P0外围交易系统的高可用降级我的项目，指标将交易系统tps晋升至2w以上，过后20台数据库物理机（单机单实例，Mysql版本5.6.x），在高性能指标要求下，零碎压测tps峰值最高可达到1~1.5w。为达成指标，同时思考资源老本，我的项目降级革新计划思路：通过缓存+MQ组合将数据库操作齐全异步化，同时利用MQ生产批量拉取策略，批量拉取数据进行DB批量操作，缩小数据库操作次数晋升效率。中间件抉择上充分利用缓存组件的高性能、高吞吐、反对连接数更大的劣势，保障了高性能同时也解决利用扩容问题。同时思考到MQ平台上部署其余利用topic影响发送性能，搭建独自独享MQ集群，保障MQ发送的性能要求，屡次大促期间MQ发送耗时tp999都小于50ms。中间件达到高性能要求后，将DB操作替换成同步入缓存+发送MQ，晋升交易链路吞吐量，压测后果也达到tps>2w+指标。 图2 DB高并发替换 具体革新点： 1.交易链路中DB操作全为insert，无update，满足了异步化后DB操作可进行批处理； 2.搭建独自MQ平台，保障了MQ发送性能，同时接入团队外部MQSender组件，解决发送失败的异步主动重发，保障整体链路的成功率； 3.缓存组件，自身具备高吞吐量并且可疾速扩容，异步化后交易链路吞吐量大幅晋升。同时缓存接入R2M、JIMDB双缓存，针对不同机房设置主从操作，例如金融机房同步主操作R2M，异步操作JIMDB，性能最优。双缓存机制避免单个缓存组件呈现故障后可疾速切换，保障整体链路成功率； 4.异步化后通过MQ生产还原DB操作，通过正当设置MQ拉取策略，批量进行DB操作，缩小DB操作晋升效率；同时减少异步化提早的UMP监控，监控从交易发动到异步入库残缺链路耗时，可直观异步化后MQ生产能力，便于动静调整； 5.缩小内部零碎的查问诉求，对立以交易实现音讯进行触达扭转，必要查问申请全副查缓存，上游要具备查问异样时重试机制。 三、财产零碎弱依赖DB计划财产交易系统参考以上两版计划，并联合本身交易场景多、交易链路长、数据状态多状况。基于此设计出一版以流水数据驱动交易数据扭转的计划，大略思路：交易链路少变动，交易数据的DB操作不变动，减少直达层将交易链路DB操作转换为逐笔流水数据的长久化操作，再异步生产MQ还原交易数据的DB操作，通过将新增直达层做到弱依赖DB，达到整个交易链路弱依赖DB。联合零碎的流量现状，查问流量大交易流量TPS未达上万，当下次要指标增强交易链路的健壮性。 流水数据长久化的操作：并行执行DB入库、入缓存，二者其一操作胜利则间接返回胜利，并异步发送弥补操作的MQ，如果DB呈现故障期间缓存操作失常也可保证系统运行失常，不影响线上业务发展。例如生产场景的弱依赖DB革新，失常收到交易申请后，首先业务校验+防重幂等>创立订单>扣减用户份额>更新订单状态，将创立订单、更新订单状态的操作革新为创立两笔流水数据的操作，交易链路不进行大的革新前提下，通过将流水数据长久化做到弱依赖DB，这样交易过程中即便DB呈现故障时只有缓存组件失常运行即可保障生产交易失常实现，再通过异步生产MQ还原创立订单、更新订单的操作。计划落地后失去了很好的验证，曾经验过数据库因执行大的变更工单导致数据库呈现性能故障，生产交易链路不受影响，保障业务失常运行和用户体验。 图3 财产零碎弱依赖DB计划 具体革新点： 1.直达层流水数据长久化外围操作：并行执行DB的insert操作、入缓存，二者其一操作胜利则间接返回胜利，并异步发送弥补操作的MQ； 2.生产MQ异步还原交易库的DB操作时，通过数据中状态位保障MQ生产的程序执行； 3.流水库和缓存的双向同步，如果流水库或缓存呈现故障时，异步进行互相弥补存储，目前流水库存储全量流水数据。 4.交易链路次要革新两点：一、防重幂等以流水数据为准，流水数据查问是合并缓存和DB数据后返回；二、交易数据调用DB操作切换到创立流水数据的操作； 总结以上数据库弱依赖的技术计划更实用于数据偏流水式的交易系统，随技术迭代和业务倒退，技术计划也层出不穷并一直迭代翻新，欢送大家跟咱们研发团队交换沟通，共同进步。

作者：vivo官网商城开发团队 - Xu Yi、Yan Chao本文是vivo商城系列文章，次要介绍vivo商城库存零碎倒退历程、架构设计思路以及应答业务场景的实际。 一、业务背景库存零碎是电商商品治理的外围零碎，本文次要介绍vivo商城库存核心倒退历程、架构设计思路及应答各种业务场景的实际。 vivo商城原库存零碎耦合在商品零碎，思考到相干业务逻辑复杂度越来越高，库存做了服务拆分，在可售库存治理的根底上新增了实物库存治理、秒杀库存、物流时效 、发货限度、分仓治理等性能，满足了商城库存相干业务需要。 本文将介绍vivo商城库存零碎架构设计教训以及一些问题的解决方案。 二、零碎架构设计2.1 vivo大电商库存架构依据vivo大电商的销售渠道与业务场景能够将库存业务架构分为3个层级：仓库层、调度层以及销售层。 仓库层对应实体仓库，包含自营仓库、顺丰仓等第三方仓库以及WMS零碎、ERP零碎等；调度层负责库存调度与订单发货治理；销售层蕴含多个服务终端，vivo官网商城、vivo门店、第三方电商分销渠道等。其分层构造如图所示： 本文探讨的vivo官网商城库存架构设计，从整个vivo大电商库存架构来看，vivo官网商城库存零碎波及销售层外部架构以及销售层与调度层的交互。 2.2 商城库存零碎架构演变晚期商城的库存冗余在各业务零碎中，如可售库存在商品零碎、流动库存在营销零碎等，库存流转也只有扣减与开释，无奈针对库存进行整合与业务翻新，存在诸多限度： 不能进行精细化治理，库存未分层，无奈针对实物库存、分仓策略、流动库存进行精细化治理。没有分仓策略，无奈提前获取商品收发地址，物流时效无奈估算。无奈针对地区、商品等进行发货管控。实时性差，无奈及时同步实物库存以及分仓策略。性能弱，与其余零碎耦合大，不能灵便扩大。基于上述限度与产品冀望，21年库存零碎实现初版架构设计，尔后零碎一直迭代欠缺，造成以后的零碎架构： 库存零碎提供两个外围能力：交易能力和库存治理。下层业务方能够调用提供的API实现库存查问、库存扣减等操作；治理台能够按成分仓策略、库存同步等操作。 三、零碎业务架构3.1 库存类型&分仓治理3.1.1 库存类型构造库存零碎一共蕴含4类库存：可售库存、实物库存、预占库存、流动库存。 可售库存：经营配置的普通商品库存，商品维度到SKU。实物库存：由仓储零碎同步到库存零碎的实物库存，细化到具体仓库。预占库存：用户下单实现库存预占，仓储零碎发货后开释预占库存，预占库存能够监控已下单未发货库存量。流动库存：用于秒杀、抢购等各类营销流动的商品库存。基于不同类型库存，能够构建一个简略的库存分层体系： 3.1.2 分仓治理库存核心还保护了仓库信息、分仓策略、仓库实物库存信息等等： 仓库信息：仓库根底信息，包含仓库地址、类型、编码等。分仓策略：仓库性能信息，仓库可发货区域、无实物库存后的备选仓库；订单依据收货地址对应优先发货的仓库，争取尽快发货尽早到货。仓库库存：仓库实物库存，由仓库调度零碎同步到商城库存零碎。3.2 商城库存流转计划商品库存流转波及两个次要操作：正向库存扣减、逆向库存回退，整套库存变更流程如下： 3.2.1 正向库存扣减流程对于库存扣减，目前常见有两种库存扣减计划： （1）下单时扣库存。 长处是：实时扣库存，防止付款时因库存有余而阻断影响用户体验。毛病是：库存无限的状况下，歹意下单占库存影响其余失常用户下单。比如说有100台手机，如果没有限度下单数量，这100个库存可能被一个用户歹意占用，导致其余用户无奈购买。（2）领取时扣库存。 长处是：不受歹意下单影响。毛病是：当领取订单数大于理论库存，会阻断局部用户领取，影响购物体验。比如说只有100台手机，但可能下了1000个订单，但有900个订单在领取时无奈购买。从用户体验思考，咱们采纳的是下单时扣库存 + 回退这种计划。 下单时扣减库存，但只保留一段时间（比方15分钟），保留时间段内未领取则开释库存，防止长时间占用库存。 3.2.2 逆向库存回退流程库存回退基于库存变更日志一一回退。 库存回退根本流程：订单出库前用户申请退款，回退可售库存、回退预占库存、软删除扣减日志、减少回退日志；一旦商品出库，用户申请退货走处理机流程，可售库存和实物库存均不回退。 3.3 精细化发货管控库存零碎还提供了一系列定制辅助性能：分仓策略、发货限度、物流时效等等。 （1）分仓策略 为了给用户更快的发货，咱们采纳的是分仓策略，即由最近的仓库（存在优先级）给用户发货；同时存在备选仓库，当所有仓库无实物库存时可走备选仓库。 3.3.1 发货限度发货限度分地区限度工夫限度。 地区限度：依据收货地址批量设置局部区域无奈发货等规定，粒度到省市区维度。工夫限度：仓库的发货时效治理，包含每天的发货时段、大促发货时段、以及非凡状况下的停发时段。3.3.2 物流时效预估依据用户收货地址，基于分仓策略确定发货地址，再基于发货时效确定发货工夫，晋升用户体验。 四、零碎架构技术要点4.1 库存扣减防重订单反复提交会导致库存反复扣减，比方用户误提交、零碎超时重试等，针对此类问题有如下常见解决方案： 订单提交按钮单击置灰，防止反复提交。注：对于按钮置灰这种计划，能够缩小用户误触反复提交的可能性，但不能从根本上解决库存被反复扣减的问题，比方通过脚本来刷扣减库存的接口，仍旧造成库存的反复扣减。保障库存扣减接口的幂等性。注：保障接口幂等的计划有很多，比方每次扣减库存时，带上惟一的流水号，利用数据库的惟一索引保障幂等等。采纳令牌机制。用户提交订单会进行令牌校验，校验通过能力提交订单。注：这种计划保障每次提交的订单是惟一的，如果用户屡次下单，那么会产生多个订单。本零碎采纳的是保障接口幂等性的计划。 在库存扣减接口入参中减少订单序列号作为惟一标识，库存扣减时减少一条扣减日志。当接口反复申请时，会优先校验是否曾经存在扣减记录，如果已存在则间接返回，防止反复扣减问题，具体流程如下： 4.2 防超卖与高并发扣减计划4.2.1 惯例渠道防超卖计划惯例下单渠道流量小且对超卖危险讨厌度极高，罕用的防超卖计划有： 计划一： 间接数据库扣减。通过sql判断残余库存是否大于等于待扣库存，满足则扣减库存。该计划利用乐观锁原理即update的排他性确保事务性，防止超卖。 伪代码sql： sql：update store set store = store - #{deductStore } where (store-#{deductStore }) >= 0该计划的长处是： ...

作者：京东科技 李良文一、前言电销是什么？就是坐席拿着电话给客户打电话吗？no no no，让咱们一起走进京音平台之电销零碎。 京音平台2020年初开始建设，过来的两年多的工夫里，经验了跌宕起伏，有教训、有教训，整体来说平台经验了人工、自动化阶段，目前处于初步智能化阶段，心愿能够将过来的一些心路历程分享给大家，独特交换、共同进步。 二、平台介绍京音平台是集电销、企业微信等于一体的综合智能SCRM SAAS化零碎，反对多渠道治理、全客户生命周期治理、私域营销经营等次要性能，目前曾经有60+京东各业务线入驻，专一于为职场提供一站式的客户治理及一体化的私域经营服务。 1、业务架构京音平台次要包含电销和企微两类业务流程，为京东各业务线提供了营销获客->客户治理->跟进培养->量控频控->交易促成->客户触达->交易转化->业绩核算等能力，通过全流程的闭环性能让客户营销变得更简略更高效，应用自动化、智能化能力矩阵打造更懂用户的营销一体化平台。 2、能力地图电销零碎次要由营销获客能力、客户治理能力、跟进培养能力、量控频控能力、交易促成能力、客户触达能力、业绩匹配能力七大能力矩阵组成，七大能力串联、组合出可利用于各场景通用组件，例如人群筛选、人群散发、人群获客等客群类组件，短信触达、外呼触达等通信类组件，在提供稳固服务的同时兼容各类类似场景，晋升零碎组件化水平进而晋升麻利迭代品质及速度。 3、外围流程介绍上面让咱们一起看下电销零碎具体是如何获客，又是如何进行客户治理、如何进行危险管控、外呼性能矩阵以及关键技术架构是怎么样的。 •营销获客 营销获客又分成两大类：一是客户被动分割产生的获客，此类获客渠道的客户价值及转化率极高，但量级较低；二是客户行为或是平台行为产生的获客，此类获取渠道产生的客户量级较大，包含app获客、业务自有获客、客户浏览行为等获客形式，是平台次要获客起源。 •客户治理 获客后，联合零碎主动及人工手动辨认客户动向，将客户调配至适合的坐席，以此来进步潜在转化率，期间若客户动向或是坐席职责产生变更，能够将客户动静的调配至更适宜的坐席，也能够将为客户提供更好的服务。 外呼作业京音零碎为了帮忙各业务线降本增效，面向不同业务场景提供不同的外呼作业形式，例如催收场景的一句话外呼，人工场景的预测式外呼，智能化场景的三段一体外呼。 一句话外呼：例如白条到期须要简短的一句话揭示用户还款，能够将用户的脱敏信息方到语音中进而晋升用户信赖度。 预测式外呼：零碎自动化的对客户进行外呼，当客户接通后零碎再按事后配置好的规定将客户通话转接到人工坐席，经理论数据统计分析，每单通话均匀振铃等待时间为26.7秒，每天预测式外呼作业能够节俭大量人工期待时长。 三段一体外呼：三段一体外呼在预测式外呼的根底上减少了机器人坐席与客户沟通，在辨认到客户有动向后再转接到人工坐席，减少此步骤目标是进一步过滤掉接通了但无心向的客户，从而将人工坐席的价值最大化，三段一体外呼操作流程如下： 量控频控量控频控是京音平台平安经营的重要保障，包含事先防控、事中管控、预先监控三局部，基于规定引擎笼罩了拨打、通用配置化人群等场景，20+细分子类的量控频控规定，并反对面向不同业务线提供个性化、可定制的营销量控频控规定，顶层设计上，平台将平安生产视为第一红线，通过第一优先级的平台级量控频控策略进行宏观防控，躲避营销过程中产生的各种危险； 三、要害架构设计1、数据存储架构京音平台尽管是to b零碎，但也面临着比拟常见的挑战：数据量大、数据操作及更新频繁，数据存储架构经验了繁多mysql主从、繁多mysql主从备、垂直拆分mysql主从、垂直及程度拆分mysql+elasticsearch为主的混合数据架构模式，不同数据存储面向不同场景提供服务。mysql数据存储拆分示意图如下： 用于反对各类场景信息筛选的elasticsearch数据模型示意图如下： 2、数据异构架构下面形容了mysql+elasticsearch为主的混合存储架构面向不同业务场景提供服务，在大量数据流转压力下，会面临一些比拟麻烦的问题，例如数据一致性问题，elasticsearch tps及qps压力问题，上面聊聊京音如何解决这两类问题。 数据一致性问题咱们采纳最终一致性俩解决mysql到elasticsearch数据一致性问题，容许毫秒~秒级数据提早，elasticsearch自身就是一个准实时数据架构，不适宜实时场景应用。例如保留立即查问、防重等场景不适宜应用elasticsearch。 集群压力mysql的压力采纳的是比拟常见的基于业务特点做了垂直及程度拆分计划， 基于咱们的数据及软硬件配置，单库能够抗住2万qps及1万tps，16个库总qps为32万，总tps为16万，按每年25%业务增长，目前的mysql架构设计能够反对3年以上长期倒退。 elasticsearch集群也应用了相似mysql思维做了配置化的垂直拆分，在数据写入时按主维度对信息流做了合并，在京音的业务场景下，把一次事务的批量数据合并成一条数据写到elasticsearch，极大的升高了elasticsearch的写入频率，另外一些主键、切分键等适宜mysql查问的场景优先走mysql，充沛应用不同存储引擎的长处满足各类业务场景需要。 数据异构图如下：  四、小结通过以上三局部，整体的介绍了京音平台倒退的心路历程以及具体应用哪些能力矩阵撑持了业务高速倒退，并对其中的一些要害性能及技术架构进行了具体的阐明。心愿通过本文，能够帮忙大家对京音SCRM平台有进一步的意识，与此同时，京音SCRM平台之企微平台的建设计划分享也在飞奔而来的路上，敬请期待。

　在日常生产生存中，咱们常说，“平安第一”、“平安无小事”。围绕着平安问题，在各行各业都有对各类常见平安问题的解决方案和突发平安问题的应急预案。在互联网、软件开发畛域，咱们日常工作中对各类常见的平安问题又有哪些常见的解决方案呢？在此，联合经典架构图做一个梳理。　上面对数据存储、微服务接口、外网数据传输及 APP 层可能呈现的平安问题进行剖析，并给出一些常见的应答措施。　1 数据存储　为了保证数据存储的平安，对于敏感数据在进行存储时，须要进行加密存储，同时，敏感数据倡议在全公司进行收口治理，便于对立治理。对敏感数据进行加密存储时，常见的加密形式有可逆加密和不可逆加密，别离实用于不同的敏感数据。　1.1 可逆加密或对称加密　可逆加密，即通过对密文进行解密后，能把密文解密还原出明文。对称加密算法加密和解密用到的密钥是雷同的，这种加密形式加密速度十分快，适宜常常发送数据的场合，毛病是密钥的传输比拟麻烦。比方：网络购物的收货地址、姓名、手机号等就适宜用该加密形式，罕用的对称加密算法有 DES、AES，上面以 AES 为例阐明对称加密的过程。　在该加解密中，对于秘钥 K 的生成须要加解密单方独特制订并妥善保存。通常，咱们会把该秘钥 K 存储在须要应用加解密程序的过程内，便于在程序应用时间接进行应用。　1.2 不可逆加密　不可逆加密，即不须要解密出明文，如：用户的明码。不可逆加密罕用的算法有 RES、MD5 等，在此以 MD5 为例进行阐明。但大家都晓得，MD5 算法是存在碰撞的，即不同的明文通过 MD5 加密后，存在雷同的密文。因而，间接应用 MD5 对明码进行加密在生产上是不谨严的，通常还须要配合盐（salt）进行应用。对于盐的应用，也有肯定的技巧，一种盐值是固定的，即所有的明文在进行加密时都应用雷同的盐进行加密；另一种是联合具体的业务场景，用可变盐值，比方：就明码加密而言，能够把用户名的局部或全副作为盐值，和明码进行一起加密后存储。　2 微服务接口　微服务的平安，须要从申请鉴权和申请容量限度这 2 个方面来思考。对于申请鉴权，能够设置申请 IP 黑名单的形式，对该 IP 的所有申请或全副放行或全副回绝，该形式的粒度较粗。而如果要做得较细粒度一些，能够针对具体的 API 进行 token 鉴权，相比粗粒度该形式会管制得比拟精准。　除了对申请鉴权外，在理论的生产中，还能够对申请容量进行限度，对申请容量进行限度时，能够按 QPS 进行限度，也能够对每天的最大申请次数进行限度。在 jsf 平台治理端，能够对具体的办法进行申请的 QPS 限流。　3 数据传输　数据传输次要分为数据通过前端 APP 的申请，进入到服务网关前和进入服务网关后这俩局部，对于数据曾经进入服务网关后，这属于机房内的数据传输，通常这类加密意义不大，对这类的数据传输的平安须要建设相应的外部平安机制及流程标准，通过制度措施来保障。而数据在进入服务网关前，对数据的平安传输有哪些可做的。在数据申请进入服务网关前，通常咱们有基于 SSL 协定的传输加密以及当初广泛通用的 HTTPS 加密。　HTTPS 也是 HTTP 和 SSL 协定的结合体，所以在数据传输中，SSL 协定表演了至关重要的角色。那 SSL 协定的工作过程是怎么样的，他是怎么保障数据传输过程中的平安的呢？上面为大家解析一下 SSL 协定的工作过程。　SSL 客户端与 SSL 服务端验证的过程如下：　SSL 客户端向 SSL 服务端发送随机音讯 ClientHello 的同时把本人反对的 SSL 版本、加密算法、秘钥替换算法、MAC 算法等信息一并发送；　SSL 服务端收到 SSL 客户端的申请后，确定本次通信采纳的 SSL 版本及加密组件和 MAC 算法，并通过 ServerHello 发送给 SSL 客户端；　SSL 服务端将携带本人公钥信息的数字证书通过 Certificate 发送给 SSL 客户端；　SSL 服务端通过 ServerHelloDone 音讯告诉 SSL 客户端版本和加密组件协商完结，开始进行秘钥替换；　SSL 客户端验证 SSL 服务端发送的证书非法后，利用证书中的公钥加密随机数生成 ClientKeyExchange 发送给 SSL 服务端；　SSL 客户端发送 ChangeCipherSpec 音讯，告诉 SSL 服务端后续将用协商好的秘钥及加密组件和 MAC 值；　SSL 客户端计算已交互的握手音讯的 hash 值，利用协商好的秘钥和加密组件加密 hash 值，并通过 Finished 音讯发送给 SSL 服务端，SSL 服务端用雷同的办法计算已交互的 hash 值，并与 Finished 音讯进行比照，二者雷同且 MAC 值雷同，则秘钥和加密组件协商胜利；　同样地，SSL 服务端也通过 ChangeCipherSpec 音讯告诉客户端后续报文将采纳协商好的秘钥及加密组件和 MAC 算法；　SSL 服务端端计算已交互的握手音讯的 hash 值，利用协商好的秘钥和加密组件加密 hash 值，并通过 Finished 音讯发送给 SSL 客户，SSL 客户端用雷同的办法计算已交互的 hash 值，并与 Finished 音讯进行比照，二者雷同且 MAC 值雷同，则秘钥和加密组件协商胜利；　通过下面的这个交互过程，咱们能够看出，在应用 SSL 的过程中，除了客户端（浏览器）跟服务器之间的通信外，其余的任何第三方想要获取到协商的秘钥是比拟艰难的。即便有比拟厉害的人获取到了，基于目前用户在某个网站上的时效性，会影响咱们对应秘钥的时效性，因而，造成的破坏性也比拟无限。　4 APP　在 APP 层的平安问题，须要联合服务端一并来解决，在这次要介绍验证码这种模式。验证码作为一种人机辨认伎俩，其次要作用是辨别正常人操作还是机器的操作，拦挡歹意行为。以后互联网中，大多数零碎为了更好地提供服务，通常都须要用户进行注册。注册后，用户每次在应用零碎时须要进行登录，登录过程中，为了避免零碎非法应用，通常都须要用户进行登录操作，登录过程中，罕用的验证形式次要通过验证码进行验证，以后比拟罕用的验证码有以下几种类型。　4.1 短信验证码　目前用得比拟宽泛的一种验证码模式，输出无效的手机号后，零碎给手机号发送相应的短信验证码实现验证。　4.2 语音验证码　通过输出无效的手机号，零碎给手机号拨打电话后，用语音播报的形式实现验证码的验证。　4.3 图片验证码　较传统的验证码验证形式，由零碎给出验证码在页面显示，在进行页面提交时，验证码一并提交到零碎后盾验证。　4.4 语义验证码　比拟新鲜的一种验证码模式，然而该种形式相比较而言对用户不是特地敌对，须要慎用。　除了上述的几种目前罕用的验证码外，还有文本验证码、拼图验证码、问题类验证码等，在此就不再一一列举，大家如果感兴趣能够本人去搜寻、学习。　这次要从零碎的架构上，剖析了日常工作中咱们所接触到的比拟常见的一些平安问题及其应答措施，在理论工作的平安问题远不止这里提到的内容。心愿在日常工作中，咱们大家都绷紧平安的神经，时刻关注本人工作中的各类潜在的平安问题，争取把平安问题毁灭在零碎公布前。　5 参考文献　SSL 是如何加密传输的数据的：　名词解释：　SSL：（Secure Socket Layer，安全套接字层），位于牢靠的面向连贯的网络层协定和应用层协定之间的一种协定层。SSL 通过相互认证、应用数字签名确保完整性、应用加密确保私密性，从而实现客户端和服务器之间的平安通信。该协定由两层组成：SSL 记录协定和 SSL 握手协定。　HTTPS：（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以平安为指标的 HTTP 通道，简略讲是 HTTP 的平安版（HTTP+SSL）。即 HTTP 下退出 SSL 层，HTTPS 的平安根底是 SSL，因而加密的具体内容就须要 SSL。 ...

在日常生产生存中，咱们常说，“平安第一”、“平安无小事”。围绕着平安问题，在各行各业都有对各类常见平安问题的解决方案和突发平安问题的应急预案。在互联网、软件开发畛域，咱们日常工作中对各类常见的平安问题又有哪些常见的解决方案呢？在此，联合经典架构图做一个梳理。 上面，联合上述的经典架构图，对数据存储、微服务接口、外网数据传输及APP层可能呈现的平安问题进行剖析，并给出一些常见的应答措施。 1 数据存储 为了保证数据存储的平安，对于敏感数据在进行存储时，须要进行加密存储，同时，敏感数据倡议在全公司进行收口治理，便于对立治理。对敏感数据进行加密存储时，常见的加密形式有可逆加密和不可逆加密，别离实用于不同的敏感数据。 1.1 可逆加密或对称加密 可逆加密，即通过对密文进行解密后，能把密文解密还原出明文。对称加密算法加密和解密用到的密钥是雷同的，这种加密形式加密速度十分快，适宜常常发送数据的场合，毛病是密钥的传输比拟麻烦。比方：网络购物的收货地址、姓名、手机号等就适宜用该加密形式，罕用的对称加密算法有DES、AES，上面以AES为例阐明对称加密的过程。 在该加解密中，对于秘钥K的生成须要加解密单方独特制订并妥善保存。通常，咱们会把该秘钥K存储在须要应用加解密程序的过程内，便于在程序应用时间接进行应用。 1.2 不可逆加密 不可逆加密，即不须要解密出明文，如：用户的明码。不可逆加密罕用的算法有RES、MD5等，在此以MD5为例进行阐明。但大家都晓得，MD5算法是存在碰撞的，即不同的明文通过MD5加密后，存在雷同的密文。因而，间接应用MD5对明码进行加密在生产上是不谨严的，通常还须要配合盐（salt）进行应用。对于盐的应用，也有肯定的技巧，一种盐值是固定的，即所有的明文在进行加密时都应用雷同的盐进行加密；另一种是联合具体的业务场景，用可变盐值，比方：就明码加密而言，能够把用户名的局部或全副作为盐值，和明码进行一起加密后存储。 2 微服务接口 微服务的平安，须要从申请鉴权和申请容量限度这2个方面来思考。对于申请鉴权，能够设置申请IP黑名单的形式，对该IP的所有申请或全副放行或全副回绝，该形式的粒度较粗。而如果要做得较细粒度一些，能够针对具体的API进行token鉴权，相比粗粒度该形式会管制得比拟精准； <jsf:consumer id="setmentService" interface="com.jd.lfsp.jsf.service.SetmentService" protocol="jsf" alias="${jsf.consumer.alias}" timeout="${jsf.consumer.timeout}" retries="0"> <jsf:parameter key="token" value="${jsf.consumer.token}" hide="true" /></jsf:consumer>除了对申请鉴权外，在理论的生产中，还能够对申请容量进行限度，对申请容量进行限度时，能够按QPS进行限度，也能够对每天的最大申请次数进行限度。在jsf平台治理端，能够对具体的办法进行申请的QPS限流。 3 数据传输 数据传输次要分为数据通过前端APP的申请，进入到服务网关前和进入服务网关后这俩局部，对于数据曾经进入服务网关后，这属于机房内的数据传输，通常这类加密意义不大，对这类的数据传输的平安须要建设相应的外部平安机制及流程标准，通过制度措施来保障。而数据在进入服务网关前，对数据的平安传输有哪些可做的。在数据申请进入服务网关前，通常咱们有基于SSL协定的传输加密以及当初广泛通用的HTTPS加密。 HTTPS也是HTTP和SSL协定的结合体，所以在数据传输中，SSL协定表演了至关重要的角色。那SSL协定的工作过程是怎么样的，他是怎么保障数据传输过程中的平安的呢？上面为大家解析一下SSL协定的工作过程。 SSL客户端与SSL服务端验证的过程如下： SSL客户端向SSL服务端发送随机音讯ClientHello的同时把本人反对的SSL版本、加密算法、秘钥替换算法、MAC算法等信息一并发送；SSL服务端收到SSL客户端的申请后，确定本次通信采纳的SSL版本及加密组件和MAC算法，并通过ServerHello发送给SSL客户端；SSL服务端将携带本人公钥信息的数字证书通过Certificate发送给SSL客户端；SSL服务端通过ServerHelloDone音讯告诉SSL客户端版本和加密组件协商完结，开始进行秘钥替换；SSL客户端验证SSL服务端发送的证书非法后，利用证书中的公钥加密随机数生成ClientKeyExchange发送给SSL服务端；SSL客户端发送ChangeCipherSpec音讯，告诉SSL服务端后续将用协商好的秘钥及加密组件和MAC值；SSL客户端计算已交互的握手音讯的hash值，利用协商好的秘钥和加密组件加密hash值，并通过Finished音讯发送给SSL服务端，SSL服务端用雷同的办法计算已交互的hash值，并与Finished音讯进行比照，二者雷同且MAC值雷同，则秘钥和加密组件协商胜利；同样地，SSL服务端也通过ChangeCipherSpec音讯告诉客户端后续报文将采纳协商好的秘钥及加密组件和MAC算法；SSL服务端端计算已交互的握手音讯的hash值，利用协商好的秘钥和加密组件加密hash值，并通过Finished音讯发送给SSL客户，SSL客户端用雷同的办法计算已交互的hash值，并与Finished音讯进行比照，二者雷同且MAC值雷同，则秘钥和加密组件协商胜利；通过下面的这个交互过程，咱们能够看出，在应用SSL的过程中，除了客户端（浏览器）跟服务器之间的通信外，其余的任何第三方想要获取到协商的秘钥是比拟艰难的。即便有比拟厉害的人获取到了，基于目前用户在某个网站上的时效性，会影响咱们对应秘钥的时效性，因而，造成的破坏性也比拟无限。 4 APP 在APP层的平安问题，须要联合服务端一并来解决，在这次要介绍验证码这种模式。验证码作为一种人机辨认伎俩，其次要作用是辨别正常人操作还是机器的操作，拦挡歹意行为。以后互联网中，大多数零碎为了更好地提供服务，通常都须要用户进行注册。注册后，用户每次在应用零碎时须要进行登录，登录过程中，为了避免零碎非法应用，通常都须要用户进行登录操作，登录过程中，罕用的验证形式次要通过验证码进行验证，以后比拟罕用的验证码有以下几种类型。 4.1 短信验证码 目前用得比拟宽泛的一种验证码模式，输出无效的手机号后，零碎给手机号发送相应的短信验证码实现验证。 4.2 语音验证码 通过输出无效的手机号，零碎给手机号拨打电话后，用语音播报的形式实现验证码的验证。 4.3 图片验证码 较传统的验证码验证形式，由零碎给出验证码在页面显示，在进行页面提交时，验证码一并提交到零碎后盾验证。 4.4 语义验证码 比拟新鲜的一种验证码模式，然而该种形式相比较而言对用户不是特地敌对，须要慎用。 除了上述的几种目前罕用的验证码外，还有文本验证码、拼图验证码、问题类验证码等，在此就不再一一列举，大家如果感兴趣能够本人去搜寻、学习。 这次要从零碎的架构上，剖析了日常工作中咱们所接触到的比拟常见的一些平安问题及其应答措施，在理论工作的平安问题远不止这里提到的内容。心愿在日常工作中，咱们大家都绷紧平安的神经，时刻关注本人工作中的各类潜在的平安问题，争取把平安问题毁灭在零碎公布前。 5 参考文献 SSL是如何加密传输的数据的：[技术每日说] - SSL是如何加密传输的数据的! 名词解释： SSL：（Secure Socket Layer，安全套接字层），位于牢靠的面向连贯的网络层协定和应用层协定之间的一种协定层。SSL通过相互认证、应用数字签名确保完整性、应用加密确保私密性，从而实现客户端和服务器之间的平安通信。该协定由两层组成：SSL记录协定和SSL握手协定。HTTPS：（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以平安为指标的HTTP通道，简略讲是HTTP的平安版（HTTP+SSL）。即HTTP下退出SSL层，HTTPS的平安根底是SSL，因而加密的具体内容就须要SSL。 作者：廖宗雄

导读：百度APP内含有现金、流动、虚构等多类资产信息，散布于百度APP内各个业务线中，用户回访信息难度较高，且用户对百度资产认知度不高。我的钱包建设后，汇聚百度APP内所有用户资产信息，解决了用户回访难的问题，建设用户百度APP资产认知。本文次要介绍了钱包从0到1的搭建过程、遇到的各种问题以及相应的解决方案，旨在抛砖引玉，心愿能给读者带来思考和帮忙。 全文6082字，预计浏览工夫16分钟 一、背景百度APP坐拥日活2亿+、月活6亿+用户，在百度APP内每时每刻都产生了泛滥用户的资产信息。以后，百度APP内含有现金资产、流动资产、虚构资产等多类资产信息，散布于百度APP内各个业务线中。每个业务线提供用户独立的资产信息，业务线间关联性较低，用户回访信息难度较高，不利于造成用户对百度APP资产信息的整体认知。亟需一个零碎，可能汇聚百度APP内所有用户资产信息，反对用户资产信息对立汇总、展现，收拢用户回访入口，建设用户百度APP资产认知，晋升百度APP用户体验，我的钱包应运而生。 二、业务介绍百度APP集体中心里我的钱包，次要收拢了百度用户的资产信息，进行对立的治理、展现，同时收拢各个业务线资产查看、应用等能力的入口，便于用户疾速回访、找到集体的资产信息。钱包在百度APP集体核心外露四个金刚位和钱包入口地址，四个金刚位反对配置，经营人员可依据不同期间的流动、营销等配置不同外露业务方，便于用户快捷回访。同时四个金刚位反对业务数据外露展现，使用户直观感知集体的资产信息。 在钱包入口点击后，可进入钱包首页。首页中次要外露用户的现金、提现流动、返现、卡券、虚构币、快捷入口等信息，同时反对经营配置营销、流动。对于现金余额信息，咱们须要用户受权，用户受权后查问用户在度小满、百度闪付的余额，进入明细页面后，可别离进行受权、查看明细。针对流动提现金额，钱包推动百度APP内所有波及提现金额的业务接入钱包，对立进行治理，反对用户查看金额明细，其中金额明细中蕴含两个局部，一部分是明确返回用户余额信息的业务，反对用户点击跳转至具体业务方查看明细，另一部分是汇总百度提现核心全副业务，反对用户点击跳转，建设用户现金余额对立治理、拜访的认知。对于虚构币数据，可依据用户各个虚构币余额数量进行动静展现，便于用户疾速通晓本人的虚构币信息，点击具体虚构币时，反对跳转至业务方明细页面进行查看明细、充值等操作，也反对跳转至钱包对立虚构币明细列表，查看用户明细、月度汇总等信息。对于业务方接入，钱包提供多种接入形式：API数据同步、实时查问、配置跳转，业务方可依据本人理论状况进行抉择。 △图2-1 钱包展现 三、零碎业务架构 △图3-1 钱包业务架构图 钱包的整体零碎业务架构如上图3-1所示，钱包服务次要面向C端用户、业务接入方、经营人员。针对C端用户，钱包提供百度APP集体核心一级入口和钱包首页两个外围入口，前端应用talos框架实现。用户通过集体核心入口拜访达到逻辑层后，首先判断用户是否命中用户缓存，该缓存用来标识用户是否有资产，如果命中缓存且有资产，则读取数据缓存返回数据。用户通过钱包首页进入钱包，依据拜访的模块，路由适配器依据配置规定，抉择不同数据规定进行数据加载、获取，数据获取后按规定进行聚合返回。为了避免服务异样时影响页面渲染，提供异样兜底计划，业务方接口异样时应用缓存数据兜底，外部异样时对立返回兜底文案。 针对不同的业务方，咱们提供多种接入形式，对一个人核心一级入口外露业务，咱们提供推送、拉取机制，即业务方在用户数据变更时同步钱包，钱包准时拉取用户最新数据；对于钱包首页、列表页业务，咱们提供实时查问形式，对于利用钱包给业务内导流的业务，咱们反对H5、scheme、talos、端内等多种跳转能力。配置次要包含根底配置、扩大配置、流控配置， 实现不同的适配器供上游调用。 经营人员可应用B端经营工具，配置、批改接入的业务方信息，也能够治理钱包首页展现、经营流动、营销等，同时亦可配置相干的流控、监控等信息。底层服务，咱们应用了百度内通用的数据库、Redis、音讯队列、CDN等根底服务，该根底服务由对立的部门运维，稳定性比拟牢靠。 四、技术细节1、资产数据同步钱包搭建，面临着一个辣手的问题：百度APP内资产信息散布在不同业务线，信息间相互隔离，零碎异构。如果推动业务方间接裸露API查问数据，则须要业务方接口达到钱包要求的高QPS、底平响、高稳定性，同时业务线内可能存在一些非凡状况，再加上节假日、流动等非凡期间流量突增，会重大影响钱包数据展现，进而影响用户体验。存在局部业务方用户量级较小，但必须得提供合乎钱包须要的性能，这就对业务方带来额定压力。如果要求所有业务方将全量数据同步至钱包，又面临业务线数据推送、钱包海量数据存储、数据准确性对账等问题。 针对如上一系列问题，咱们确定了接入钱包的准则：①在集体核心破壳展现位外露的业务方，必须将资产数据同步至钱包，钱包服务外部确保接口可用性和降级计划；②钱包首页展现数据，反对业务方抉择是否将数据同步至钱包，如果不同步数据，须要提供满足QPS、平响等要求的API供钱包调用；③钱包二级页面、三级页面数据，需业务方提供查问API或者落地页，实时查问业务方数据进行展现，确保明细数据准确无误。 1.1 数据同步对于业务方同步的用户资产数据，咱们只存储用户的最新数据，思考数据量级问题，钱包不存储历史快照。钱包定义业务方数据推送的接口标准，业务方在数据更新时，需及时告诉钱包拉取最新数据。为了避免业务方推送数据时流量突增对钱包sever的影响以及进步钱包server的吞吐，引入音讯队列进行削锋，即接到业务方资产数据变更申请时，放入音讯队列后返回业务方告诉胜利，钱包server内生产队列音讯，依据配置信息向业务方拉取最新数据进行更新。对于用户资产明细数据，钱包定义接口标准，业务方实现后将调用地址提供给钱包，钱包进行配置，用户拜访时实时调用。 于是，咱们设计了如下的数据同步计划： △图4-1 业务方数据同步 ①用户资产变更时，业务方调用钱包接口告诉信息变更； ②钱包接到告诉后，放入音讯队列； ③生产工作获取音讯队列中音讯进行生产解决； ④依据配置，拉取业务方最新信息，更新至钱包存储； 在生产音讯时，钱包server进行批量解决，针对肯定工夫内同一业务方同一用户信息，只拉取一次数据，缩小对业务方服务压力。遇到异样时，会进行3次重试拉取。钱包server管制是否拉取、流控，在上游业务方服务异样时，可及时进行拉取、升高拉取流量，缩小或者去除上游系统对钱包的影响。 1.2 实时查问针对局部业务方不推送数据，咱们定义接口标准，业务方进行实现，实现后上报钱包配置调用形式。对于此类业务方，不容许配置到集体核心展现，避免业务方接口性能不达标连累整体用户体验。实时查问接口次要分为余额、分页明细接口，钱包对立format后进行展现。余额接口查问返回后，异步写入Redis进行缓存，用于下次访问业务接口异样时进行兜底展现，如果后续拜访业务接口失常，则应用最新数据更新Redis数据。 用户明细分页数据蕴含分页明细数据和月度汇总数据（月度总收入与总支出），钱包调用上游拆分成两个接口：分页明细接口和月度汇总接口，提供给前端展现页面封装成一个接口，升高前端交互复杂度。调用上游分页接口实时返回用户明细分页数据，月度汇总接口返回用户以后明细所属月份的汇总数据。钱包服务外部依据业务方明细分页接口数据进行汇总，为了缩小申请业务方次数，钱包外部判断分页数据，如果返回数据都是同一月份，则只申请业务方一次月度汇总接口，后续分页不再申请，如果返回数据扩散在两个月份，则申请业务方月度接口两次，如果返回数据扩散在三个月份（含）以上，则只申请起止两个月份的月度数据，两头月份数据由钱包依据明细数据外部计算。 2、多级缓存百度登录账号体系中，用户id已超过数十亿，存在资产的用户靠近亿级，同时钱包会在百度APP集体核心破壳展现局部业务，即一级入口，预计会带来均匀万级 QPS、峰值超过十万级 QPS流量，非凡工夫点可能会更高。为了避免服务宕机对百度APP产生非预期影响，故须要对破壳展现的数据提供残缺缓存计划和降级预案。为了晋升零碎的高吞吐，咱们决定将一级入口数据全副缓存至Redis，拜访流量只读Redis，如果遇到Redis异样时，则返回兜底数据，不查问DB（避免压垮DB）。DB数据用来Redis极其状况解体时复原Redis数据时应用。 针对存在资产的用户量剖析，进入集体核心的用户存在一个特点：大部分用户没有集体核心外露的资产数据，形象成一个稠密矩阵，这就使咱们在设计的时候，能够思考两层缓存：第一层判断用户是否领有资产信息，第二层缓存存储用户资产数据。故咱们设计了如下的两层缓存计划。 △图4-2 钱包两层缓存计划时序图 大部分用户流量会被第一层缓存拦挡，设计正当的第一层缓存数据构造，成为了零碎的一个要害。咱们调研了hyperLogLog、布隆过滤器、roaringBitmap等计划，剖析和试验后发现，hyperLogLog中pfadd操作自身能够满足性能要求，key的大小在12k也满足，然而因为pfadd自身针对于一个uid，只能操作一次，所以不适宜这个场景hyperLogLog；布隆过滤器在试验20亿的数据量下，内存占用来量大概占比3G，内存占用比拟大，基于redis的布隆过滤器没有分布式的数据能力，实质上还是对redis的强依赖，存在危险。 roaringBitmap在存储空间上满足要求，咱们依据钱包的理论场景，改良了分桶与计算规定，依据用户id进行sharding分桶，桶内应用uid的hash值对应的bitmap位点标记状态。试验数据验证，3000分片，8个计算单元，1000W试验数据，存储空间占用500M+，误判率2.14%，即存在2.14%的用户没有资产信息会打到第二层缓存，整体对第二层缓存减少压力可控。 3、读写拆散钱包服务承接较大的读流量和写流量，为了避免相互影响，咱们将读写流量别离拆到不同的服务。用户拜访读服务异样时，不影响业务方推送写入，业务方推送写入服务异样时，不影响C端用户拜访。读服务次要承接C端用户通过集体核心和钱包首页、二级页面拜访的流量，将用户拜访的相干数据进行缓存，晋升零碎平响。写服务次要承接业拉取业务方数据和C端用户受权信息，同时承接音讯队列生产解决和与上游业务方交互。读写服务之间，通过RPC接口调用进行交互。 △图4-3 读写拆散 4、数据统一集体核心外露的业务数据，针对接入用户核心外露展现的业务方，咱们须要业务方在用户资产产生变更时及时推送给钱包，以确保用户在钱包看到的数据与在业务方提供的入口查看的数据是雷同的。但理论状况不肯定如此，比方业务方推送服务异样、网络抖动，都有可能导致两方数据不统一。于是，咱们提出了推拉联合的数据一致性解决方案。即业务方资产信息变更时，准时推送钱包，在用户进入集体核心时，触发拉取用户最新资产信息。以后，咱们只对用户的资产信息已被推送至钱包的业务方，拉取用户最新资产信息，避免拉取全量业务方数据给用户量级小的业务方带来过多有效拉取流量导致服务压垮。针对零碎外部，因为展现时只应用Redis中缓存数据，如果同步用户信息时因某些异样导致Redis与DB中数据不统一，咱们采纳定时工作，每天凌晨拉取DB中前一天（DB变更工夫）有变更的用户信息，与Redis信息进行比对，数据不统一时，拉取业务方最新数据，更新Redis数据，做到T+1对账，解决零碎内数据不统一问题。 对于钱包内展现的业务方，也会存在服务异样、网络抖动导致的无奈获取用户最新信息的问题。咱们采纳的计划，对于失常申请业务方后果数据，将后果信息写入Redis，如果下次访问业务方接口异样时，应用Redis中数据作为兜底，优先确保数据失常展现。如果后续申请上游接口失常，则应用胜利的数据更新Redis数据，确保Redis数据的准实时性。 △图4-4 钱包数据统一计划时序图 5、配置化钱包设计之初，就面临着如何反对业务方疾速接入和反对经营人员疾速配置用户展现界面、流动、营销等信息的问题。通用配置化能力，是解决此类问题的首选计划。 配置化次要分为两局部：接入配置化和展现配置化。通过剖析发现，不同业务方的接入、展现需要不同，于是咱们形象独特的信息，生成通用根底信息，对于业务个性化信息，采纳扩大模型记录业务非凡配置。汇总业务方根底配置+扩大配置后，放入Redis缓存中。对于钱包展现配置，底层设计展现通用配置，比方展现名称、文案、跳转链接、图片Url、背景图Url，对于非凡展现需要，可配置到扩大信息，比方外露Icon、展现金额，配置信息同样放入Redis缓存中。 我的项目上线初期，配置信息新增与更改的频次都很高，容易产生批改谬误的危险，导致C端用户体验受损。于是咱们设计版本号+白名单计划进行放量管制，新版本公布需与白名单用户相关联，配置失效后先应用白名单用户线上进行验证，验证通过后逐渐全流量。批改配置时，保留历史更改全量数据，用于配置信息异样时回滚。 因为钱包对业务方配置信息依赖较强，如果Redis异样时会影响钱包的稳定性，所以咱们将配置信息同步配置到百度云控平台GCP中，作为Redis异样时的兜底。缓存有效期能够设置永恒无效，在变更配置时同步更新Redis，同时须要同步更新GCP配置，及时下发。 6、数据库设计因为用户量较大，波及用户资产信息到了数据库层面会同步放大，受限于MySQL数据库单机解决能力，故将数据进行拆分，不同的数据搁置在不同的机器，便于机器扩容。在数据模型的设计上，数据库分表字段采纳用户id作为分表字段（shardingKey），这样通过用户id定位到具体的库和表，因将整个资产信息库所有表依照对立规定进行切分，分表规定统一，保障依照同一用户都能在一个库，从而能够应用数据库事务。采纳分库分表模式，后续遇到数据库存储瓶颈时，能够很不便的进行横向扩容。 五、总结本文重点在介绍了百度APP集体钱包搭建的整个技术细节，在我的项目推动和落地的过程中，也遇到了诸多困难，次要的难点在零碎高可用、高稳固、疾速反对业务接入。梳理分明难点与技术关键点，抓住关键问题，对系统正当做减法，升高零碎复杂度，疾速推动零碎上线，后续一直迭代，打造极致用户体验。后续，在业务上会继续推动业务线疾速接入，让用户在钱包内能够查看、治理百度系全量资产信息，在技术上持续推动稳定性、可靠性建设，为业务方带来更多用户流量，为用户提供更好的用户体验。 ——————END—————— 举荐浏览：基于宽表的数据建模利用 百度评论中台的设计与摸索 基于模板配置的数据可视化平台 如何正确的评测视频画质 小程序启动性能优化实际 咱们是如何穿过低代码 “⽆⼈区”的：amis与爱速搭中的要害设计 挪动端异构运算技术-GPU OpenCL 编程（根底篇） 云原生赋能开发测试

简介：为了更好解决企业对前台工作效率、服务体验等诉求，阿里巴巴企业智能事业部联结阿里行政，推出的“非接触式服务”——云前台，集物品暂存、自助支付、物品长期借用、查问周边配套信息、一键呼叫视频客服、报销单收取等性能于一体。代替传统前台人员的高重复性的工作内容，实现无人化的根底服务反对，解决日常员工、访客在前台服务场景下遇到的各类问题。 古代企业前台服务个别会设置为2-3名工作人员，负责员工办公用品治理、来访客户接待、长期存放服务、各类日常征询等繁冗的内容，但受工夫、地点、内容上的限度，企业对人员投入产出比难以掂量。 为了更好解决企业对前台工作效率、服务体验等诉求，阿里巴巴企业智能事业部联结阿里行政，推出的“非接触式服务”——云前台，集物品暂存、自助支付、物品长期借用、查问周边配套信息、一键呼叫视频客服、报销单收取等性能于一体。代替传统前台人员的高重复性的工作内容，实现无人化的根底服务反对，解决日常员工、访客在前台服务场景下遇到的各类问题。 （往年云栖大会上云前台首次对外亮相，吸引少量观众体验互动） “云前台”是如何实现的？云前台依据不同的空间地位和不同应用对象，提供不同的服务。在实现平台化的根底上，提供通用的人脸识别服务和标准化接口，对接了阿里外部的多个零碎（包含报销、IT资产治理、内外小蜜智能助理、行政零碎等），并集成音视频会议能力和基于空间的智能报单、视频客服能力。 （云前台） 在多业务接入且业务流程不统一的状况下，提炼出了业务共性，设计了一套标准化的接入形式。在主流程的根底上，通过扩大点的形式，接入不同类型的扩大流程来提供不同的业务服务，各业务只需依据标准化标准自行接入即可。 云前台在硬件上接入菜鸟柜，每个格口定义惟一编号（A1、A2……），将物品寄存在柜中。员工通过刷脸、刷工牌、扫码、取件码几种形式进行身份验证，以实现物品存放取、物品借领用等服务。另外访客也可通过驿台驿阁自助实现物品的存放。 在保障前厅服务体验的前提下，目前云前台次要有以下几大性能亮点： 1、物品7*24自助服务员工通过云前台刷卡/扫脸，能够自助实现物品的存放取、借领用。领用还可依据物品品类的不同，设置是否须要身份认证。对于一些价值较高或限量领借的物品，如转接头、翻页笔等IT配件，可设置须要身份认证，认证实现后领借物品将自动记录到该员工名下，不便后续进行资产治理；而对于一些消耗性的日常用品，如本子、笔等办公行政用品、罕用药品等，则可搁置到按键式领用格中，一按即可支付，更加快捷。 与传统的人工前台相比，云前台通过人脸识别或工牌认证的形式，就能实现物品自助操作，不仅操作上更加方便快捷，还能享受7*24小时的服务，突破人工前台在服务时长上的限度，给员工带来了极大的便当。 2、报销单实现便捷提交以往在阿里员工须要通过特定地点的报销箱，实现报销单的投递工作。而当初，云前台上装置的红外扫码设施，代替了传统的扫码枪，并且买通了财务零碎接口，实现报销单状态信息同步。 当初，员工只须要将报销单的二维码放在红外设施下方一扫，即能实现报销单信息的录入零碎的工作。之后只需再将报销单投递进专门的柜子，期待工作人员收取即可。 3、反对人工征询/报障在日常应用环境下，如若遇到一些必须通过人工解决的问题，或是设施呈现故障的时候该怎么办呢？仔细的技术同学为云前台配置了音视频客服及问题报障性能。 在遇到一些非凡状况须要求助人工客服时，员工能够通过界面上的“视频客服”入口疾速与后盾人工客服取得联系，寻求相应帮忙。云前台接入了xspace工单零碎，与客服通话的过程中将主动唤起工单录入性能，在后盾生成服务工单，不便后续对应负责人跟进。 自助保障性能则和阿里的行政工作台买通，报障后零碎将依据问题给关联的技能组主动派单，同时也在xspace后盾生成工单，相干工作人员收到派单后会及时跟进问题的解决。 4、定制化周边配套举荐园区周边有什么好吃的店？出差同学能够抉择哪些酒店？可通过云前台的机器人端一键查问到，对于访客及差旅出行的人员来说，极大水平满足了他们对周边配套设施理解的需要。 缩小50%的行政人员投入，云前台扭转办公形式云前台自在阿里外部上线以来，目前已在40多个园区投放了超90台设施，笼罩10万+员工应用，均匀智能解决率达到了99%，根本能够满足同学们对日常前台服务的需要。 通过对云前台的布局，预计能够实现50%的人员优化，缩小近一半的人工投入，使行政人力从反复、琐碎的工作中开释了进去，同时也能冲破人工前台在服务工夫、地点、内容上的局限性。 随着企业数字化的降级，阿里巴巴在数字行政畛域也在继续一直地摸索和翻新。从疫情期间的员工入园管控零碎，到错峰就餐智能助理，再到云前台，通过数字化伎俩晋升行政团队的园区保障和治理能力，为员工发明新的服务体验，数字行政的将来可期。 原文链接本文为阿里云原创内容，未经容许不得转载。

案例背景打造一站式数字化办公平台，领有业内当先的门户、流程、集成、利用、开发等5大能力，助力“人财物事”全面数字化治理，让企业协同更集中，经营治理更高效。案例详情随着挪动互联网在近些年高速倒退，市场竞争也在日益加剧。业务和技术的疾速倒退，越来越多不同规格的企业在倒退过程中遇到了各种各样的问题。因而，应用OA办公系统对企业进行监管，谋求更加有序的办公条件，曾经成为事不宜迟。

近日，LiveVideoStackCon 2021 音视频技术大会北京站隆重召开。作为多媒体行业的技术盛会，泛滥行业专家齐聚在此，新技术、新产品、新趋势与新思维在这里碰撞交汇，一直催生出翻新冲破的新灵感。 网易云信服务端首席架构师吉奇受邀加入，并分享主题为《网易云信自研大规模传输网外围零碎架构分析》的演讲，介绍了网易云信寰球智能路由网络 WE-CAN 背地的设计理念，受到与会嘉宾宽泛关注。 WE-CAN——交融通信的基石WE-CAN 这个词，对于一些开发者略显生疏。简略了解，WE-CAN（Communications Acceleration Network）是一个架设在公共互联网上，通过对各种资源智能调度来实现进步数据传输品质、升高数据传输老本指标的简单网络系统。 吉奇示意，网易云信的指标是成为交融通信云服务第一品牌，而要实现这一指标，通信数据的传输品质至关重要，尤其在长距离、简单网络环境下。在这样的背景下，WE-CAN 诞生，并取得疾速倒退。   据吉奇介绍，目前 WE-CAN 能对流媒体进行高达到、低提早的传输，且 WE-CAN 能在媒体自身的各种 QoS 策略之外额定进行可选的、对业务通明的 ARQ、FEC 及其他冗余策略，这些策略对 WE-CAN 其余所有传输模式也通用； WE-CAN 也能对视频直播进行超大规模散发，通过门路级联和复用打消房间人数瓶颈，升高带宽老本，做到老本上靠近 CDN，实时性上靠近 RTC，更好地反对低提早直播场景； WE-CAN 还能对信令、IM或其余数据进行牢靠传输。所谓“牢靠传输”是指保证数据肯定能到，并且保证数据投递的程序性； WE-CAN 的服务和协定领有业界当先的解耦和分层设计，实现优雅，应用简略，形式灵便。例如其对牢靠传输协定进行了形象封装，对外提供了一个极简接口，咱们管它叫 MessageBus，MessageBus 的指标是提供一个寰球部署的分布式音讯队列服务。 作为网易云信的传输基座，WE-CAN 从一开始，定位就不是一般的传输网，而是建设一个能将任意数据从寰球任一点稳固、疾速、高效地发送到寰球任何其余角落的通用传输网络。 WE-CAN设计背地，分层至关重要“WE-CAN 的实现原理并不难，但要真正达到网易云信的设计指标，有很多工作要做。”吉奇与参会者分享道。 从整体而言最大的挑战就是如何放弃各层之间的形象和隔离，另外 WE-CAN 尽管最终目标是建设一个笼罩寰球的软件定义的通用传输网络，但出发点毕竟是为网易云信 RTC 服务的，所以与下层业务零碎的解耦也是一个很大的挑战。 本次分享中，吉奇也深刻分析了各层的架构设计。   之所以这么设计，吉奇示意，出于四方面的思考：一、WE-CAN 自身是公共互联网的 overlay，分层能更独立、更平安；二、分层可能实现各司其职、零碎边界清晰；三、分层可能更好的针对性优化，从而实现各层不同的传输优化策略；四、为了反对更多的传输场景。 实现过程中，WE-CAN 将整个架构分为五层，即网络层、管制层、传输层、应用层和业务层。 其中，网络层是 WE-CAN 核心网的入口，为报文提供寻址路由性能，是整个架构最简单、流程最长的一层。 管制层次要负责数据的路由、流量调度、拥塞管制。管制层会将转发节点编织为一张高速公路网，并为接入节点调配最优的高速公路入口。 传输层，负责报文的排序、重传、切片等，WE-CAN 基于 UDP 协定自研了一套牢靠的传输机制，可能反对更丰盛的利用场景，比方对应用层协定进行流量管制、熔断限流等，对应用层提供分级服务策略等。 应用层提供 Message Bus 的协定封装，包含 Topic 订阅、多目的地播送、承载 RTC 服务端信令等。 业务层反对 RTC、IM、直播点播、数据上报等各种利用，能无效升高业务提早，晋升通信品质的同时，降低成本。 如吉奇所说，彻底的分层解耦既能使各层独立工作互不影响，从而进步零碎稳定性，又能促成性能的疾速迭代，升高开发难度。另外，彻底的分层形象也使 WE-CAN 可能提供更灵便、更多元化的分级服务。这也是网易云信 WE-CAN 区别于很多厂商最大的不同。 ...

零碎思维简略地说，就是把某个疑难、某种情况或某个难题明确的视为一个零碎，也就是视为一组互相关联的实体。 零碎思维不等于系统化地思考。零碎是由一组实体和这些实体之间的关系所形成的汇合，其性能要大于这些实体各自的性能之和。一、 模式与性能零碎同时具备模式和性能这两个特色。模式讲的是零碎是什么，性能则是零碎做什么。二、实体及其模式与性能零碎是由一组实体所形成的。 确定如何将零碎初步合成为失当的实体用整体思维找出潜在的实体通过对重点的剖析，把注意力放到重要的实体上为实体创立形象定义零碎的边界，并将其与外界环境隔开三、确定实体间的关系关系的模式与性能 零碎是由实体及其关系组成的，关系能够依照特色分为两类：性能关系和模式关系。 性能关系，是指用来实现某件事情的实体之间所具备的关系，此关系可能波及实体之间对某物的操作、传输或替换。也称交互关系。 在交互过程中，相干的实体可能会替换操作数，也可能会协同对操作数执行操作。 例子：心脏与肺替换血液，某位团队成员与共事分享成绩。 模式关系，是某段时间内稳固存在或有可能稳固存在的实体之间所具备的关系。 例子：肺与心脏相连接，某人退出团队，这些都会形成模式关系。也称构造关系。内部接口 模式关系与性能关系能够逾越零碎边界。它们能够产生在零碎外部的实体与零碎外围环境中的实体之间。四、涌现涌现是指零碎在运作时所体现、出现或浮现的货色。 分为预期的涌现、意外的涌现。体现在性能、性能、可靠性、可维护性、可操作性、安全性和健壮性方面。