聊天记录2017-05-06未整理版

Posted by PaymentGroup on May 6, 2017

08:08:09 听过降峰老师的网课,很用心,点赞
08:08:50 请教一下各位支付平台双活都这么做的?

10:45:04 请教下,大家app收银台一般放在交易系统还是支付网关(支付系统),还是单独放?
11:07:02 没人讨论问题啊
11:07:24 我们是单独,建议与交易系统做分隔。是否放在支付网关视情况而定。
11:10:47 支付网关采用异步架构还是同步架构?
11:12:12 异步较多 同步性能跟不上
11:12:48 异步架构中消息队列一般用啥?
11:18:31 看公司选型吧,activemq,rocketmq的都有
11:19:04 kafka行吗
11:19:30 我们是分开的。收银台属于基础组 上层建筑。和账务 通道网关 结算 是分开的。
11:19:45 蘑菇街自研了一套mq
11:19:57 牛
11:20:06 [强][强][强]
11:20:47 这是 我们的基础架构设计。
11:20:47 架构设计 11:21:03 这个我有分享过。
11:21:59 收银台作为独立的应用对外提供服务
11:22:44 支付订单和收银台的交互时序是怎么样的呢?
11:27:00 kafka一般还是作为日志传输用,主要是能容忍消息可能会丢失
11:28:24 多谢
11:29:37 不知道rocketmq新版本是否还需要app处理重复消费的问题?
11:32:46 app在接受消息通知的时候 都需要做幂等控制吧?mq最少通知一次和只通知一次,在实现上有较大的区别 。
11:33:33 是的,我们用过rocketmq之前的版本,是需要自己做幂等控制的
11:34:17 你们都是偏技术的问题。我是前端pm。
11:34:23 学习ing
11:35:07 有谁做过支付平台的同城双活和异地多活吗?
11:35:30 我的理解:支付系统有操作行为的接口都需要有幂等保证[呲牙]

11:36:18 我们这边正要做同城灾备和双活
11:36:34 我也还惆怅~

11:41:00 坐等大神分享~
11:41:30 有没有阿里或者淘宝的大神出来分享一下双活、多活的架构?
11:43:31 我们有做同城双活……
11:45:10 阿里“三活”数据中心实践经验
11:46:08 你们同城双活的架构是啥样子的?
11:47:19 深圳两个中心,交易通过消息中间件切了部分流量发往两个中心
11:48:29 数据复制是在数据库层做的还是存储层做的?
11:50:04 我们数据库本身就是腾讯的tdsql分布式数据库,数据库直接保证这个
11:50:28 tdsql支持跨两个数据中心?
11:55:53 这是我一直没搞懂的
11:56:42 这偏基础平台搭建了
12:01:24 大公司才需要考虑
12:01:24 a
12:01:24 a
12:30:26 set即数据库服务单位
12:31:01 一个set单个节点,1主2备
13:20:08 谢谢各位大神
13:27:48 同谢

13:48:16 请问一下各位同仁,大家现在在对接接入网联了吗
13:51:11 同问 这个后续银行方的接入计划各位同仁了解吗
13:54:25 网联系统四大行都没接入呢……首批联调时间是6.30……
13:55:05 [发呆]最近那边催着我们公司6月底完成接入
13:56:06 那其实现在网联平台上没接入几家银行咯
13:56:22 嗯
13:56:55 支付宝和财付通是不是已经完成了对接,但是还没有切量过去
13:57:37 财付通接了,支付宝好像还没没接
13:58:00 即使介入,刚开始也是只切1%交易过去
14:04:24 百度接了 还没投产
14:15:38 有哪位同仁能分享一些清分,对账,报表的架构思路吗?
15:40:11 这个话题有点大,得分头说
15:47:50 分几块大家讨论下
15:49:28 对账分散在各个地方,有点头大,多方勾对麻烦的很
16:34:29 现在是啥架构?
17:16:18 三大块对账,内部,渠道,业务方
17:16:24 都不一样处理
17:22:18 微信支付商户平台中看不到订单中的商品详情列表,只有每个订单总金额,财务想每一种商品单独对账,大家有遇到过类似需求的吗?
17:37:47 赞需求
17:48:00 可以加备注字段
17:48:58 微信商户后台,只有商户订单号是可以和自己的交易系统记录中的商户订单号匹配的
17:50:15 一个订单只有一个对应的名称字段,通过商品名称字段自己定义下详情?其实商品详情微信是拿到了,我怀疑是还没时间做商品种类的对账单。创建微信支付订单时有传给微信订单里包含哪几种商品各是几个
17:53:57 嗯,目前微信是没有在商户后台导出的记录中加这些的,所以只能自己来记。。
17:54:35 [捂脸]
18:07:08 正统做法应该还是渠道对账和内部对账来保证的,渠道方面只关注金额状态正确
18:11:41 三方对账
18:13:50 (1)支付流水和通道流水对,以通道为准同步状态。 (2)支付记账流水和核心流水对,以核心记账流水为准。 (3)三方流水记入应收应付流水表对,检查单边账记录。
18:14:29 我们银行内的可能会和支付机构的有些差别哈~[微笑]
18:14:59 [强]
18:15:45 好专业哦[强][强]
18:16:55 嗯,是的,外部对账对流水,内部对账对细节
18:16:57 还有就是核对每个通道每日的待清算科目余额变动是否与实际发生额一致。
18:17:20 我们准备采用微服务重构一下支付平台,问一下模块怎么划分比较合理?
18:17:29 这是账面和实际的核对
18:17:42 问题太大了@XXX?
18:18:03 @XXX?接上午问题 两个机房的交易通过消息中间件来分流 那中间件本身不还是单点吗?
19:38:29 主流消息系统都有高可用的方案。
19:39:44 他想知道的是怎么保证消息系统在两个数据中心双活?
20:14:40 这个消息系统问了下说是高可用的,但怎么实现高可用的得找人再了解?
20:15:48 多活需要物理的虚拟路由支持吧?
20:37:23 对的

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。