系统架构

<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 区别于很多厂商最大的不同。 ...

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

Design Review 是 TTM 过程中至关重要的一环，优秀的 Design review 不但能让技术方案的考虑更加周全，更多意义是避免潜在的线上 Bug 以及不必要的反复。 下面是我经常思考的一些问题，虽然不是每个项目都会涉及到这些点，而且也不应该被这些问题所局限，但作为一个参考，依然希望能给团队提供一个好的思考框架。 可用性外部依赖有哪些？如果这些外部依赖崩溃了我们有什么处理措施？我们 SLA 是什么？主要是指可用性目标几个 9? 50/90/99 分位数的响应时间是多少？QPS 是多少？我们的超时、重试、过载保护、服务降级机制是什么？如何避免雪崩我们的调用方有哪些？分别有什么服务配额？是否需要对关键的服务调用方单独部署？运维我们都有配置了哪些监控？如果出现问题，我们需要查看哪些信息？这些信息是否都有记录？报警的处理流程是什么？系统上线流程和步骤是什么，出了问题后是否可以回滚，以及怎么回滚？安全XSS，CSRF，SQL 注入这些是否需要处理？3 防怎么搞：防抓，防 DDOS，防恶意访问是否有请安全团队 review是否有风控的需求？信息存储时是否设计到密码、信用卡、身份证等敏感信息，这些信息是怎么存储和访问的？扩展性分层，分模块怎么拆分比较合理？拆分出来的模块可以搞成服务单独部署吗？应用层可以水平扩展吗？有用 session 吗？可以去掉 session 吗？如果系统的负载提升到以前的 3 到 10 倍，当前系统是否依然可用存储层面如果需要扩展存储怎么做？系统中有哪些上下依赖的节点 / 系统 / 服务？这些依赖是否会导致无法并行开发？能否去掉这些依赖？是否有数据访问 API? 数据 API 的设计对性能的考虑是什么？数据 API 对异常数据 (超大数据集、空数据集、错误数据、schema 异常...) 的处理是什么？存储数据计划怎么存储？会有可能的性能瓶颈吗？需要考虑一些缓存方案吗？有什么复杂 SQL 可能会导致慢查询吗？数据库的操作什么地方用了事务？什么情况会导致锁竞争？我们的锁策略是什么？一致性和可用性如何平衡？未来如果分库分表会有什么影响？缓存失效会有什么影响？缓存大量失效会有什么影响？冷启动有问题吗？有热点数据吗？多个缓存节点需要权衡可用性和一致性吗？存储时，是否需要分库，分表，选择的理由是什么？技术选型开发语言是什么，框架是什么为什么用他们？缓存用什么（tair/medis/redis/memached），web server 用什么？(nginx+php fpm/ apach php 扩展/jetty/tomcat/jboss)，消息队列用什么 (rebbitmq/beanstalk/kafka/mafka/metaq/notify)？为什么用它们？DB 是否可以用、以及用哪种 no sql (hbase/tair/mangodb/redis) 来优化？业界或者其他团队是否有处理过类似问题？他们是怎么处理的？是否可以 copy 或者借鉴？服务调用和服务治理请求同步处理还是异步队列处理比较好？服务接口的 URI 设计合理吗？可以向下兼容吗？服务间的调用协议是什么(dubbo/hsf/thrift) ？有公司标准的调用协议可以用吗(hession/protobuffer)？客户端和服务端的调用协议是什么(http/ws/私有)？有公司标准的调用协议可以用吗？有什么服务治理相关的要考虑的吗？能否接入 SLA 服务治理？业务监控正常的业务逻辑外，可能会有哪些奇葩或者恶意的操作？我们应该怎么处理？除了系统上的监控外，需要什么业务维度的监控吗？log 是怎么记的？如果要 debug 能有什么开关迅速打开吗？log 怎么 rotate？log 会影响性能吗？复用项目中有用什么新技术吗？为什么要用新技术？未来其他人接手容易吗？项目中有什么复杂计算的地方吗？这些计算可以用什么算法优化吗？这个项目可以抽象出来什么可以复用的东西吗？项目中的什么可以不用自己做，调用现成服务吗？测试新的系统设计是否容易独立测试兼容性新的系统是否和已有系统冲突，怎么融进去

写在前面打开 DDD 相关的书籍，你会被一系列生硬、高深的概念充斥，拜读完毕，满头雾水。这不是你的问题，而是 DDD 本身的问题，表现形式太概念化。学习它的内核，就不要被它给出的概念所迷惑，而要去思索这些概念背后所蕴含的设计原则，多问一些为什么，本质无外乎是 SOLID。最重要的，要学会运用设计原则去解决问题，而非所谓的 “设计规范”。 本文将会以系列解答的方式展开，由浅入深，篇幅不长，无妨一看。 啥是 DDD？本质上是一种方法论，提供了一套系统开发的设计方法。面对需要解决的问题，从复杂的现实中抽象出业务模型的思维方式与实践技巧。初衷是清晰设计思路，规范设计过程。 啥是驱动？DDD 强调是说得先把 “领域” 中涉及到的数据、流程、规则等都弄明白了，然后以面向对象的观点为其建立一个模型（即领域模型），而这个模型，决定了你将用什么技术、什么架构、什么平台来实现这个系统。所以技术在这个过程中是 “被动的”，是被 “选来” 实现 “领域模型” 的。对于项目的成败，技术不是决定性因素，领域模型是否符合事物的本质才是关键。 可以看出，领域驱动设计的出发点是业务导向，技术服务于业务。 我有误解？学习 DDD 有一些常见的误区。第一个要避免的就是，你必须要清楚，DDD 对于工程领域没有提出多么创新的技法，它更多是把前人在生产系统中用惯的技法归纳，总结，包装了一下。 我们来看一下 DDD 的初衷 —— DDD 抛开它晦涩的表达和术语，内核无外乎是 SOLID。书中的技法不是作者的发明创造或独门秘籍，而是当时业已存在并已在使用的做法，只不过没有被系统地加以记录 —— 换而言之，只要遵循 SOLID 的原则，这些所谓的概念技法完全可能在无意识的状态下自发出现在生产代码中。这些技法在各种大型系统被多次使用。换而言之，只要你接触足够多的代码、足够多的项目，必然会接触到这些 DDD 的实际应用。只不过在看过 DDD 一书之前，你可能意识不到这是一个成体系的设计手段。—— 如果你无法理解这样一个设计理论，看实际生产代码的应用场景是唯一真正有效的方法，毕竟设计理论本身就是从具体代码中总结出来的。即使你觉得自己懂了，抽象思维和开发经验也可能还未达到正确使用它的水平。它最大的价值在于对设计手段进行了有效的整理，形成了一个完整的系统设计规范，但过于晦涩和概念化的表述，也几乎消解了它对业界的贡献。啥时候用？你可能认为设计模式是一把 “瑞士军刀”，能够解决所有的设计问题，而实际上 “DDD 只是一把锤子”，有个谚语叫做 “如果你手里有一把锤子，那么所有的问题都变成了钉子”，如果你拿着 DDD 这把锤子到处去敲，要么东西被敲坏，要么就不起作用。 为什么说设计模式只是一把锤子呢？作者明确指出，DDD 只适合业务复杂度很大的场景，不适用于技术复杂性很大但业务领域复杂性很低的场景。可以看出，DDD 只专注一个领域，高复杂业务 —— 通过它可以为你的系统建立一个核心、稳定的领域模型，灵活、可扩展的架构。 DDD 是拥抱复杂的，拥抱变化的，但本身也是有成本有前提的；简单系统，没必要搞这么复杂，强上 DDD 就是一种反模式了。所以，当你遇到一个问题就想到 DDD 的时候，一定要注意 “DDD 只是一把锤子”，不要拿着这把锤子到处去敲！ 啥是复杂？如何判断业务是否复杂，判断依据不胜繁数。在我看来，没那么复杂，就两个： 宽度：链路广度大，关注多个纬度的消息来源，覆盖了较多的业务场景深度：链路深度深，关注对象整个的生命周期，从数据创建、到变更、再到后期运维，流程运转长只要满足其中一个，我认为就是复杂的。 具体解决啥？领域驱动设计并非 “银弹”，自然也不是解决所有疑难杂症的 “灵丹妙药”。在我看来，它只解决一个问题：过度耦合。 为啥会耦合？业务初期，系统功能大都非常简单，CRUD 就能满足，此时的系统是清晰的。随着业务的不断演化，系统的频繁迭代，代码逻辑变得越来越复杂，系统也越来越冗余。模块彼此关联，谁都很难说清模块的具体功能意图是啥；修改一个功能，往往光回溯该功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。 ...

