Mobabel Blog

[转]支付系统 0

[转]支付系统

支付系统 概述 支付系统是连接消费者、商家(或平台)和金融机构的桥梁,管理支付数据,调用第三方支付平台接口,记录支付信息(对应订单号,支付金额等),金额对账等功能,根据不同公司对于支付业务的定位不同大概有几个阶段:第一阶段:支付作为一个(封闭)的、独立的应用系统,为各系统提供支付功能支持。一般来说,这个系统仅限于为公司内部的业务提供支付支持,并且和业务紧密耦合。第二阶段:支付作为一个开发的系统,为公司内外部系统、各种业务提供支付服务,支付服务本身应该是和具体的业务解耦合。 支付是电商系统中核心 我们先来看一下用户完成一次购物需要进行那些操作: 通常消费者在手机APP或者网站都会涉及到支付相关的业务场景,用户只需要简单点击支付按钮输入支付密码,就可以完成整个支付过程,那么我就和大家一起来看看一个完整的支付系统有什么功能组成和设计时需要考虑那些问题。 01 支付系统的作用 从上图中我们可以看出真实的资金流向。首先当用户产生支付行为时,资金从用户端流向支付系统,退款时则相反,从支付系统回流至用户端。因此在整个交易过程中用户端与支付系统是双向资金的流动方式。对于支付系统而言,资金有进有出。从支付系统到商户端就比较简单了,在清算完成后支付系统负责将代收的资金结算给商户,通常结算的操作可以在线上来完成(采用支付公司代付接口或者银企直连接口来完成),也可以由公司财务通过线下手工转账的方式来完成,因此这种资金流动的方式是单向的。出于资金安全考虑,大多数公司通常这部分采用线下方式实现。真实的资金流由支付公司按照约定期限(通常 T+1 )结算到平台公司对公账户中,然后再由平台公司再按照交易明细进行二次清算后结算给对应的商户。 支付系统 一个支付系统需要由哪些功能模块组成 01 完整的支付系统包括如下功能: 应用管理: 同时支持公司多个业务系统对接。 商户管理: 支持商户入驻,商户需要向平台方提供相关的资料备案。 渠道管理: 支持微信、支付宝、银联、京东支付等多种渠道。 账户管理: 渠道账户管理,支持共享账户(个人商户)及自有账户。 支付交易: 生成预支付订单、提供退款服务。 对账管理: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对(通常T+1),确保交易数据的准确性和一致性。 清算管理: 计算收款交易中商户的应收与支付系统收益。 结算管理: 根据清算结果,将资金划拨至商户对应的资金帐户中。 02  核心流程 支付系统有几个关键的核心流程:支付流程、对账流程、结算流程...

[转]一文看懂互联网支付系统整体架构 0

[转]一文看懂互联网支付系统整体架构

在互联网产品运营中,有很多小伙伴或许会遇到这样的困扰:产品好不容易推出来了,流量成本节节攀升,用户的活跃度、留存度却持续下降。 因此在瞬息万变的互联网产品环境中,需要研发接入支付系统来加入商业行为的闭环,支付系统能够帮助企业更好地实现商业化,利用那些为用户而生的支付体系产品,实现用户积累、商业变现。 对于支付系统,有针对不同行业的支付系统,有支付宝,微信支付,paypal的通用网关支付,也有聚合了不同网关的聚合系统。

[转]支付系统设计:支付系统的账户模型 0

[转]支付系统设计:支付系统的账户模型

账户体系是支付系统的基础,它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统的支付账户体系设计。我们从一些基本概念开始入手,了解怎么建模。

[转]百亿大表任意维度查询,如何做到毫秒级返回 0

[转]百亿大表任意维度查询,如何做到毫秒级返回

随着闲鱼业务的发展,用户规模达到数亿级,用户维度的数据指标,达到上百个之多。 如何从亿级别的数据中,快速筛选出符合期望的用户人群,进行精细化人群运营,是技术需要解决的问题。业界的很多方案常常需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法,从亿级别数据中,任意组合查询条件,筛选需要的数据,做到毫秒级返回。

[转]菜鸟下一代分布式体系架构的设计理念 0

[转]菜鸟下一代分布式体系架构的设计理念

二十年来,整个分布式系统架构的演进,从 C/S 到 B/S,再到分布式系统,当前广泛使用的是网格计算和云计算,包括目标、定位、场景。 菜鸟乃至阿里在全球化进程中,也面临着全球分布式架构问题,以及仓储系统中独特场景下云计算能力的不足。菜鸟资深技术专家 黄浩 老师目前带领团队在设计规划菜鸟下一代分布式系统架构,结合传统云计算 PaaS/BaaS 以及边缘计算能力,将其应用在全球多域体系中。

[转]考拉:传统企业请注意:不够痛就别微服务,有坑 0

[转]考拉:传统企业请注意:不够痛就别微服务,有坑

