网站建设范文,python编程语言的特点,如何开发微信公众平台,工程建设信息网站接口前言说起支付平台#xff0c;支付宝量级的支付平台和一个小型公司的支付不可同日耳语。一个初创或刚创业一两年的公司#xff0c;一没人力#xff0c;二没财力的情况下#xff0c;如果也想对接支付那怎么办呢#xff1f;感谢支付宝和微信支付#xff0c;两大行业巨头提供… 前言说起支付平台支付宝量级的支付平台和一个小型公司的支付不可同日耳语。一个初创或刚创业一两年的公司一没人力二没财力的情况下如果也想对接支付那怎么办呢感谢支付宝和微信支付两大行业巨头提供了简单易用的方案简化了对接流程又能支持大部分银行。今天我们就来根据不同业务规模设计一个能经受业务考验的支付平台。第一阶段举个例子阿力空闲时间接了个外包的分销系统。业务模型如成为会员可以自动带二维码的分销海报扫描你二维码的人成为会员后你获得提成。这个例子有几个核心步骤申请会员支付成为会员自动生成海报计算分销提成。有点小挑战的自动生成海报。这个可以参考微信参数二维码接口和GDI绘制图片来搞定利用html5的canvas也能搞定。最核心的部分当然是支付。先来一张订单表流程图压压场面。订单模型前些天看领域驱动提到了核心域和子域那么整个交易流程是是这个模型的核心域订单表是交易流程的子域。我大概说下这些字段业务类型和业务id以及业务处理url实现了各个业务的解藕各个业务线都有自己的限界上下文。它可以根据取消日期和取消地址完成订单的取消动作可以根据支付平台交易id和支付平台查询对账。业务通知状态是用来综述通知业务处理是否成功。说完了订单让我们来看下整体交易流程。交易流程订单有三个主流程提交订单是用户主动触发支付回调是属于支付平台触发定时取消是后台任务根据设定的取消时间自动运行小业务可以不考虑订单取消问题。这样来说第一版支付中心就完成了。由于刚上线流量每天很少平稳了运行一段时间后也许会出现支付平台支付但搭建的支付中心却未支付只能手动修改数据库了并触发业务回调了这在最终一致性里可以成为人工补偿。后来不厌其烦加了个支付日志记录任何与支付平台交互的信息然后每隔一段时间扫描最近变更的日志表并和订单表对比发现不匹配的修复为已支付完美的解决了这个问题这在最终一致性里可概括为定时补偿。交易日志表老板缺少人手业务量又上升又对阿力解决问题的能力很欣赏就直接把阿力工资翻倍从原公司挖了过来。故事纯属虚构第二阶段刚过来新公司不久就接到了一笔融资然后新公司扩招了很多同事市场销售人一多产品线更多线上支付流量也加快起来。阿力信心满满觉得很有干劲。得意不久就遇到了服务线反馈的问题有客户重复支付需要退款。于是改订单清理数据财务退款临时解决了问题。后来次数多了手工处理及易出错就查询支付宝和微信的自动退款接口然后依赖日志表记录过支付成功对比判定重复支付发起退款引入了自动退款流程。交易流程补充自动退款流程然后又接到了一个线上客户需要抢购的需求每月有一天集中一起抢类似小米秒杀那样。然后到了激动的那天系统撑过了三分钟华丽丽的挂了熬了二十分钟才恢复正常。痛定思通支付中心进入重构优化阶段。由于公司人员扩张有时间和精力和能力去重购优化更健康的业务架构。一引入消息队列Rabbitmq支撑流量削峰。如支付回调先进消息队列由消息队列去通知业务。大幅度缩短单次请求处理时间提升兵法能力。二全面引入Redis缓存减小数据库访问压力部分关键业务表启用HttpRuntime缓存性能指数级提升。三引入专业调度工具quartz.net或hangfire。可以用来处理定时查询订单交易问题及退费问题。四购买商业.net监控平台如听云。检测程序性能。阿力跟随新公司技术体系也对支付中心实现了升级。支付平台回调通知后先转发到消息队列由消息队列来通知业务处理如失败后延时转发到消息队列继续执行最高重试5次然后发短信或邮件通知责任人。针对之前线上支付平台和自建平台不一致问题利用hangfire调度机制定时每天晚上拉取一周数据和支付平台核对。确保了两个异构系统的一致性。为防止支付平台同时通知造成两条支付日志先更新订单成功后在队列里用redis的incr和decr原子性操作来确保只能同时操作一个订单另一个通知延迟处理。数据库开启读写分离部署集群。经过阿力和同事们两个月的协力合作与加班加点新系统终于在那个客户第三次线上抢购前一段时间上线。经过线上抢购验证新的系统轻轻松松的抗过了抢购大家一片欢声笑语。阿力看到十几分钟XX百万的交易额惊呆了这真是金牌客户啊到了年底微信红包火热起来许多客户申请开通微信红包有家客户粉丝有二十多万发的钱也特别多。当时一到点十万人齐刷刷摇手机抢红包。最后重启了几遍应用程序池也不顶用。针对如此的流量我们应该怎么办呢每秒万级的请求暂时就不是小公司处理的来的况且这流量就过年才有像级了春运。人有那么多抢到红包的人是有限的。百分之九十五的人都是无效流量。那就取巧吧随机抽取一部分人的数据进入服务器其他的人就本地留存吧通过这种思路减少了一大部分流量。只考虑第一第二阶段的话上面关于支付中心的思考架构是完全可以满足交易量的。况且又有多少公司能迈向独角兽之路呢念天地之悠悠独怆然而泪下第三阶段上面那种方式虽然取巧针对特定业务本来就是抢红包大部分人都是无效的能说的过去假如是主业务流程有万级每秒甚至百万千万级每秒的请求量应该怎么办呢阿力陷入了迷茫。听说过dockerkuberneters为代表的容器编排听说过CI/CD自动部署听说过微服务的强大听说过负载均衡仿佛都是方向。大海跨不过陆地台风却能轻易穿梭大化为小繁化为简聚简成面规模化微服务也许才是解决巨量请求之道(故事纯属虚构不要代号入座)附录:最终一致性说完了解决中小型流量的问题我们来了解下一致性问题。1、关系型数据库事务追求ACID:A: Atomicity原子性C: Consistency一致性I: Isolation隔离性D: Durability持久性2、CAP帽子理论CConsistency一致性, 数据一致更新所有数据变动都是同步的AAvailability可用性, 好的响应性能完全的可用性指的是在任何故障模型下服务都会在有限的时间处理响应PPartition tolerance分区容错性可靠性帽子理论证明任何分布式系统只可同时满足二点没法三者兼顾3、Base模型:BABasically Available基本可用SSoft State软状态状态可以有一段时间不同步EEventually Consistent最终一致最终数据是一致的就可以了而不是时时保持强一致利用查询模式补偿模式异步确保模式定时校对模式等可实现分布式系统最终一致性。最终一致性更详细用法参考李艳鹏老师关于分布式一致性的讲解。https://www.jianshu.com/p/1156151e20c8?fromsinglemessageisappinstalled0后言阿力解决了支付中心的稳定问题后就买了许多书看到了上面关于最终一致性的陈述时心里想到这些都是我已经实现了的原来还有这么多头头道道阿力又看到了领域驱动设计等书感慨支付领域模型真是学习领域驱动设计的最好实践。它具有独立的限界上下文通过回调url和其他业务限界上下文沟通。最后再用交易流程在做个总结吧交易流程关键点:1.回调部分有消息队列通知并支持失败重试。2.每天晚上定时拉取支付平台对象记录核账保证最终一致性。3.支付平台回调时根据支付日志判定是否重复支付重复支付的发起自动退款。源码计划用.netcore按领域驱动的方式完成以上设计。日期未定。声明全文除附录部分最终一致性外均为原创。如文章能给你带来帮助请点下推荐感谢支持。相关文章ICanPay 统一支付网关ASP.NET Core 2.0 使用支付宝PC网站支付ASP.NET Core Web 支付功能接入 微信-扫码支付篇微信和支付宝支付模式详解及实现.Net标准库原文链接https://www.cnblogs.com/fancunwei/p/9612567.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