摘要： ACE成长记是阿里云面向技术人推出的一个以记录ACE开发者通过阿里云平台获得的技术能力成长、技术视野扩展为主的内容栏目，初期每月一期，每期报道2~3位ACE成员。《ACE成长记》栏目说明 名词解释： 阿里云工程师，简称 ACE （Alibaba Cloud Engineer），代表云计算的爱好者，是最“王牌”（ACE）的一群开发者，也是未来的MVP。 ACE 是遍布在全国的开发者社群，作为国内优秀的开发者圈子，为所有开发者提供学习、交流的机会和平台。 ACE成长记是阿里云面向技术人推出的一个以记录ACE开发者通过阿里云平台获得的技术能力成长、技术视野扩展为主的内容栏目，初期每月一期，每期报道2~3位ACE成员。 每期会甄选出2~3位有一定代表性的开发者进行采访，在稿件里尽量还原被访人彼时与此时的心理状态、能力状态、思维状态，让我们看到一位开发者真实的成长记录。 被访人信息 邱登极限 东莞ACE同城会会长4年技术工作经验擅长Linux系统运维 VMware虚拟化 云安全领域姓邱，名登极限，父母期望他可以一直攀登高峰远望。 正文： 现在回想起来，若不是3年前的一次偶然机会了解到帝都IT人的工作状态，邱登极限那颗蠢蠢欲动的心可能被县城的安逸状态所磨灭。 生于湖南，求学于北京，工作于东莞，很多进入职场的人都会经历的一条城市迁移路线，同样被复制粘贴到了邱登极限身上。 北京的求学之路，被邱登极限认为是打开了他进入技术世界的大门。“尤其在大一时，在通过某种驱动得到了一台惠普 EliteBook 6930p，倒腾硬件.软件.操作系统就成了家常便饭。之后发展到自己捣鼓VMware虚拟机，安装Oracle、微软数据库等”。 90后的IT故事起于笔记本。而80后，在北京的中关村，深圳的华强北，广州的解放路盛行的PC DIY时代才是他们的IT训练场，东拆西拼笔记本是绝对不敢在DIY时代想做就能做的，贵啊！！！！ 一入IT深似海 每一代人都有自己时代的苦恼，但对于应届生来讲，苦恼比较相似。在高等教育被广泛普及后，每年6、7百万应届生涌入社会带来的就业压力一直被政府、媒体关注，似乎每一年都被称为“最难就业季”。 尤其在一线城市，房租基本会占去收入的1/3甚至更多，地铁里、公交车上，竟是批量的月光族在簇拥着。 在较大的生活压力和北方冬天寒冷逼人的自然环境下，邱登极限毕业不久回到老家衡阳，在本地一家事业单位做驻场运维工程师。“尽管每天上下班路上要花两个多小时，每月只有三千多元工资（2015年），但现在回头看，那段经历是我实践能力成长最快的时候，每天捣鼓的就是IBM P740P550小型机、华为刀片服务器、网络架构设计、VMware Esxi等，以前上学自己捣鼓的系统软件等都有了实战场地让我去练兵”。 对硬件与系统软件的热爱是从大学开始的，未曾想第一份工作就延续了大学的热爱，这个美好的开始让邱登极限充满了激情，自此开始了一入IT深似海的求知之路。我们都曾知道的CSDN、InfoQ、51CTO、ITpub、GitHub等IT社区就成了日常登录的地方，新吸收的知识不断在这份工作上得以验证，基础能力得到了扎实的沉淀。 白天像打了鸡血一样兴奋，但在上下班路上、拿到工资后的心情却很拧巴，对于刚入职场的邱登极限来讲他无法确定这个症结所在。 不过1年后一个偶然的机会让他找到了症结，原来偏居一隅的他与IT行业出现了隔膜，外边的IT行业大不一样。 再入一线城市 成为核心技术人 “这次对IT行业的了解给了我两个暴击，一是待遇，二是看到整个IT行业的技术发展正在快速向云转移，我之前做的工作处在前一个IT时代，脱节太多”，邱登极限认为对于一位刚毕业的年轻人来讲，必须要快速跟随潮流的发展，顺势才能快速成长。 从东莞开始的这份新工作，带领他进入了全新的世界，同时更坚定了自己的职业规划。如果用邱登极限自己的话来讲，就是“未来一定会继续围绕云的工作发展，整个产业就像农业向工业社会发展的路线，是不可逆的”。 然而从传统IT运维到云上运维，也带来了一些挑战，最明显的就是云上技术内容太多，涉及面很广，需要快速掌握并立即应用到具体业务中。为此邱登极限加强了对阿里云认证考试的学习。 据了解，很多阿里云上的企业用户，为提升企业内技术人员云技术能力，都会在内部开展“阿里云认证培训计划”，鼓励技术人员学习阿里云ACP、ACE等认证，在取得证书后给予学费报销的安排。 “我们公司也有这个计划，但没等政策公布，我就自费学了，还是希望能够早一些掌握新技术”。邱登极限回忆，为了考证，每天基本要花 2 ~ 3个小时学习，尤其大数据相关的证书，要做完所有实验，每个实验用时3~4个小时，这些是额外的压力。 尽管是额外的压力，但在取得多个认证后，邱登极限总结了3点最有意义的收获：一是对阿里云平台更熟悉，对云有更全面和系统的了解，对于搭建云架构等工作更有帮助；二是在服务客户时，认证是很有价值的筹码，“尤其我们服务的都是企业级客户，他们在竞标、后期服务保障时，都会要求技术人员有过硬的资质证明”；三是从自己的成长与发展看，在从事云技术工作时，这些证书起到加持作用，尤其阿里云的认证在业界认可度更高。 从传统IT运维，到成为云服务公司运维安全、运维开发核心人员，我想这也是对邱登极限过去3年持续学习最大的回报。谈到未来的职业规划，可以强烈感觉到他对云安全、专有云的渴望。 在工作的第4年，除了需要继续积累基础知识外，与更多同行交流、学习又成为邱登极限新的目标。 “人类毕竟是群居动物，即使我们通过云平台去操作，但依然需要面对面和同行交流，去和阿里的技术专家有更多接触，走到更前线的位置了解产业动态、技术实践内容”，邱登极限说，阿里云ACE同城会就是一个非常好的平台，在线上可通过钉钉群和全国各地技术人交流，在线下又能够面对面交流切磋技艺。 在成为阿里云ACE东莞同城会会长后，感觉自己多了一份责任，不仅要通过ACE组织将关注云技术的人聚合在一起，更重要的是自己要创造内容、创造机会带领ACE成员一同成长。 “虽然东莞地区的云计算产业不如深圳、广州，但我希望能够通过我们这些ACE之火，让云技术四处开花，用云技术带动更多传统产业、服务业的升级转型”。 本文作者：南霸天霸南北阅读原文 本文为云栖社区原创内容，未经允许不得转载。

IM系统设计实践

在线视频直播系统形式从内容和功能上具备的多样化为个人主播、企业都提供更多的流量变现机会，直播行业从某个方面来说既推动了智能手机性能发展，也推动了互联网市场发展方向。目前短视频直播模式掀起了全民直播的帷幕，社交领域融合的直播在线系统更多聚集在抢夺高流量IP资源上，根据下文我们来看看各个模式的发展趋势及其分析。网络视频直播平台，系统开发模式分析1、短视频手机直播系统形式从短视频发展而来的视频直播平台形式，允许用户使用手机进行直播，人人都可以成为视频直播平台传播者，拉开了全民直播的时代帷幕。采用在线直播系统形式，用户可以把自己的所见所闻实时传送到网络直播平台，以新鲜的内容抢夺眼球。另外，用户还可借助直播形式进行产品推广与宣传，吸引其他人前来消费，从而完成变现。2、网络直播平台企业争夺大流量IP竞争激烈在网络视频直播系统时代，各个参与者都将IP资源作为竞争重点。如今，互联网在越来越多的领域得到应用，其影响范围也逐步拓宽，“互联网+”行动进一步展开，成为互联网渗透作用的表现。随着发展，无论是投资者还是经营者，都越来越重视“个体”的重要性，而不是仅聚焦于行业层面。对进军网络视频直播平台领域的企业而言，现阶段最关心的就是怎样使自己的直播获得网民的认可与支持，提高用户黏度。因此，网络直播参与者之间的比拼，大都集中在对于IP资源的竞争上。以往，企业间的竞争焦点集中在客户资源的抢夺上，而在互联网时代下，企业间的较量则以IP资源为抢夺为主，对企业而言，要想在激烈的市场竞争中获得生存与发展的机会，就要采取有效措施，吸引更多用户的关注。在与IP资源的抢夺为主，对企业而言，要想在激烈的市场竞争中获得生存与发展的机会，就要采取有效措施，吸引更多用户的关注。在网上直播平台IP资源相关的竞争中，越来越多的人聚焦于以内容为中心开展运营的视频直播形式，与此同时，直播对参与者的要求并不高，为很多普通人提供了展示自身才华的平台。近年来，直播形式快速崛起，促使很多经营者将线上渠道作为自己的重要阵地，并将竞争重点放在网红经济与直播领域。视频直播+社交属性应用广泛1、在线视频直播系统具备的差异化优势与社交形式相比，活动直播系统具有显著的差异化特点，它能够有效缩短用户之间的距离，使彼此之间的交流更加顺畅。伴随着信息技术，尤其是互联网的高速发展，网络直播平台在社交领域的应用受到大批用户的追捧，并迅速推广开来。2、网络直播社交系统为企业助力随着直播软件应用范围的扩展，互联网巨头也认识到该领域的发展潜力，纷纷进军视频直播行业，促使更多企业聚焦于直播行业的发展。3、社交直播软件多元化趋势在移动互联网时代下、微信、微博等各类社交软件涌现在市场上，社交形式由传统模式下的单一走向多元，网络直播平台作为不同于传统模式的社交形式，可能颠覆传统的社交模式。这个并不是空穴来风，是已经形成当下互联网风口的，为什么这么多企业老板纷纷转行投入直播系统，就是看到里面的红利所在，想在风口赶来之前分一杯羹。网上直播系统打击传统图文传播方式网络直播系统形式能够使内容表现形式更为形象生动，传统模式下，图片与文字是内容传播的主要载体，相比之下，直播的优势身份突出，用户采用直播形式，不但可以实现基本的信息传递与推广，还能及时与对方进行互动，方便对后续的信息补充与说明。网络直播系统开发带来了行业持续性改革与升级为用户带来诸多便利，能够使用户从更加全面、直观的角度认识其他人或者对方推荐的产品。相比于传统模式下的单一的产品推广形式，视频直播方式允许互动双方根据现场情况进行实时问答，彼此之间可通过丰富的语言、手势乃至表情进行信息传递，使社交变得更加立体直观。原创文章作者：数商云，转载请标注来源