在多家传统行业的企业走访和落地了微服务之后,我发现落地微服务是一个非常复杂的问题,甚至都不完全是技术问题,它牵扯到 IT 架构,应用架构,组织架构多个方面。 当时我想微服务既然是改造应用,做微服务治理,类似注册,发现,熔断,限流,降级等,当然应该从应用开发组切入。 一般一开始聊的会比较开心,从单体架构,到 SOA,再到微服务架构,从 Dubbo 聊到 Spring Cloud,但是必然会涉及到微服务的发布和运维问题,涉及到 DevOps 和容器层。 这些都不在开发组的控制范围内,一旦拉进运维组,对于容器的接受程度就成了一个问题,和传统物理机,虚拟机的差别,会带来什么风险等等。 尤其是容器绝对不是轻量级的虚拟化这件事情,就不是一时半会儿能说的明白的。 更何况就算说明白了,还有线上应用容器,一旦出了事情,谁背锅的问题,容器往往会导致应用层和基础设施层界限模糊,这使得背锅双方都会犹豫不决。 有的企业的微服务化是运维部门发起的,运维部门已经意识到了各种各样不统一的应用给运维带来的苦,也乐意接受容器的运维模式。 这就涉及到容器直接的服务发现是否应该运维在容器层搞定,还是应用应该自己搞定的问题,还涉及 Dockerfile 到底是开发写还是运维写的问题。 一旦容器化的过程中,开发不配合,运维单方面去做这个事情,是徒增烦恼却收益有限的。 下图是微服务实施的过程中涉及到的层次,具体的描述参考《云架构师进阶攻略》: 在一些相对先进的企业,会在运维组和开发组之间,有个中间件组,或者叫做架构组来负责推动微服务化改造的事情。 架构组既需要负责劝说业务开发实施微服务化,也要劝说运维组实施容器化,如果架构组的权威性不足,推动往往也会比较困难。 所以微服务,容器,DevOps 的推动,不单单是一个技术问题,更是一个组织问题。 在推动微服务的过程中,更加能够感觉到康威定律的作用,需要更高层次技术总监或者 CIO 的介入,方能够推动微服务的落地。 然而到了 CIO 层,在很多企业又体会不到技术层面的痛点了,而更加关注业务的层面了。 只要业务能赚钱,架构的痛,中间件的痛,运维的痛,高层不是非常能够感知,也就体会不到微服务,容器化的技术优势了。 而微服务和容器化对于业务的优势,很多厂家在说,能够说到表面,说不到心里。 因而微服务和容器化的改造,更加容易发生在一个扁平化的组织里面,由一个能够体会到基层技术细节的痛的...

[转]蚂蚁金服异地多活的微服务体系,从“被动挖光缆”到“主动剪网线” 0

[转]蚂蚁金服异地多活的微服务体系,从“被动挖光缆”到“主动剪网线”

蚂蚁金服(当时还是支付宝)从 2013 年起就运行在单元化架构上,除了具备异地容灾能力外,还能做到异地多活,可随时在多城市、多数据中心调配流量。基于单元流量调配机制,可实现大规模集群的蓝绿发布、灰度仿真环境,为充分验证业务正确性、降低故障提供了基础条件。相应地,微服务体系也必须具备单元内收敛、单元间可控路由等能力,来支撑单元化技术架构的落地。本文根据玄霄 2018 年上海 QCon 演讲内容整理。

[转]360容器平台监控实践 0

[转]360容器平台监控实践

360 近年来上线了容器云平台,给团队工作带来了一些便利,同时也给运维工作带来了很多挑战。    背景 360 在做容器化平台之前,有一个基于小米开源的 Open-Falcon 进行二次开发的老监控系 (Wonder),这个系统承揽了公司所有的物理机和虚拟机的监控任务。随着容器技术的普及,以容器的方式在创建应用时,由于 Kubernetes 容器编排系统部署的服务具有弹性扩容的特性,而老的监控系统无法感知这些动态创建的服务,已经不适合容器化的场景,所以 360 团队就搭建了一套可以支持服务发现的新监控系统。

[转]小米大数据:借助Apache Kylin打造高效、易用的一站式OLAP解决方案 0

[转]小米大数据:借助Apache Kylin打造高效、易用的一站式OLAP解决方案

如今的小米不仅是一家手机公司,更是一家大数据与人工智能公司。随着小米公司各项业务的快速发展,数据中的商业价值也愈发突显。而与此同时,各业务团队在数据查询、分析等方面的压力同样正在剧增。因此,为帮助公司各业务线解决这些数据方面的挑战,小米大数据团队不断地尝试通过不同的技术手段打造新的解决方案。

[转]ZooKeeper分布式锁的实现原理 0

[转]ZooKeeper分布式锁的实现原理

一、写在前面 之前写过一篇文章(《拜托,面试请不要再问我Redis分布式锁的实现原理》),给大家说了一下Redisson这个开源框架是如何实现Redis分布式锁原理的,这篇文章再给大家聊一下ZooKeeper实现分布式锁的原理。 同理,我是直接基于比较常用的Curator这个开源框架,聊一下这个框架对ZooKeeper(以下简称zk)分布式锁的实现。 一般除了大公司是自行封装分布式锁框架之外,建议大家用这些开源框架封装好的分布式锁实现,这是一个比较快捷省事儿的方式。