通过 上篇文章 的分析，我们已经明确了这个系统要干些什么。接下来的都是实打实的干货。这些内容认真阅读掌握后，相信你能够以此为基础设计一个维护性好、扩展性好的交易系统。数据库设计数据的设计是按照：交易、退款、日志 来设计的。对于上面说到的对账等功能并没有。这部分不难大家可以自行设计，按照上面讲到的思路。主要的表介绍如下：pay_transaction 记录所有的交易数据。pay_transaction_extension 记录每次向第三方发起交易时，生成的交易号pay_log_data 所有的日志数据，如：支付请求、退款请求、异步通知等pay_repeat_transaction 重复支付的数据pay_notify_app_log 通知应用程序的日志pay_refund 记录所有的退款数据具体的表结构：– ——————————————————- Table 创建支付流水表– —————————————————–CREATE TABLE IF NOT EXISTS pay_transaction ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, app_id VARCHAR(32) NOT NULL COMMENT ‘应用id’, pay_method_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付方式id，可以用来识别支付，如：支付宝、微信、Paypal等’, app_order_id VARCHAR(64) NOT NULL COMMENT ‘应用方订单号’, transaction_id VARCHAR(64) NOT NULL COMMENT ‘本次交易唯一id，整个支付系统唯一，生成他的原因主要是 order_id对于其它应用来说可能重复’, total_fee INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付金额，整数方式保存’, scale TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘金额对应的小数位数’, currency_code CHAR(3) NOT NULL DEFAULT ‘CNY’ COMMENT ‘交易的币种’, pay_channel VARCHAR(64) NOT NULL COMMENT ‘选择的支付渠道，比如：支付宝中的花呗、信用卡等’, expire_time INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘订单过期时间’, return_url VARCHAR(255) NOT NULL COMMENT ‘支付后跳转url’, notify_url VARCHAR(255) NOT NULL COMMENT ‘支付后，异步通知url’, email VARCHAR(64) NOT NULL COMMENT ‘用户的邮箱’, sing_type VARCHAR(10) NOT NULL DEFAULT ‘RSA’ COMMENT ‘采用的签方式：MD5 RSA RSA2 HASH-MAC等’, intput_charset CHAR(5) NOT NULL DEFAULT ‘UTF-8’ COMMENT ‘字符集编码方式’, payment_time INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘第三方支付成功的时间’, notify_time INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘收到异步通知的时间’, finish_time INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘通知上游系统的时间’, trade_no VARCHAR(64) NOT NULL COMMENT ‘第三方的流水号’, transaction_code VARCHAR(64) NOT NULL COMMENT ‘真实给第三方的交易code，异步通知的时候更新’, order_status TINYINT NOT NULL DEFAULT 0 COMMENT ‘0:等待支付，1:待付款完成， 2:完成支付，3:该笔交易已关闭，-1:支付失败’, create_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建时间’, update_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘更新时间’, create_ip INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建的ip，这可能是自己服务的ip’, update_ip INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘更新的ip’, PRIMARY KEY (id), UNIQUE INDEX uniq_tradid (transaction_id), INDEX idx_trade_no (trade_no), INDEX idx_ctime (create_at)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘发起支付的数据’;– ——————————————————- Table 交易扩展表– —————————————————–CREATE TABLE IF NOT EXISTS pay_transaction_extension ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, transaction_id VARCHAR(64) NOT NULL COMMENT ‘系统唯一交易id’, pay_method_id INT UNSIGNED NOT NULL DEFAULT 0, transaction_code VARCHAR(64) NOT NULL COMMENT ‘生成传输给第三方的订单号’, call_num TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘发起调用的次数’, extension_data TEXT NOT NULL COMMENT ‘扩展内容，需要保存：transaction_code 与 trade no 的映射关系，异步通知的时候填充’, create_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建时间’, create_ip INT UNSIGNED NOT NULL COMMENT ‘创建ip’, PRIMARY KEY (id), INDEX idx_trads (transaction_id, pay_status), UNIQUE INDEX uniq_code (transaction_code)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘交易扩展表’;– ——————————————————- Table 交易系统全部日志– —————————————————–CREATE TABLE IF NOT EXISTS pay_log_data ( id BIGINT UNSIGNED NOT NULL, app_id VARCHAR(32) NOT NULL COMMENT ‘应用id’, app_order_id VARCHAR(64) NOT NULL COMMENT ‘应用方订单号’, transaction_id VARCHAR(64) NOT NULL COMMENT ‘本次交易唯一id，整个支付系统唯一，生成他的原因主要是 order_id对于其它应用来说可能重复’, request_header TEXT NOT NULL COMMENT ‘请求的header 头’, request_params TEXT NOT NULL COMMENT ‘支付的请求参数’, log_type VARCHAR(10) NOT NULL COMMENT ‘日志类型，payment:支付; refund:退款; notify:异步通知; return:同步通知; query:查询’, create_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建时间’, create_ip INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建ip’, PRIMARY KEY (id), INDEX idx_tradt (transaction_id, log_type)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘交易日志表’;– ——————————————————- Table 重复支付的交易– —————————————————–CREATE TABLE IF NOT EXISTS pay_repeat_transaction ( id BIGINT UNSIGNED NOT NULL, app_id VARCHAR(32) NOT NULL COMMENT ‘应用的id’, transaction_id VARCHAR(64) NOT NULL COMMENT ‘系统唯一识别交易号’, transaction_code VARCHAR(64) NOT NULL COMMENT ‘支付成功时，该笔交易的 code’, trade_no VARCHAR(64) NOT NULL COMMENT ‘第三方对应的交易号’, pay_method_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付方式’, total_fee INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘交易金额’, scale TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘小数位数’, currency_code CHAR(3) NOT NULL DEFAULT ‘CNY’ COMMENT ‘支付选择的币种，CNY、HKD、USD等’, payment_time INT NOT NULL COMMENT ‘第三方交易时间’, repeat_type TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT ‘重复类型：1同渠道支付、2不同渠道支付’, repeat_status TINYINT UNSIGNED DEFAULT 0 COMMENT ‘处理状态,0:未处理；1:已处理’, create_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建时间’, update_at INT UNSIGNED NOT NULL COMMENT ‘更新时间’, PRIMARY KEY (id), INDEX idx_trad ( transaction_id), INDEX idx_method (pay_method_id), INDEX idx_time (create_at)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘记录重复支付’;– ——————————————————- Table 通知上游应用日志– —————————————————–CREATE TABLE IF NOT EXISTS pay_notify_app_log ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, app_id VARCHAR(32) NOT NULL COMMENT ‘应用id’, pay_method_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付方式’, transaction_id VARCHAR(64) NOT NULL COMMENT ‘交易号’, transaction_code VARCHAR(64) NOT NULL COMMENT ‘支付成功时，该笔交易的 code’, sign_type VARCHAR(10) NOT NULL DEFAULT ‘RSA’ COMMENT ‘采用的签名方式：MD5 RSA RSA2 HASH-MAC等’, input_charset CHAR(5) NOT NULL DEFAULT ‘UTF-8’, total_fee INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘涉及的金额，无小数’, scale TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘小数位数’, pay_channel VARCHAR(64) NOT NULL COMMENT ‘支付渠道’, trade_no VARCHAR(64) NOT NULL COMMENT ‘第三方交易号’, payment_time INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付时间’, notify_type VARCHAR(10) NOT NULL DEFAULT ‘paid’ COMMENT ‘通知类型，paid/refund/canceled’, notify_status VARCHAR(7) NOT NULL DEFAULT ‘INIT’ COMMENT ‘通知支付调用方结果；INIT:初始化，PENDING: 进行中； SUCCESS：成功； FAILED：失败’, create_at INT UNSIGNED NOT NULL DEFAULT 0, update_at INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (id), INDEX idx_trad (transaction_id), INDEX idx_app (app_id, notify_status) INDEX idx_time (create_at)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘支付调用方记录’;– ——————————————————- Table 退款– —————————————————–CREATE TABLE IF NOT EXISTS pay_refund ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, app_id VARCHAR(64) NOT NULL COMMENT ‘应用id’, app_refund_no VARCHAR(64) NOT NULL COMMENT ‘上游的退款id’, transaction_id VARCHAR(64) NOT NULL COMMENT ‘交易号’, trade_no VARCHAR(64) NOT NULL COMMENT ‘第三方交易号’, refund_no VARCHAR(64) NOT NULL COMMENT ‘支付平台生成的唯一退款单号’, pay_method_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘支付方式’, pay_channel VARCHAR(64) NOT NULL COMMENT ‘选择的支付渠道，比如：支付宝中的花呗、信用卡等’, refund_fee INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘退款金额’, scale TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘小数位数’, refund_reason VARCHAR(128) NOT NULL COMMENT ‘退款理由’, currency_code CHAR(3) NOT NULL DEFAULT ‘CNY’ COMMENT ‘币种，CNY USD HKD’, refund_type TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘退款类型；0:业务退款; 1:重复退款’, refund_method TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT ‘退款方式：1自动原路返回; 2人工打款’, refund_status TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘0未退款; 1退款处理中; 2退款成功; 3退款不成功’, create_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘创建时间’, update_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘更新时间’, create_ip INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘请求源ip’, update_ip INT UNSIGNED NOT NULL DEFAULT 0 COMMENT ‘请求源ip’, PRIMARY KEY (id), UNIQUE INDEX uniq_refno (refund_no), INDEX idx_trad (transaction_id), INDEX idx_status (refund_status), INDEX idx_ctime (create_at)),ENGINE = InnoDBDEFAULT CHARACTER SET = utf8mb4COMMENT = ‘退款记录’;表的使用逻辑进行下方简单描述：支付，首先需要记录请求日志到 pay_log_data中，然后生成交易数据记录到 pay_transaction与pay_transaction_extension 中。收到通知，记录数据到 pay_log_data 中，然后根据时支付的通知还是退款的通知，更新 pay_transaction 与 pay_refund 的状态。如果是重复支付需要记录数据到 pay_repeat_transaction 中。并且将需要通知应用的数据记录到 pay_notify_app_log，这张表相当于一个消息表，会有消费者会去消费其中的内容。退款 记录日志日志到 pay_log_data 中，然后记录数据到退款表中 pay_refund。当然这其中还有些细节，需要大家自己看了表结构，实际去思考一下该如何使用。如果有任何疑问欢迎到我们GitHub的项目（点击阅读原文）中留言，我们都会一一解答。这些表能够满足最基本的需求，其它内容可根据自己的需求进行扩张，比如：支持用户卡列表、退款走银行卡等。系统设计这部分主要说下系统该如何搭建，以及代码组织方式的建议。系统架构由于支付系统的安全性非常高，因此不建议将对应的入口直接暴露给用户可见。应该是在自己的应用系统中调用支付系统的接口来完成业务。另外系统对数据要求是：强一致性的。因此也没有缓存介入（当如缓存可以用来做报警，这不在本位范畴）。具体的实现，系统会使用两个域名，一个为内部使用，只有指定来源的ip能够访问固定功能（访问除通知外的其它功能）。另一个域名只能访问 notify return 两个路由。通过这种方式可以保证系统的安全。在数据库的使用上无论什么请求直接走 Master 库。这样保证数据的强一致。当然从库也是需要的。比如：账单、对账相关逻辑我们可以利用从库完成。代码设计不管想做什么最终都要用代码来实现。我们都知道需要可维护、可扩展的代码。那么具体到支付系统你会怎么做呢？我已支付为例说下我的代码结构设计思路。仅供参考。比如我要介入：微信、支付宝、招行 三家支付。我的代码结构图如下：用文字简单介绍下。我会将每一个第三方封装成： XXXGateway 类，内部是单纯的封装第三方接口，不管对方是 HTTP 请求还是 SOAP 请求，都在内部进行统一处理。另外有一层XXXProxy 来封装这些第三方提供的能力。这一层主要干两件事情：对传过来请求支付的数据进行个性化处理。对返回的结构进行统一处理返回上层统一的结构。当然根据特殊情况这里可以进行一切业务处理；通过上面的操作变化已经基本上被完全封装了。如果新增一个支付渠道。只需要增加：XXXGateway 与 XXXProxy。那么 Context 与 Server 有什么用呢？Server 内部封装了所有的业务逻辑，它提供接口给 action 或者其它 server 进行调用。而 Context 这一层存在的价值是处理 Proxy 层返回的错误。以及在这里进行报警相关的处理。上面的结构只是我的一个实践，欢迎大家讨论。本文描述的系统只是满足了最基本的支付需求。缺少相关的监控、报警。大家可以到我们的 GitHub主页留言 ...

本篇主要明确消息通知系统的概念和具体实现，包括数据库设计、技术方案、逻辑关系分析等。消息通知系统是一个比较复杂的系统，这里主要分析站内消息如何设计和实现。我们常见的消息推送渠道有以下几种：设备推送站内推送短信推送邮箱推送我们常见的站内通知有以下几种类别：公告 Announcement提醒 Remind资源订阅提醒「我关注的资源有更新、评论等事件时通知我」资源发布提醒「我发布的资源有评论、收藏等事件时通知我」系统提醒「平台会根据一些算法、规则等可能会对你的资源做一些事情，这时你会收到系统通知」私信 Mailbox以上三种消息有各自特点，实现也各不相同，其中「提醒」类通知是最复杂的，下面会详细讲。数据模型设计公告公告是指平台发送一条含有具体内容的消息，站内所有用户都能收到这条消息。方案一：【适合活跃用户在5万左右】 公告表「notify_announce」 表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //公告编号；senderID: {type: ‘string’, required: true} //发送者编号，通常为系统管理员；title: {type: ‘string’, required: true} //公告标题;content: {type: ’text’, required: true} //公告内容；createdAt: {type: ’timestamp’, required: true} //发送时间；用户公告表「notify_announce_user」 表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号；announceID: {type: ‘integer’} //公告编号；recipientID: {type: ‘string’, required: true} //接收用户编号；createdAt：{type: ’timestamp’, required: true} //拉取公告时间；state: {type: ‘integer’, required: true} //状态，已读|未读；readAt：{type: ’timestamp’, required: true} //阅读时间；平台发布一则公告之后，当用户登录的时候去拉取站内公告并插入notify_announce_user表，这样那些很久都没登陆的用户就没必要插入了。「首次拉取，根据用户的注册时间；否则根据notify_announce_user.createdAt即上一次拉取的时间节点获取公告」方案二：【适合活跃用户在百万-千万左右】 和方案一雷同，只是需要把notify_announce_user表进行哈希分表，需事先生成表：notify_announce_<hash(uid)>。 用户公告表「notify_announce_<hash(uid)>」 表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号；announceID: {type: ‘integer’} //公告编号；recipientID: {type: ‘string’, required: true} //接收用户编号；createdAt：{type: ’timestamp’, required: true} //拉取公告时间；state: {type: ‘integer’, required: true} //状态，已读|未读；readAt：{type: ’timestamp’, required: true} //阅读时间；提醒提醒是指「我的资源」或「我关注的资源」有新的动态产生时通知我。提醒的内容无非就是： 「someone do something in someone’s something」 「谁对一样属于谁的事物做了什么操作」 常见的提醒消息例子，如： XXX 关注了你 - 「这则属于资源发布提醒」 XXX 喜欢了你的文章 《消息通知系统模型设计》 - 「这则属于资源发布提醒」 你喜欢的文章《消息通知系统模型设计》有新的评论 - 「这则属于资源订阅提醒」 你的文章《消息通知系统模型设计》已被加入专题 《系统设计》 - 「这则属于系统提醒」 小明赞同了你的回答 XXXXXXXXX -「这则属于资源发布提醒」最后一个例子中包含了消息的生产者（小明），消息记录的行为（赞同），行为的对象（你的回答内容）分析提醒类消息的句子结构： someone = 动作发起者，标记为「sender」 do something = 对资源的操作，如：评论、喜欢、关注都属于一个动作，标记为「action」 something = 被作用对象，如：一篇文章，文章的评论等，标记为「object」 someone’s = 动作的目标对象或目标资源的所有者，标记为「objectOwner」总结：sender 和 objectOwner 就是网站的用户，object 就是网站资源，可能是一篇文章，一条文章的评论等等。action 就是动作，可以是赞、评论、收藏、关注、捐款等等。提醒设置提醒通常是可以在「设置-通知」里自定义配置的，用户可以选择性地「订阅」接收和不接收某类通知。呈现在界面上是这样的：通知设置我发布的 publish 文章 被 评论 是/否 通知我 被 收藏 是/否 通知我 被 点赞 是/否 通知我 被 喜欢 是/否 通知我 被 捐款 是/否 通知我我订阅的 follow 文章 有 更新 是/否 通知我 被 评论 是/否 通知我订阅一般系统默认是订阅了所有通知的。系统在给用户推送消息的时候必须查询通知「订阅」模块，以获取某一事件提醒消息应该推送到哪些用户。也就是说「事件」和「用户」之间有一个订阅关系。那么接下来我们分析下「订阅」有哪些关键元素： 比如我发布了一篇文章，那么我会订阅文章《XXX》的评论动作，所以文章《XXX》每被人评论了，就需要发送一则提醒告知我。分析得出以下关键元素：订阅者「subscriber」订阅的对象「object」订阅的动作「action」订阅对象和订阅者的关系「objectRelationship」什么是订阅的目标关系呢？ 拿知乎来说，比如我喜欢了一篇文章，我希望我订阅这篇文章的更新、评论动作。那这篇文章和我什么关系？不是所属关系，只是喜欢。objectRelationship = 我发布的，对应着 actions = [评论，收藏]objectRelationship = 我喜欢的，对应着 actions = [更新，评论]讲了那么多，现在来构建「提醒」的数据结构该吧！ 提醒表「notify_remind」 表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //主键；remindID: {type: ‘string’, required: true} //通知提醒编号；senderID: {type: ‘string’, required: true} //操作者的ID，三个0代表是系统发送的；senderName: {type: ‘string’, required: true} //操作者用户名；senderAction: {type: ‘string’, required: true} //操作者的动作，如：赞了、评论了、喜欢了、捐款了、收藏了；objectID: {type: ‘string’, required: true}, //目标对象ID；object: {type: ‘string’, required: false}, //目标对象内容或简介，比如：文章标题；objectType: {type: ‘string’, required: true} //被操作对象类型，如：人、文章、活动、视频等；recipientID: {type: ‘string’} //消息接收者；可能是对象的所有者或订阅者；message: {type: ’text’, required: true} //消息内容，由提醒模版生成，需要提前定义；createdAt：{type: ’timestamp’, required: true} //创建时间；status：{type: ‘integer’, required: false} //是否阅读，默认未读；readAt:{type: ’timestamp’, required: false} //阅读时间；假如：特朗普关注了金正恩，以下字段的值是这样的senderID = 特朗普的IDsenderName = 特朗普senderAction = 关注objectID = 金正恩的IDobject = 金正恩objectType = 人recipientID = 金正恩的IDmessage = 特朗普关注了金正恩这种情况objectID 和 recipientID是一样的。这里需要特别说下消息模版，模版由「对象」、「动作」和「对象关系」构成唯一性。通知提醒订阅表「notify_remind_subscribe」 表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //订阅ID；userID: {type: ‘string’, required: true}，//用户ID，对应 notify_remind 中的 recipientID；objectType: {type: ‘string’, required: true} //资源对象类型，如：文章、评论、视频、活动、用户；action: {type: ‘string’, required: true} //资源订阅动作，多个动作逗号分隔如: comment,like,post,update etc.objectRelationship: {type: ‘string’, required: true} //用户与资源的关系，用户发布的published，用户关注的followed；createdAt：{type: ’timestamp’, required: true} //创建时间；特别说下「objectRelationship」字段的作用，这个字段用来区分「消息模版」，为什么呢？因为同一个「资源对象」和「动作」会有两类订阅者，一类是该资源的Owner，另一类是该资源的Subscriber，这两类人收到的通知消息内容应该是不一样的。聚合假如我在抖音上发布了一个短视频，在我不在线的时候，被评论了1000遍，当我一上线的时候，应该是收到一千条消息，类似于：「* 评论了你的文章《XXX》」? 还是应该收到一条信息：「有1000个人评论了你的文章《XXX》」? 当然是后者更好些，要尽可能少的骚扰用户。消息推送是不是感觉有点晕了，还是先上一张消息通知的推送流程图吧： 订阅表一共有两张噢，一张是「通知订阅表」、另一张是用户对资源的「对象订阅表」。 具体实现就不多讲了，配合这张图，理解上面讲的应该不会有问题了。私信通常私信有这么几种需求：点到点：用户发给用户的站内信，系统发给用户的站内信。「1:1」点到多：系统发给多个用户的站内信，接收对象较少，而且接收对象无特殊共性。「1:N」点到面：系统发给用户组的站内信，接收对象同属于某用户组之类的共同属性。「1:N」点到全部：系统发给全站用户的站内信，接收对象为全部用户，通常为系统通知。「1:N」这里主要讲「点到点」的站内信。私信表「notify_mailbox」表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //编号；dialogueID: {type: ‘string’, required: true} //对话编号； senderID: {type: ‘string’, required: true} //发送者编号；recipientID: {type: ‘string’, required: true} //接收者编号；messageID: {type: ‘integer’, required: true} //私信内容ID；createdAt：{type: ’timestamp’, required: true} //发送时间；state: {type: ‘integer’, required: true} //状态，已读|未读；readAt：{type: ’timestamp’, required: true} //阅读时间；Inbox私信列表select * from notify_inbox where recipientID=“uid” order by createdAt desc对话列表select * from notify_inbox where dialogueID=“XXXXXXXXXXXX” and (recipientID=“uid” or senderID=“uid”) order by createdAt asc私信回复时，回复的是dialogueIDOutbox私信列表select * from notify_inbox where senderID=“uid” order by createdAt desc对话列表select * from notify_inbox where dialogueID=“XXXXXXXXXXXX” and (senderID=“uid” or recipientID=“uid”) order by createdAt asc私信内容表「notify_inbox_message」表结构如下：id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //编号；senderID: {type: ‘string’, required: true} //发送者编号；content: {type: ‘string’, required: true} //私信内容； createdAt：{type: ’timestamp’, required: true}参考消息系统设计与实现 通知系统设计 ...

2018刚过去，趁着春节放假对过去一年主导开发的项目做个梳理和总结项目背景平台运营到一定阶段，一定会累积大批量的用户数据，这些用户数据是运营人员的黄金财产。而如何利用用户的数据来做运营（消息推送、触达消息、优惠券发送、广告位等），正是精准运营系统需要解决的问题。本文是基于信贷业务实践后写出来的，其它行业如保险、电商、航旅、游戏等也可以参考。业务场景先看几个具有代表性的需求用户可用额度在20000～50000元，而且有借款记录，未还本金为0，性别为“男”用户发生了A行为且未还本金大于5000用户在1天内发生A行为次数大于等于3次用户在A行为前24小时内未发生B行为用户在A行为后一个月内未发生B行为业务上有两种消息类型日常消息：由业务人员通过条件筛选锁定用户群，定时或即时给批量用户发送消息或者优惠券触达消息：主要由用户自身的行为触发，比如登陆、进件申请、还款等，满足一定筛选条件实时给用户发送消息或优惠券对于用户筛选条件，也主要有两种类型用户状态：包括用户自身属性如性别、年龄、学历、收入等，还有用户相关联实体如进件订单、账户信息、还款计划、优惠券等的属性，以及用户画像数据如行为偏好、进件概率等用户行为：即用户的动作，包括登陆、进件申请、还款，甚至前端点击某个按钮、在某个文本框输入都算早期方案早期方案存在以下痛点至少两次跨部门沟通配合成本，周期被拉长非实时消息推送，无法实现基于用户行为的实时推送场景非实时效果验证，无法及时调整运营策略系统搭建的目标需要定义规则，提供可视化界面给业务人员动态配置，无需重启系统即使生效，减少沟通成本和避免重复开发，总之就是要更加 自动化 和 易配置采集实时数据，根据实时事件做实时推送，总之就是要 实时技术选型数据采集、转换、存储采集：状态类的数据主要放在各个业务系统的关系型数据库中，由于历史原因有postgres和mysql，需要实时采集表的数据变更，这里使用kafka connector读取mysql的binlog或postgres的xlog，另外还有标签系统计算出来的标签，在kafka中；而事件类数据主要来源于前端上报事件（有专门的服务接收再丢到kafka），关系型数据库里面也可以提取一些事件。转换：采集出来的数据需要做一些格式统一等操作，用kafka connector。存储：采用Elasticsearch存储用户数据，ES查询不像mysql或mongoDB用B-tree 或B+tree实现索引，而是使用bitset和skip list来处理联合索引，特别适合多字段的复杂查询条件。下面重点看下kafka connector和Elasticsearch如何使用kafka connectorkafka connector有Source和Sink两种组件，Source的作用是读取数据到kafka，这里用开源实现debezium来采集mysql的binlog和postgres的xlog。Sink的作用是从kafka读数据写到目标系统，这里自己研发一套组件，根据配置的规则将数据格式化再同步到ES。kafka connector有以下优点：提供大量开箱即用的插件，比如我们直接用debezium就能解决读取mysql和pg数据变更的问题伸缩性强，对于不同的connector可以配置不同数量的task，分配给不同的worker，，我们可以根据不同topic的流量大小来调节配置。容错性强，worker失败会把task迁移到其它worker上面使用rest接口进行配置，我们可以对其进行包装很方便地实现一套管理界面Elasticsearch对于状态数据，由于状态的写操作相对较少，我们采取嵌套文档的方式，将同个用户的相关实体数据都同步写入到同个文档，具体实现用painless脚本做局部更新操作。效果类似这样：{ “id”:123, “age”:30, “credit_line”:20000, “education”:“bachelor”, … “last_loan_applications”:{ “loan_id”:1234, “status”:“reject”, … } …}事件数据写入比较频繁，数据量比较多，我们使用父子文档的方式做关联，效果类似这样：{ “e_uid”:123, “e_name”:“loan_application”, “e_timestamp”:“2019-01-01 10:10:00” …}（e_前缀是为了防止同个index下同名字段冲突）ES这样存储一方面是方便做统计报表，另一方面跟用户筛选和触达有关。规则引擎在设计规则引擎前，我们对业界已有的规则引擎，主要包括Esper, Drools, Flink CEP，进行了初步调研。EsperEsper设计目标为CEP的轻量级解决方案，可以方便的嵌入服务中，提供CEP功能。优势:轻量级可嵌入开发，常用的CEP功能简单好用。EPL语法与SQL类似，学习成本较低。劣势:单机全内存方案，需要整合其他分布式和存储。以内存实现时间窗功能，无法支持较长跨度的时间窗。无法有效支持定时触达（如用户在浏览发生一段时间后触达条件判断）。DroolsDrools开始于规则引擎，后引入Drools Fusion模块提供CEP的功能。优势:功能较为完善，具有如系统监控、操作平台等功能。规则支持动态更新劣势:以内存实现时间窗功能，无法支持较长跨度的时间窗。无法有效支持定时触达（如用户在浏览发生一段时间后触达条件判断）。FlinkFlink 是一个流式系统，具有高吞吐低延迟的特点，Flink CEP是一套极具通用性、易于使用的实时流式事件处理方案。优势:继承了Flink高吞吐的特点事件支持存储到外部，可以支持较长跨度的时间窗。可以支持定时触达（用followedBy＋PartternTimeoutFunction实现）劣势:无法动态更新规则（痛点）自定义规则综上对比了几大开源规则引擎，发现都无法满足业务需求:业务方要求支持长时间窗口（n天甚至n个月，比如放款一个月后如果没产生还款事件就要发消息）动态更新规则，而且要可视化（无论用哪个规则引擎都需要包装，需要考虑二次开发成本）最终我们选择自己根据业务需要，开发基于json的自定义规则，规则类似下面例子：{ “batchId”: “xxxxxxxx”, //流水号，创建每条运营规则时生成 “type”: “trigger”, //usual “triggerEvent”: “login”, “after”: “2h”, //分钟m,小时h,天d,月M “pushRules”: [//支持同时推送多条不同类型的消息 { “pushType”: “sms”, //wx,app,coupon “channel”: “cl”, “content”: “hello #{userInfo.name}” }, { “pushType”: “coupon”, “couponId”: 1234 } ], “statusConditions”: [ { “name”: “and”, //逻辑条件，支持与(and)或(or)非(not) “conditions”: [ { “name”: “range”, “field”: “credit_line”, “left”: 2000, “right”: 10000, “includeLeft”: true, “includeRight”: false }, { “name”:“in”, “filed”:“education”, “values”:[“bachelor”,“master”] } ] } ], “eventConditions”: [ { “name”: “or”,//逻辑条件，支持与(and)或(or)非(not) “conditions”: [ { “name”: “event”, “function”: “count”, //聚合函数,目前只支持count “eventName”: “xxx_button_click”, “range”: { //聚合结果做判断 “left”: 1, “includeLeft”: true }, “timeWindow”: { “type”: “fixed”, //fixed为固定窗口，sliding为滑动窗口 “start”: “2019-01-01 01:01:01”, “end”: “2019-02-01 01:01:01” }, “conditions”: [ //event查询条件继承and逻辑条件，所以事件也可以过滤字段 { “name”: “equals”, “field”: “f1”, “value”: “v1” } ] } ] } ]}使用面向对象思维对过滤条件做抽象后，过滤条件继承关系如下：然后代码里加一层parser把Condition都转成ES查询语句，实现轻量级的业务规则配置功能。整体技术方案系统组成模块及功能如下：mysql binlog：mysql的数据变更，由kafka connector插件读取到kafka，数据源之一postgres xlog：pg的数据变更，由kafka connector插件读取到kafka，数据源之一report server：事件上报服务，数据源之一tags：用户画像系统计算出来的标签，数据源之一触发场景路由：分实时触发和延迟触发，实时触发直接到下一步，延迟触发基于 rabbitmq的延迟队列实现用户筛选模块：将筛选规则翻译为ES查询语句到ES查询用户数据，可以是批量的和单个用户的变量渲染模块：对推送内容做处理推送适配器：兼容不同的推送方式定时任务调度器：基于elastic-job，处理定时推送任务规则配置控制台：提供可视化配置界面（运营规则配置、数据采集规则配置、字段元数据配置等）报表服务：提供报表查询功能运营位服务：提供外部接口，根据条件匹配运营位（如启动图、首页banner图片等）总结与展望系统基本满足了目前的业务需求，对转化率等运营指标提升显著可以扩展其它业务，如推荐、风控、业务监控等规则定时拉取，实时性差，可以用zk做发布订阅实现即时更新目前事件的聚合函数只支持count，能满足业务需求但是未来可能还需要支持其它函数系统只经过千万级用户的生产验证，再高数量级的话可能还有很多性能优化的工作,如ES并行查询（目前用scroll api批量拉取用户数据是串行的）事件类数据越来越多，目前采取定时删除半年前数据的方式，防止持续增长过快不可控，所以事件类条件不可超过半年的时间窗口虽然系统对业务无入侵，但是反过来看本系统依赖于上游数据，上游数据发生变化时如何做到影响最小？未来会继续从技术及业务两方面入手，将系统建设的更加易用、高效。 ...

与分布式超级账本技术（如Hyperledger Fabric或R3 Corda）相比，以太坊区块链保持了相似性和差异性。在对区块链和分布式超级账本平台进行有根据的评估及其为企业带来的价值时，根据平台的核心功能和特征对平台进行分类是有用的。由于区块链源自密码学和数据配置的原则，某些功能可以在协调的数据库系统中复制，而其他功能仅在真正的区块链环境中可行。在本文中，我们将评估面向平台的主要企业的基本业务功能，包括以太网，Hyperledger Fabric和R3 Corda，无论是通过传统的分布式系统还是通过现代的区块链基础系统，都可以从软件获取其影响的位置以及系统的整体优化方式进行评估。图1：基础技术的划分特别是，我们将重点关注三个关键功能领域：数据协调——如何在利益相关者之间更好地分配和分配系统内的信息和信任。加密经济内部激励层——如何构建系统，以便基于经济激励来激励不同的利益相关者和用户，以确保系统的功能，例如。博弈论与机制设计。融入资产的数字商品化——系统如何融入数字商品经济。在一些名义上的特征中，这被称为代币经济。区块链的主要目标：企业希望通过这项技术实现什么目标？像以太坊这样的区块链与他们的分布式对手有类似的目标。确定企业希望使用区块链技术实现目标的目标可能是一种具有挑战性的方法，因为像1990年代的互联网一样，企业还不知道如何概念化强大工具的使用。类似地，今天已知区块链技术能够实例化各种功能，但是如何将这些功能构建到业务解决方案中需要对底层能力的进一步见解和评估。探索的三个主要轴：数据的处理和协调，可信和不可变记录以及资产的数字化。足够广泛，可以封装区块链的主要可用性，同时允许将这些功能进一步推断到业务场景中。通过讨论这三个方面，可以揭示商业实体为什么要使用该技术背后的含义。高效的信息处理和协调如果改进的分布式系统设计或数据库协调是协议或平台的唯一目的，那么区块链可能不一定是所需要的。区块链平台传统上促进了更好的数据协调和分布式共识机制的概念，其中数据通过技术平台得到促进和传递。虽然有用，但通过更好地协调中央数据库或改进的分布式系统设计，可以获得这些所需功能特征的重要部分。在此调查中，有必要确定平台和协议尝试优化现有数据协调功能与实施新区块链功能的程度。区块链的设计不仅仅是高级数据协调。产品和交易的不可变/可信记录关于我们为什么需要区块链的原始论文围绕着数字化信任的概念。ConsenSys的Andrew Keys推出的一个主题是“随着互联网导致信息数字化，区块链导致信任和协议的数字化。”这篇有意义的论文体现了区块链希望实现的精神，同时也为其铺平了道路。另一条路。附加变量是值的数字化。当值附加到系统中实现的信任时，某些对齐结构和激励机制将影响和激励系统内的正确行为，从而形成一个强大的平台。通常情况下，在设计系统时，不可变性与信任同义使用，即因为系统是不可变的，所以可信的是坏事不会逍遥法外。虽然在我们的平台协议评估中，重要的是还要评估可信系统如何实施的机制，以确保可以有益于平台用户的业务模型（通过加密经济学进一步探索）。资产数字化商品和资产的数字化被认为是大多数区块链或分布式账本平台的主要目标。如果企业正在寻找资产的数字化，则分布式分类帐或数据库协调能够提供一些功能，但应充分考虑这些数字商品的可访问性。因为协调数据库基本上是通过传统软件范例集中运行或分布在交易对手的一个或多个子组之间，所以数字化的级别可以基于数字化平台提供的自由度来限制。虽然数字化商品的概念听起来像一个简单的过程，但不同的激励动态和围绕商品如房地产，人类关注甚至电力等数字化的经济推理需要考虑哪种类型的平台将对数字化负责。供应商平台确实展示了“供应商锁定”的程度，并且在各种情况下依赖于集中管理的平台。如果依赖于封闭的专有系统，并且这些资产扩散到数字生态系统或市场，它们与经济激励层的相互作用水平相当有限，那么通过分布式分类帐系统也可以使用诸如标题系统和供应链等记录和注册表。如果基于封闭的轨道将会严重发育不良。充分利用开放市场能够提供的各种方面的自由市场系统对于在不断发展的数字生态系统中促进真正的数字商品是必要的。评估数据库协调特征数据库协调：特征虽然已经在不变性，安全性，可伸缩性，可管理性和性能等特性方面对这些平台的功能进行了深入分析，但通过了解构建体系结构的基础，可以确定更多内容。已经发明并实现了许多工具，用于在分布式系统内进行适当的数据协调。一个例子就是强调像Hadoop这样的工具以及这个生态系统中的各种集合，包括Spark，Hive和Zookeeper。对这些产品的依赖表明了分布式系统工具和协议的高度集成。进一步的相似之处可以在诸如Tendermint之类的协议中显示，这是一种BPFT共识引擎，其设计具有与Apache Zookeeper等工具类似的功能。在内部，还有一些event sourcing databases的研究，可以复制协调数据共享系统所需的几个功能。通过评估Apache Kafka等工具以及数据流服务如何在企业环境中实现显着的吞吐量水平，我们可以根据对这些数据库协调和优化的不同依赖程度划分区块链和分布式分类帐之间的功能差异。基础概念方面的工具。包括Plasma在内的以太坊的实现正在利用MapReduce等工具在UTXO和基于帐户的模型之上增强某些映射功能，同时还将组件简化为merkle证明，尽管重要的是要认识到协议的基础层仍然依赖于以太坊作为根区块链。通过分解这些细节，可以获得有关如何最好地评估这些软件平台的技术特征的进一步见解。数据协调：平台比较IBM Fabric通过深入研究Fabric架构，可以确定该平台已经创建了一个复杂的开发环境，专注于基于软件架构的详细配置实现卓越的吞吐量，以在分布式系统环境中实现最佳性能。客户端和分布式签署对等节点网络之间的链代码的移动以及交易机制和满足认可策略的收据的转移在封闭系统中是有效的，而在私有信道内传播交易的gossip（八卦）协议允许协调大数据集。虽然基础设施稳健且能力强，但应该考虑如何设计架构以允许多边协调结构的思考过程，其中最终可能存在难以管理的网络中涉及的通道因素。图2：Hyperledger Fabric架构此图演示了Fabric的一些体系结构配置，以及如何将组件组织到专为高级信息处理和最大事务吞吐量而设计的系统中。主要思想是渠道为在平台内移动交易提供了机会。 在查看体系结构时，订购服务节点（OSN）的功能用于记录Apache Kafka订购服务中的交易。在数据流生态系统中，Kafka是一个功能强大的工具，具有将各种形式的事务附加到单独的Kafka集群并最终分区的功能。在此设置中，数据能够跨群集分布，以形成分布式存储平台，该平台可以记录在其键/上下文中“状态”的Fabric定义内有时称为“块”或blob的数据结构/值存储配置。在该软件框架内承认的概念是该生态系统中的所有参与者和数据结构都是本机的，因为它们主要与该软件生态系统中的其他用户一起运行。图3：Apache Kafka资料来源：Apache KafkaFabric实际上采用了部署类型的子结构来部署某些散列链接数据存储，但应该认识到散列的配置不遵循从比特币或以太坊派生的区块链系统附属的原始架构设计。虽然数据blob被批处理并且经历传递事件以最终创建交易的哈希链接，但是必须理解该过程不一定将数据转换为系统状态的修改。相反，这些块的配置方式是信息存储在具有不同哈希实例的数据库类型结构中。在Fabric生态系统中，交付事件称为块，而链代码通过部署事件最终保护订购服务结构的链分区内的数据。该系统的数据结构和模块的配置能够允许分布式数据库体系结构所期望的事务吞吐量，尽管应该承认，资产代码协调仍然是一个尚未完全解决的挑战作为资产和价值的Fabric生态系统不一定具有可在分类帐内协调的数字表示。R3 CordaR3 Corda建立在一个不要求区块链的环境之上，而是一个分布式的数据库，利用各种形式的结构重构来构建一个主要由银行和其他机构用于其流程的系统。该平台大量借用比特币交易中使用的UTXO模型，其中状态由一系列输入和输出定义，输入的变化重新配置可以决定输出的状态。R3 Corda架构框架依赖于节点结构，该结构依赖于称为公证人的子模块，这些子模块有助于维护网络的有效性，类似于抽象共识功能的其他平台中的验证器结构。节点附带有关系数据库，这些数据库附加在数据结构中，允许使用SQL进行查询。交易通信在称为流的子协议中受到限制。这些流程与IBM Fabric中的通道体系结构相当，其中只有交易的各方能够访问信息。类经历转换，导致称为光纤或协同例程的状态机。该体系结构依赖于与子流通信的流以及与在平台范围内具有预定义功能的流库交互。此外，Corda中还有一个自包含的身份层，允许在整个网络中进行不同程度的访问控制。虽然R3 Corda公开声明它不打算成为区块链，但应该考虑到将分布式数据库的概念重新配置到去中心化数据库确实非常依赖于传统的数据库系统。虽然系统围绕新颖的数据结构和分布式系统如何组织的不同组成进行架构，但该平台确实考虑了数据分配，并且确实找到了各种方法来优化数据分发系统的功能。需要记住的一点是，由于系统仅限于特定体系结构范围内的数据协调的某些方面，因此，由于未对原始设计实施模块化和互操作性，因此牺牲了与实际区块链系统的集成。图4：R3 Corda工作流程图详细信息：Corda中的交易工作流以及如何通过系统移动输入状态和输出状态以及如何将文档附加到工作流过程中。以太坊以太坊生态系统由私人区块链和公共区块链生态系统组合而成。公共链没有任何接近数据协调上下文中描述的吞吐量和数据处理能力，因此不应基于这些能力进行评估。在评估以太坊的这一方面时，最有意义的是合成以太坊私有实例的网络拓扑的不同细微差别。以太坊黄皮书坚定地规定了关于构成以太坊的一系列规范以及代码库的技术细节。由于严格遵守该协议的蓝图，以太坊以及联盟实施的forks确实类似于构建该技术的原始基板。实际上，无论是在工作量证明，股权证明还是资产证明中，相同的规范都是连续的，因为协议被认为是相同的以太坊虚拟机（EVM）规范的后代。修改的体系结构仍与原始EVM明确校准。Quorum等平台的主要变化包括改变共识机制，修改全球根状态以适应私人和公共状态，改变Patricia Merkle tries 状态以及处理私人交易的其他模块。该架构允许该软件维护原始以太坊配置的沿袭和数据结构，同时通过更改提供增加的交易吞吐量。除了Quorum提供的改进的数据交易优化之外，通过Plasma，Truebit和Cosmos等工具协调和集成公共以太坊环境的能力为协议提供了额外的可扩展性。通过对像Plasma这样的工具的技术评估以及在Casper中获得共识的格式，很明显，MapReduce和Abstract Rewrite Systems等数据库管理工具将在以太坊中实现。在Plasma中，MapReduce是组装基于帐户的系统和多线设置的位图-UTXO承诺结构的协调的不可或缺的一部分。通过防欺诈机制设计和保真债券激励结构的组合，使用根链，等离子链和子链之间的相互作用的协调交易处理范例有助于满足块扣除和质量提取表面之间的动态。它还允许使用来自Casper或Truebit等系统的机制来填充进一步的加密经济结构，以便根据空间中普遍存在的数据可用性问题来镜像擦除编码中使用的概念。对于多链体系结构，以太坊将能够将分布式数据库系统的数据库协调和吞吐量功能与实际区块链的公共链兼容功能相结合。数据库协调：结论关于数据库协调能力范围的可行结论将是IBM拥有卓越的数据库管理工具集，因为依赖于传统数据库和分布式系统软件架构，基于整体单片设计和构建Fabric的大量资源密集型流程。R3 Corda还在进一步定义其功能，同时通过比特币协议私密重新配置细微差别，为银行和金融机构提供多种协调服务。Ethereum虽然是为公共链兼容性而设计的，但它没有IBM Fabric的原始数据库处理功能，尽管它在Fabric可用的企业用例的可伸缩性环境中确实具有某些协调原理图。以太坊和互补客户的私人实例可以作为构建更大系统的架构构建块，基于模块化设计，坚持相对基于unix的理念。与以太坊相关的代码库旨在与Fabric等数据库平台的交易吞吐量功能相媲美，同时允许Corda和Fabric中不存在的功能，但也可以跨平台探索互补关系。主要的区分因素可以从后续因素的评估中进一步阐明。区块链平台的加密经济配置软件平台内部的密码经济子系统需要各种机制设计和博弈论配置，以激励参与者以最佳方式行事，既有利于自身利益，又有利于生态系统。将区块链生态系统与分布式分类账设计的数据库系统区分开来的核心原则是能够将机制设计用作经济激励层，确保信任和合作的正确分配，使系统的行为方式有利于实现分散的共识。用户以及安全。依赖于“反向博弈论”设计的这些系统的主要目标是在子系统中创建主导策略，从而产生激励的均衡结构，进一步增强整个系统的整体完整性。密码经济机制设计的例子等离子和真实比特Plasma的设计旨在为以太坊网络带来可扩展性和多链功能。通过提供其上多个以太坊谱系的区块链可以相互通信的催化剂，Plasma充当私有区块链和公共区块链网络之间的可行桥梁。从进一步分析可以看出，Plasma为以太坊网络提供了可扩展性和可用性。虽然要了解等离子体的有效性，但了解等离子体设计的机制非常重要。通过所谓的欺诈证据实现了大量的互操作性。通过配置区块链，使得派生的子区块链（或子区块链）仍然可以基于MapReduce函数的计算可靠地验证事务，可以通过最小化的信任来实现可伸缩性。围绕等离子体设计了一种机制，以便在发现故障链时允许所谓的质量存在。这些与错误操作有关的情况与数据可用性的不一致和阻止预扣攻击有关。通过允许通过交替配置相互关联的链来惩罚邪恶活动的机制，生态系统希望实例化实体如何相互作用的内聚平衡。等离子体具有相当大的影响力，来自一个名为Truebit的密集加密经济激励结构的平台，旨在提高以太坊网络的离链计算能力。通过围绕验证游戏设计Truebit系统，其中整体共识机制的解决方案可以被验证者挑战，如果他们识别出一个邪恶的交易对手则获得奖励，创建系统的内部加密经济“检查和平衡”以激励占主导地位行为公平的策略。由于Plasma通过TrueBit的影响专注于创建多链互操作性网络，因此系统的内部实施对于实现信息和共识保真度至关重要。如下图所示，涉及Truebit并衍生到Plasma中的加密经济游戏包括求解器和挑战者之间的平衡相互作用，以验证最终在链上验证的计算的正确性。挑战者被激励不断挑战，因为强制错误可以保证如果正确解决支付。图5：加密经济设计以太坊Casper股权证明机制密码经济激励层的一个例子也可以在以太坊通过Casper的实现过渡到股权证明共识机制的证据中看到。虽然工作量证明有自己的内化游戏理论激励结构，以阻止参与者征用网络，但是向股权证明的过渡甚至还有进一步的内部结构，以阻止参与者在遇到货币时模仿或试图创建区块链的替代实例。staking协议创建了一个拜占庭容错环境，其中Ether将被绑定到共识机制中。这意味着个人将受到忠诚的约束，以在系统内表现得光荣。如果攻击者计划在共识机制中模仿或试图控制，那么与“slasher算法”相关的各种协议将破坏以太网持有者或攻击者的联系，因此惩罚他们的邪恶行为。在惩罚背后的机制设计中，被破坏的以太网的数量始终被编程为与攻击者希望获得的数量成比例，其中所达到的均衡是攻击者首先不想破坏系统的地方。Cosmos和TendermintCosmos还在建立一个依赖于Tendermint共识机制的生态系统，该机制在很大程度上依赖于拜占庭容错算法。该平台依赖于与比特币网络中的矿工具有类似角色的验证器。验证器具有称为Atoms的标记代币，用于通过依赖于绑定验证器生成的信任的股权证明机制来保护网络。生态系统中的参与者之间的相互作用也表示游戏理论结构，其中如果发现违反协议，验证者可能丢失其代币或授权给他们的代币。由于该系统内利益相关者的这种保税存款设计，共识机制允许一种保护网络的激励机制。此安全设计允许应用程序区块链接口（ABCI），区块链间通信协议（IBC）以及Cosmos集线器和区域之间的不同交互的正常运行。R3 Corda和IBM Fabric需要注意的一个重要注意事项是，R3 Corda和Hyperledger Fabric在其软件架构中没有实例化这些加密经济激励层。由于软件体系结构是基于分布式数据库聚焦范例进行基础设计的，因此它们最初并非设计用于在整个框架内结合本机加密货币层。由于软件设计的这种固有差异，它们尚未经过校准，无法参与多链生态系统，在这些生态系统中存在与多个区块链的互操作性和协调性。由于系统的结构考虑了最大吞吐量，因此基于这些系统的初始构建，忽略了包含公共区块链主网的区块链的可互操作网络拓扑的架构布局。为什么需要加密经济机制设计？人们可能会问为什么在软件设计中需要加密经济基础设施层。这种范式创造的是一个新的信任和不变性层，可以存在于计算环境中而不依赖于集中式实体。几十年来，我们一直在特定的客户端服务器和数据库架构中构建软件。像IBM，Intel和Oracle这样的公司已经完善了这个模型以及在初始创建之后创建的系统和子系统，这些模型仍然在分布式系统架构以及新标记的分布式分类帐系统中使用。虽然这些系统仍然集中在各个方面，无论是通过中央实体还是类似卡特尔的财团结构，其中激励措施是基于对集中实体的固有依赖而不是真正的激励结构来确保系统的正常运行。图6：客户端服务器模型去中心化系统允许在软件环境中实现某些目标的可行替代途径。在这种交换中突出显示的主要权衡是信任与执行。因为大型集中式系统更受信任，所以它被认为能够更好地执行。虽然区块链系统希望灌输的是系统的特征，在这种系统中，信任和价值可以在不依赖大型集中化实体的情况下重新分配。在系统设计的某些方面支持的一个想法是，为了优化系统，还必须对子系统进行子优化。这意味着必须协调和架构系统的协调，以便内部子系统在整个更大的生态系统中也具有利益或激励机制，以进一步实现合作目标。通过为整体环境的优化创建加密经济博弈理论方法，可以创建计算机科学和经济模型的汇合，从而允许创建可以在数字经济中设想的新软件架构。基于对数字经济的这种愿景，应该认识到，使用可以互操作的私有区块链和公共区块链的组合将创建一个可行的数字生态系统，在这个生态系统中可以出现各种商业和商业关系层，并在在传统技术配置中是可能的。融入区块链代币经济出于本次调查的目的，有必要定义标记化的概念。该概念借鉴了企业或实体能够根据我们生态系统中目前存在的某些数字标准创建各种形式的资产，商品和服务的可替代或非可替代表示的概念。虽然代币经济仍在发展，但重要的是区分第一波产品最初会有各种各样的失败和缺陷需要时间和迭代来完善。即使资产，金融产品，能源和数字注意力的标记化都是可行的商业模式，它们实施的确切动态需要额外的功能和访问层，只能随着时间的推移而改进。成功的代币经济将是由游戏理论机制设计和区块链创新中的重大发展和发现所创造的结果。正如Josh Stark关于加密经济学的文章所述，表现出最强可用性标志的标记是否构成了整体业务的经济学和博弈论设计中的必要组成部分。如果企业可以将其生态系统的各个方面数字化或标记化，那么可以创建的产品线将以指数方式扩展，超出我们传统的交换实物，金融资产，商品或技术服务的方式。通过创建标记化资产可以实现的数字媒体，重要的发展可以从新的生态系统发展而来。在观察区块链工具的生态系统时，很明显，以太坊实际上是可以建立代币经济的基础。如果代币经济模型能够结合私有区块链，可扩展性解决方案和ZK-Snarks等隐私工具的功能，数字资产的整体标记化将使我们的经济模型受限于当前的能力，因为组织可行性。实现区块链的业务目标为了实现区块链的上述业务目标，我们必须评估需要服务的各种途径。在概述详细说明所述模型的功能的图表时，以太坊能够为分布式数据库协调方案以及附加功能提供服务，而R3 Corda和IBM Fabric尚未选择触及这些功能层。在业务用例的背景下，我们覆盖了在现实世界业务场景之上讨论的不同功能，以更好地理解平台的功能。图7：功能摘要有效分配信息从功能上讲，从分布式系统的数据库协调和利用的角度来看，产品类似地匹配。事实上，R3 Corda，IBM Fabric和以太坊的企业版本具有分布式信息分配功能，可以通过不同的访问控制层和联盟的治理配置来促进信息的分配。虽然每个平台在其软件架构配置方面都不同，但每个平台都能够在有效的信息分配和协调上执行必要的性能。可信的不可变信息在大量这些技术的背景下，不变性在某种程度上被用作信任的同义概念。在评估不变性特征时，必须理解在利用基于Apache的数据流工具（如Kafka）的生态系统中，存在允许对数据进行读/写访问的固有功能。因此，由于系统设计中的一些选择，IBM Fabric的不变性方面有些受限。对于R3 Corda的基于UTXO模型的系统，不变性方面在系统的整体范围内保持不同。由于他们系统的整体分布式分类帐设计，他们已经建立了可以在整个平台上展示的某些信任方面。在以太坊上下文中建立的信任和不变性层都是在Patricia Merkle Tries的公共区块链派生状态根的子协议中概念化的。由于生态系统内核心软件范例的这种保留以及与公共链的可行连接，以太坊区块链和以太坊的相关推导能够充分证实不变性。随着资产开始数字化，从这种不变性获得的信任最终可以附加到新的价值体系。资产数字化应该认识到，IBM Fabric实际上能够在名义意义上创建数字资产，因为资产的数字化是从产品的注册表导出为数字格式的。虽然Fabric上资产的数字化会导致资产只能在使用Fabric的系统上运行。这相当于如果创建电子邮件客户端只能与使用完全相同的电子邮件客户端的人来回发送电子邮件，这与我们当前世界中存在的大量电子邮件客户端可以一起互操作的情况不同。R3 Corda具有类似的不一致性，因为R3平台的用户将被限制在其整体环境中与R3之外的其他平台进行交互，从而造成一些供应商锁定。因为R3 Corda主要关注银行客户，所以有可能有一个虽然应该注意平台的用户将仅限于使用R3 Corda的机构的银行业务关系，并且无法与不使用供应商平台的交易对手的生态系统无缝互操作。因为以太坊意味着充当类似于Web服务中的HTTP或TCP/IP的底层协议，所以对于只有一个以太坊应用程序的构建者，没有“供应商锁定”的概念。可以通过以太坊区块链的不同方面建立的信任允许全球资产的数字化，这种资产可以在新的经济体系内发生，而不像现有的那样。如果回头参考电子邮件示例，可以将以太坊协议视为与IMAP或POP3类似，作为访问电子邮件的通用协议。以太坊和以太坊派生的协议能够充当区块链基础设施，公司可以在此基础设施上构建数字资产。类似于每个公司在90年代后期使用HTML为网页搭建网站创建网站的方式，每家公司都能够使用以太网智能合约为其服务和产品创建数字经济，这些合约可以创建代币。可通过更广泛的网络访问。前方的路为了拥有足够强大的平台，可以与公共市场互动，系统必须能够满足业务需求，从而实现数据的有效处理，额外的信任分配层以及在发展中的数字经济中代表资产的能力。 很明显，所有三个平台都旨在通过技术进步和技术配置的不同途径实现类似的目标。在未来的道路上，我们必须考虑在这个发展中的生态系统中我们看到经济商业模式在哪里发展，显然基于以太坊的平台在真正融入数字经济方面具有优势，尽管在某些数据交易中存在明显的弱点IBM Fabric和R3 Corda可以擅长的吞吐量功能。由于不同的区块链和分布式账本平台被迭代并超越了我们当前技术时代精神所存在的能力，围绕哪个平台进行构建的决策将严重依赖于方向在我们的生态系统中的用例，我看到不同类型的用例相互分层。本文档的目的并不是说一个平台总体上比另一个平台更好，而是旨在规定这些平台本质上是彼此不同的。以太坊具有某些功能，分布式分类账（如Fabric和Corda）没有，而Fabric和Corda具有以太网目前无法达到相同程度的性能。为了真正实现我们现有系统所需的交互和可扩展性水平，必须在构建和设计协议时考虑所有交互，类似于首次设计互联网的方式。以太坊作为一种协议，能够充当基础技术堆栈，为广泛的生态系统提供服务，涵盖经济环境中的必要因素，但请记住，该平台目前尚未完成，也可能受益于某些固有的功能在DLT同行中。虽然前面的道路将包括尚未完善的技术，但应该检查协议是否最终会复制我们希望在下一代互联网中看到的功能程度，有时最明显的解决方案不是只关注一项技术。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是区块链与分布式超级帐本技术(Hyperledger Fabric或R3 Corda)

本文根据美团资深技术专家宋斌在ArchSummit架构师峰会上的演讲整理而成。背景美团外卖已经发展了五年，即时物流探索也经历了3年多的时间，业务从零孵化到初具规模，在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点：即时物流业务对故障和高延迟的容忍度极低，在业务复杂度提升的同时也要求系统具备分布式、可扩展、可容灾的能力。即时物流系统阶段性的逐步实施分布式系统的架构升级，最终解决了系统宕机的风险。围绕成本、效率、体验核心三要素，即时物流体系大量结合AI技术，从定价、ETA、调度、运力规划、运力干预、补贴、核算、语音交互、LBS挖掘、业务运维、指标监控等方面，业务突破结合架构升级，达到促规模、保体验、降成本的效果。本文主要介绍在美团即时物流分布式系统架构逐层演变的进展中，遇到的技术障碍和挑战：订单、骑手规模大，供需匹配过程的超大规模计算问题。遇到节假日或者恶劣天气，订单聚集效应，流量高峰是平常的十几倍。物流履约是线上连接线下的关键环节，故障容忍度极低，不能宕机，不能丢单，可用性要求极高。数据实时性、准确性要求高，对延迟、异常非常敏感。美团即时物流架构美团即时物流配送平台主要围绕三件事展开：一是面向用户提供履约的SLA，包括计算送达时间ETA、配送费定价等；二是在多目标（成本、效率、体验）优化的背景下，匹配最合适的骑手；三是提供骑手完整履约过程中的辅助决策，包括智能语音、路径推荐、到店提醒等。在一系列服务背后，是美团强大的技术体系的支持，并由此沉淀出的配送业务架构体系，基于架构构建的平台、算法、系统和服务。庞大的物流系统背后离不开分布式系统架构的支撑，而且这个架构更要保证高可用和高并发。分布式架构，是相对于集中式架构而言的一种架构体系。分布式架构适用CAP理论（Consistency 一致性，Availability 可用性，Partition Tolerance 分区容忍性）。在分布式架构中，一个服务部署在多个对等节点中，节点之间通过网络进行通信，多个节点共同组成服务集群来提供高可用、一致性的服务。早期，美团按照业务领域划分成多个垂直服务架构；随着业务的发展，从可用性的角度考虑做了分层服务架构。后来，业务发展越发复杂，从运维、质量等多个角度考量后，逐步演进到微服务架构。这里主要遵循了两个原则：不宜过早的进入到微服务架构的设计中，好的架构是演进出来的不是提前设计出来的。分布式系统实践上图是比较典型的美团技术体系下的分布式系统结构：依托了美团公共组件和服务，完成了分区扩容、容灾和监控的能力。前端流量会通过HLB来分发和负载均衡；在分区内，服务与服务会通过OCTO进行通信，提供服务注册、自动发现、负载均衡、容错、灰度发布等等服务。当然也可以通过消息队列进行通信，例如Kafka、RabbitMQ。在存储层使用Zebra来访问分布式数据库进行读写操作。利用CAT（美团开源的分布式监控系统）进行分布式业务及系统日志的采集、上报和监控。分布式缓存使用Squirrel+Cellar的组合。分布式任务调度则是通过Crane。在实践过程还要解决几个问题，比较典型的是集群的扩展性，有状态的集群可扩展性相对较差，无法快速扩容机器，无法缓解流量压力。同时，也会出现节点热点的问题，包括资源不均匀、CPU使用不均匀等等。首先，配送后台技术团队通过架构升级，将有状态节点变成无状态节点，通过并行计算的能力，让小的业务节点去分担计算压力，以此实现快速扩容。第二是要解决一致性的问题，对于既要写DB也要写缓存的场景，业务写缓存无法保障数据一致性，美团内部主要通过Databus来解决，Databus是一个高可用、低延时、高并发、保证数据一致性的数据库变更实时传输系统。通过Databus上游可以监控业务Binlog变更，通过管道将变更信息传递给ES和其他DB，或者是其他KV系统，利用Databus的高可用特性来保证数据最终是可以同步到其他系统中。第三是我们一直在花精力解决的事情，就是保障集群高可用，主要从三个方面来入手，事前较多的是做全链路压测评，估峰值容量；周期性的集群健康性检查；随机故障演练（服务、机器、组件）。事中做异常报警（性能、业务指标、可用性）；快速的故障定位（单机故障、集群故障、IDC故障、组件异常、服务异常）；故障前后的系统变更收集。事后重点做系统回滚；扩容、限流、熔断、降级；核武器兜底。单IDC的快速部署&容灾单IDC故障之后，入口服务做到故障识别，自动流量切换；单IDC的快速扩容，数据提前同步，服务提前部署，Ready之后打开入口流量；要求所有做数据同步、流量分发的服务，都具备自动故障检测、故障服务自动摘除；按照IDC为单位扩缩容的能力。多中心尝试美团IDC以分区为单位，存在资源满排，分区无法扩容。美团的方案是多个IDC组成虚拟中心，以中心为分区的单位；服务无差别的部署在中心内；中心容量不够，直接增加新的IDC来扩容容量。单元化尝试相比多中心来说，单元化是进行分区容灾和扩容的更优方案。关于流量路由，美团主要是根据业务特点，采用区域或城市进行路由。数据同步上，异地会出现延迟状况。SET容灾上要保证同本地或异地SET出现问题时，可以快速把SET切换到其他SET上来承担流量。智能物流的核心技术能力和平台沉淀机器学习平台，是一站式线下到线上的模型训练和算法应用平台。之所以构建这个平台，目的是要解决算法应用场景多，重复造轮子的矛盾问题，以及线上、线下数据质量不一致。如果流程不明确不连贯，会出现迭代效率低，特征、模型的应用上线部署出现数据质量等障碍问题。JARVIS是一个以稳定性保障为目标的智能化业务运维AIOps平台。主要用于处理系统故障时报警源很多，会有大量的重复报警，有效信息很容易被淹没等各种问题。此外，过往小规模分布式集群的运维故障主要靠人和经验来分析和定位，效率低下，处理速度慢，每次故障处理得到的预期不稳定，在有效性和及时性方面无法保证。所以需要AIOps平台来解决这些问题。未来的挑战经过复盘和Review之后，我们发现未来的挑战很大，微服务不再“微”了，业务复杂度提升之后，服务就会变得膨胀。其次，网状结构的服务集群，任何轻微的延迟，都可能导致的网络放大效应。另外复杂的服务拓扑，如何做到故障的快速定位和处理，这也是AIOps需要重点解决的难题。最后，就是单元化之后，从集群为单位的运维到以单元为单位的运维，业给美团业务部署能力带来很大的挑战。作者简介宋斌，美团资深技术专家，长期参与分布式系统架构、高并发系统稳定性保障相关工作。目前担任即时物流团队后台技术负责人。2013年加入美团，参与过美团外卖C端、即时物流体系从零搭建。现在带领团队负责调度、清结算、LBS、定价等业务系统、算法数据平台、稳定性保障平台等技术平台的研发和运维。最近重点关注AIOps方向，探索在高并发、分布式系统架构下，如何更好的做好系统稳定性保障。招聘信息美团配送技术团队诚招LBS领域、调度履约平台、结算平台、AIOps方向、机器学习平台、算法工程方向的资深技术专家和架构师。共建全行业最大的单一即时配送网络和平台，共同面对复杂业务和高并发流量的挑战，迎接配送业务全面智能化的时代。欢迎感兴趣的同学投送简历至 songbin@meituan.com，chencheng13@meituan.com。

前段时间分别用vue和react写了两个后台管理系统的模板vue-quasar-admin和3YAdmin。两个项目中都实现了基于RBAC的权限控制。因为本职工作是后端开发，比较清楚权限控制一个管理系统应该必须具备的核心功能，而且是可以做到通用的。打算写写关于管理系统前后端分离方面的文章，也是做一个知识的总结，其中会涉及到vue,react,node,.net core等方面的知识。术语描述用户(Subject)：发起操作的主体对象(Object)：指操作所针对的客体对象，比如文章或评论权限(Permission)：用来指代对某种对象的某一种操作，例如“添加文章的操作”权限码：权限的代号，例如用“ARTICLE_ADD”来指代“添加文章的操作”权限权限有时候也可以称为动作或者功能。比如“添加文章”，既可以认为它是一个动作，也可以认为它是一个功能。对象也可以称为资源。常用的权限模型ACL(Access Control List)(访问控制列表)DAC(Discretionary Access Control)(自主访问控制)MAC(Mandatory Access Control)(强制访问控制)RBAC(Role-Based Access Control)(基于角色的访问控制)ABAC(Attribute-Based Access Control)(基于属性的访问控制)ACL(Access Control List)(访问控制列表)ACL是最早也是最基本的一种访问控制机制，它是用来描述用户和权限之间关系的数据列表。它的原理非常简单：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD等操作。当试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。例如一个文件对象的 ACL 为 Alice: read,write; Bob: read，这代表 Alice 对该文件既能读又能写，而 Bob 只能读取。由于ACL的简单性，使得它几乎不需要任何基础设施就可以完成访问控制。但同时它的缺点也是很明显的，由于需要维护大量的访问权限列表，ACL在性能上有明显的缺陷。另外，对于拥有大量用户与众多资源的应用，管理访问控制列表本身就变成非常繁重的工作。最开始的ACL定义中，用户直接和权限挂钩，数据存储的是用户与权限的关联关系。如果两个用户的权限是一样的，那么就需要分别存储这两个用户与权限的关联关系，也是上面所提到的ACL的缺陷。为了解决这些问题，便有了对ACL设计的改进，相同权限的用户放到同一个分组里，分组与权限挂钩，不再是用户直接与权限挂钩。以及后来出现的RBAC(基于角色的访问控制)，角色与分组也是差不多的概念，角色直接与权限挂钩，用户再与角色进行关联。所以，现在一般说ACL,不再是用户直接和权限挂钩的一种权限控制模型，把它看做一个单纯的访问控制列表即可。列表里维护的可能是用户与权限的关系，也可以是用户组与权限的关系，也可以是角色与权限的关系，甚至是部门，职位等等于权限的关系。ACL是权限体系中的业务规则。RBAC等权限模型要用到ACL才能工作，ACL服务于RBAC等权限模型，其它权限控制体系里的权限规则也叫ACL。DAC(Discretionary Access Control)(自主访问控制)系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。因为用户能自主地将自己拥有的权限授予其他用户，所以DAC模型可以任意传递权限，用户能间接获得本不具有的访问权限，因此DAC模型的安全性较低，不能给系统充分的数据保护。DAC可以直接使用ACL的物理模型，区别在于，DAC模型中用户可以将自己具备的权限分配给其它用户(程序里的操作就是根据用户ID筛选出权限列表，根据列表为要分配权限的用户构造出新的权限列表并保存)DAC是传统的UNIX访问控制模型，也是Windows文件系统的访问控制模型。Windows的文件访问权限的设置中，除了用户，还有组。这个组与后面要说到的RABC模型的角色有什么区别呢？https://stackoverflow.com/questions/7770728/group-vs-role-any-real-difference我认为没必要去划分的太清楚，不管是组还是角色，都是为了更好的管理和分配权限在最原始的ACL模型上做的改进。如果有需要，甚至可以把权限分配到部门，职位上。MAC(Mandatory Access Control)(强制访问控制)MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。访问时，系统先对用户的访问许可级别和资源对象的密级进行比较，再决定用户是否可以访问资源对象。用户不能改变自身和资源对象的安全级别，只有系统管理员或管理程序才能 控制资源对象和用户的级别。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。MAC可以继续使用DAC的模型，但是要对用户进行等级划分，比如一级，二级，三级。。。，对对象资源也要做划分，比如机密，秘密和最高机密。用户访问的资源的时候，根据用户等级与资源访问级别来做判断，比如一级用户只能访问机密文件，如果访问的是最高机密文件，系统就会拒绝。这一系列规则是优先于DAC的，如果MAC与DAC混用，要先校验MAC再校验DAC。RBAC(Role-Based Access Control)(基于角色的访问控制)ACL的访问控制机制中，直接维护的是用户与功能的关系，这一系列的关系就是一个权限列表。当很多的用户具有相同功能权限的时候，就要进行繁琐的关联操作。RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联，权限列表维护的是角色与功能的关系。RBAC是目前使用最普遍的权限控制模型。当某些用户具备相同的权限的时候，只需要为这些用户建一个角色，把相应的功能关联到这个角色上，生成角色的权限列表。当有新的用户需要相同权限的时候，把用户关联到这个角色上即可。而当用检查或校验用户的操作权限的时候，查询用户所属角色的权限列表即可。当然，RBAC也不是完美的，比如想要为某个用户单独设置某个功能权限，可能需要为这个功能权限单独创建一个角色，然后把特定的用户关联到这个角色上。当想要移除某个用户的特定功能权限的时候，可能需要重新设置角色的功能权限，把特定功能权限从当前角色中移除，建立新的角色并关联特定的功能权限，然后再把新角色与相关的用户做关联(也可以直接在特定功能的程序里校验操作用户)这里说一个比较常见的RBAC的错误的用法：那就是直接使用角色做权限判断。比如只有角色A才能做文章的删除操作。function delPost(postId){ if(!isRole(‘A’)){ return false; }}如果需求该为角色B也可以删除文章。那就必须修改代码function delPost(postId){ if(!isRole(‘A’)&&!isRole(‘B’)){ return false; }}正确的做法应该是添加"删除文章"这个功能，把这个功能关联到相应的角色上。判断的时候是根据功能去判断而不是角色。function delPost(postId){ if(!hasPermission(‘POST_DEL’)){ return false; }}针对“只有角色A才能做文章的删除操作”这一需求，把这个删除功能关联到角色A上，然后把需要这个操作权限的用户加入到角色A中即可。当别的角色也需要这个操作权限，把功能关联到对应角色上即可，不需要再修改代码。在RBAC的核心基础上，还可以做相应的扩展，比如角色继承，角色分组之类的，这些扩展都是为了在一定程度简化权限管理工作。ABAC(Attribute-Based Access Control)(基于属性的权限控制)RBAC虽然是目前最普遍的权限控制模型。但是某些情况下，RBAC是无法满足并且也实现不了的。比如业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。这单单使用RBAC是无法实现。借助RBAC，可行的做法是，分地区创建角色，然后程序中根据角色做数据的过滤，这种做法缺点之前也提到过，需求变更的时候可能需要每次都修改代码。上面业务员查看订单的例子，地区是订单的一个属性，需求就是针对这个地区属性来做订单的查询范围的权限控制。这种权限控制方式就是ABAC(Attribute-Based Access Control)(基于属性的权限控制)，也被一些人称为是权限系统设计的未来。不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性是否满足某种条件来进行授权判断的（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。例如规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。ABAC非常的灵活，但是实现也是非常的难。这其中涉及到逻辑的动态执行，数据动态过滤等，更加具体就是动态拼接SQL语句(使用ORM的话就是动态组装对应ORM的查询语句)。感兴趣的可以在Github上搜索ABAC，看看不同语言是否已经有现成的解决方案。下面说说我学习到的一种实现方式：还是业务员查看订单的例子，在RBAC的基础上，扩展一个实体规则，订单就是实体，也就是针对订单设置一系列的规则。规则存储格式可以是json也可以是xml,甚至是Sql语句，能解析即可。比如北京地区这个规则：{ “regionId”:1}上海地区：{ “regionId”:3}regionId 就是系统里对应区域的Id,也是订单或订单相关表的某个字段。保存这个规则的时候，规则内容(就是上面的json),规则实体(也就是订单，表明这个规则是针对订单的)是必须的。也可以加上这个规则是适用增删改查中的一种或多种。创建好实体的规则，将规则与角色做关联，也就是将北京地区的规则关联到北京地区角色上，上海地区的规则关联到上海地区角色上。后端做权限校验的时候，还是先按RBAC模型的控制方式进行校验(是否具备订单查看权限)，然后根据当前操作对象(也就是实体)，取出用户所属角色关联的对应实体的规则。然后解析规则，动态拼接Sql或者ORM语句。没做地区限制(或没配置规则)的时候，Sql可能是select userId,orderNo,createdDate from T_Order配置了规则，解析拼接后可能就是select userId,orderNo,createdDate from T_Order where regionId=1这里是针对地区这个属性实现了动态的权限控制。实际开发过程中，要控制的东西是非常多了，查看字段的控制，数据范围的控制。要满足这些复杂的控制，需要制定一套完整的规则，以及针对规则编写相应的解析程序。比如根据配置的规则，最后解析出来可能是各种Sql语句:<,>,=,like,in,not in等等。可以看出，要真正的落地实现ABAC是多么的复杂。每次都要解析规则，对程序的性能也造成的影响，就算使用缓存，命中的概率也是非常的小，因为很多因素都是动态的。所以，如果需要根据属性做权限判断的场景不是很多的话，还是建议使用RBAC，然后程序中做判断比较省事省力。总结ACL早期定义中是一种权限控制机制，这种机制直接维护的是用户与功能的关系，功能就是针对对象定义的一些操作，比如增删改查的等。用户与功能的关系列表也称为权限列表或访问控制列表，现在说ACL，一般就是指这个权限列表或访问控制列表，但是里面维护的关系不一定是用户与功能的关系，在RBAC中维护的就是角色与功能的关系。RBAC在ACL的基础上加入了角色的概念，权限列表或访问控制列表里维护的不再是用户与功能的关系，而是角色与功能的关系。ACL可以和RBAC混着用，既可以在角色上设置权限，也可以直接给用户设置权限，更加灵活。借助角色的思想，可以在用户组，组织，职位等等上设置权限，以便更好的做好权限管理，也就是将权限设置从单一个体转移到某一类组合上。ABAC非常的灵活，也非常的难实现。参考文章权限系统设计模型分析Authorization Models: ACL, DAC, MAC, RBAC, ABAC ...