07:01:43 韩财光
周末要发一下群规
07:02:16 韩财光
#本群三大纪律#: 一,文明聊天,尊重演讲嘉宾。嘉宾分享期间,不得发言打断。 二,畅聊技术话题,营造浓厚学习分享氛围。 三,共同维护本群纪律。 #本群八项注意#: 一,不随意邀请朋友进群。若要进群,需先和群主联系,群主同意后方可邀请朋友进群,如没经过群主同意邀请朋友,邀请者需发红包,将被邀请者移出群。 二,不许发广告,发广告须发100元以上红包。 三,不许发表情图片和视频。 四,不许发分享链接,除非与技术相关。 五,不闲聊私人话题。 六,不盖楼刷屏,不发段子。 七,不索要红包。抢到红包的说谢谢,抢不到的不许抱怨哭闹。做个有礼貌的好孩子。 八,违反了要发红包并保证不再犯规,如不发红包将被移出群。 ?特别注意:群里同学请修改昵称:姓名-公司-岗位-城市。 ? 请群里各位朋友遵守本群纪律,相互监督,共同维护群秩序,营造一个良好的学习环境。
07:10:48 我
07:10:53 我
昨天签到红包数额最大的同学
07:11:47 我
@CSII-崔奕?志愿者将联系你安排分享的事情。感谢支持。
07:24:20 韩财光
恭喜@CSII-崔奕?同学 你抢到的也是本周最大的一个红包[坏笑]
07:25:50 潘儒刚-连连支付PM
恭喜,期待啊
07:32:24 孟??
恭喜崔总@CSII-崔奕?[鼓掌]
07:32:55 孟??
不许发表情图片 严重同意[微笑]
07:34:54 张泽雄-民生金服 项目总监
今天还上班吧?
07:35:12 汪晓明-什马金融-CTO
@老熊-爱奇艺-技术经理-北京?群主,发个不错的工作机会给大家可以吧?杭州的CTO岗位[偷笑]
07:38:01 韩财光
@汪晓明-什马金融-上海?群规说要先发红包的[微笑]
07:38:41 汪晓明-什马金融-CTO
哦 那让我思考一下 因为我不收人家猎头费[抓狂]
07:40:56 张泽雄-民生金服 项目总监
[捂脸]
07:41:19 韩财光
招聘算公益广告 可以商量 或者应聘者许诺成功后再补也可以 我觉得
07:42:22 张泽雄-民生金服 项目总监
我觉得也是,别广告满天飞,别影响大家交流就行
07:44:36 韩财光
是啊是啊 人多了就容易吵杂
07:48:21 汪晓明-什马金融-CTO
还是发一个吧,机会的确不错的先给群内各位大佬,杭州b轮跨境支付创业公司招聘CTO,要求有支付开发经验,有互联网公司背景,Alipay和PayPal最佳,带过研发团队。私人推荐非猎头,有兴趣的加我微信。
07:49:22 汪晓明-什马金融-CTO
微信红包
07:54:41 郭芬-中央结算公司
互联网公司背景。。。,我是没戏了
07:59:07 张泽雄-民生金服 项目总监
央企还跳?我从联通出来是没办法,中债不挺好的吗
08:00:06 韩财光
我也没戏 我仅仅是使用过这两个 alipay paypal
08:03:18 张泽雄-民生金服 项目总监
这要求,待遇还不得面谈啊[奸笑]
08:03:35 郭芬-中央结算公司
确实比一般公司好吧,安逸待遇也还凑合,但是没什么好的发展机会。
08:03:50 郭芬-中央结算公司
干的多干得少拿一样
08:04:14 王启荣-合众财险CTO
围城啊。
08:05:30 张泽雄-民生金服 项目总监
大公司都差不多,干活的总是那几个,然后大锅饭
08:05:31 人生几何-农行软开 快捷支付开发
央企靠牌照,不靠技术和市场
08:05:56 郭芬-中央结算公司
养老好地方
08:06:07 汪晓明-什马金融-CTO
[呲牙]
08:06:38 汪晓明-什马金融-CTO
民企干久了,累的要死,好想进国企
08:07:35 龚正-滴滴-支付金融
08:07:49 郭芬-中央结算公司
有一同事3年来,什么都不干,领导说的压根不听,照样和我们拿一样多
08:10:37 人生几何-农行软开 快捷支付开发
要这样想,人家有背景??
08:15:07 韩财光
而且还不小
08:21:47 张泽雄-民生金服 项目总监
体制文化都很重要,企业越大越难改变,就看自己想要的是什么了
08:27:18 pangning-安邦集团收付团队研发
只能跳槽来 涨工资和证明自己?
08:27:25 pangning-安邦集团收付团队研发
[捂脸]
08:28:46 pangning-安邦集团收付团队研发
阿里的那一批的技术骨干都是随着公司成长的
08:38:59 郭芬-中央结算公司
这个看机会,没机会就踏实做好自己的工作啊
08:42:28 李小-交通银行商户运营 支付PM
大清早的还有红包领
08:42:38 李小-交通银行商户运营 支付PM
[奸笑]
08:44:43 我
关于招聘广告,好几位同学也联系过我要发招聘广告,一直没有同意。 群里有很多公司的领导,大部分也都在招才纳士,建议是大家在群里看着能对上的,就私聊吧。
08:46:17 刘伟-猪八戒-高级PM
这个群是我加的 质量最高的一个群??感谢 老熊,那么费心[强],义务做这些事儿
08:46:43 落雪飞花-农信互联-开发经理
[强]
08:47:08 我
有计划换地方的同学,群也是一个才艺展示的舞台。希望能帮助大家。
08:47:24 满月明 中移动资金归集负责
[强][强][强]
08:47:25 郭程-微信支付商户运营腾讯
[强]
08:47:36 王向东-卡联科技-PM
[强]
08:47:50 孔晓光 丰瑞祥CTO
有想换地方同学可以私聊我[色]
08:47:51 Tim-深圳百灵鸟-架构
的确[强]
08:48:33 吴浩
[强][强][强]
08:49:39 孔晓光 丰瑞祥CTO
@老熊-爱奇艺-技术经理-北京?尤其欢迎你,老乡[偷笑][偷笑][偷笑]
08:49:58 Summer 梁夏
[捂脸][捂脸][机智]
08:50:02 Summer 梁夏
@孔晓光-丰瑞祥-技术-北京?
08:50:47 孔晓光 丰瑞祥CTO
今天银联的发布会,有同学在现场么
08:51:10 我
@孔晓光-丰瑞祥-技术-北京? 谢谢老乡。[呲牙]
08:53:40 我
@汪晓明-什马金融-上海?汪总,不好意思啊,找CTO的话,得多大的红包呢。
08:56:10 Charle-跨境通-清结算PM
@老熊-爱奇艺-技术经理-北京?迄今除了工作群之外,加的第一个高质量的群[强][强][强],希望保持[微笑]
08:56:28 孔晓光 丰瑞祥CTO
支付这块的人才需求量太大了
08:57:54 dio
主要是这块人才很难培养,基本都得看运气,跟其他的类型还不一样,能懂全局的基本就没有
08:58:14 李玉福
这个群是我加的 质量最高的一个群??感谢 老熊,那么费心[强],义务做这些事儿
08:59:12 freewolf-天津金融资产交易所技术
老熊这群挺nice的 学到不少东西 每天到家 复盘一遍群信息 记录一些笔记 收获大大的
08:59:17 煜-易物网-技术总监
都缺……
08:59:21 王启荣-合众财险CTO
确实是质量最高的群,都是满满的干货。
09:00:01 freewolf-天津金融资产交易所技术
不只是缺人 根本就找不到
09:08:01 阿兵-美利金融-PL
群里应该有做P2P,融资相关公司的支付
09:08:12 阿兵-美利金融-PL
我们可以开个话题聊聊
09:10:17 李丹-风控经理-双乾支付
各位早
09:10:29 李丹-风控经理-双乾支付
端午节前最后一天
09:12:48 人生几何-农行软开 快捷支付开发
@小吴_产品-承泰-上海? 请教一下您说的懂全局的人是指有什么样的要求
09:13:33 马忠信-联金所-深圳
从银行出来的技术会不会有优势些
09:14:11 孔晓光 丰瑞祥CTO
不一定
09:14:20 郭芬-中央结算公司
每个人的全局都有局限性,都是自家公司的全局
09:16:22 亡目丁-币港湾PM
我是P2P资金端的[呲牙]@阿兵-美利金融-技术经理-北京
09:17:49 郭芬-中央结算公司
技术跟着业务发展,我们是这样的。这些年,我和另外一个同事做银登中心的系统建设,从无到有,就成长很多,但是仍然局限于资产登记托管和结算的范围。
09:18:15 沈一点-恒生电子-工程师
第一次听说从银行出来的有技术优势
09:19:22 煜-易物网-技术总监
@郭芬-中央结算(中债登)-北京?你说的应该是业务范畴。
09:19:23 煜-易物网-技术总监
这是目前各大支付或者金融都头疼的事,其中跨越财务,法务。
09:19:48 蘑菇街_陈宗
银行出来有业务背景优势 但是技术优势没有吧
09:20:02 煜-易物网-技术总监
同意
09:21:14 朱雄新-广发支付组
先在公司待过,再到银行的,技术上会好些
09:21:22 煜-易物网-技术总监
技术与个人相关,行业影响因素比重小。
09:22:22 freewolf-天津金融资产交易所技术
同意 技术只看个人追求
09:22:27 沈一点-恒生电子-工程师
技术也要跟着业务落地
09:23:06 郭芬-中央结算公司
技术是为业务服务的嘛,无论多好的技术适合的是最重要的,我们这些年也频繁跟恒生、阿里、京东金融、支付宝交流过,也确实见过很多很多很好的技术,但就感觉不适合我们的场景。相信大家也有这种情况,别人的技术解决方案是为了解决自己问题而发展出来的,自己生搬硬套就容易四不像。
09:23:13 freewolf-天津金融资产交易所技术
这不一定的 可以脱离公司现有业务 变成个人的东西
09:23:17 Aaron-携程金融支付PL
主要是有这业务非银行很难接触
09:23:25 蘑菇街_陈宗
技术我理解不是知识 而是业务落地的能力
09:23:30 李紫建
@郭芬-中央结算(中债登)-北京?非常认同
09:23:47 郭芬-中央结算公司
就是技术和业务结合的能力
09:24:09 李紫建
业务得落地,技术才能最大化凸显价值
09:24:10 freewolf-天津金融资产交易所技术
技术结合业务才有意义 要不就是知识
09:24:14 freewolf-天津金融资产交易所技术
无法转化
09:24:22 煜-易物网-技术总监
还是换个话题吧。
09:24:30 李紫建
@郭芬-中央结算(中债登)-北京?能做到机构不多
09:25:12 马忠信-联金所-深圳
想请教下各位,这些支付,结算,账务系统,产品的角色是什么,重要吗
09:25:39 沈一点-恒生电子-工程师
非常重要
09:26:15 马忠信-联金所-深圳
需要产品具备哪方面的能力呢
09:27:43 孔晓光 丰瑞祥CTO
纵向贯穿能力,以及对应的控制能力
09:28:28 马忠信-联金所-深圳
@孔晓光-丰瑞祥-技术-北京?是从系统功能角度还是业务流程角度呢?
09:28:55 pangning-安邦集团收付团队研发
技术结合业务才有意义 要不就是知识 这个说的很好
09:28:56 马忠信-联金所-深圳
感觉系统功能架构,技术都可以搞定了[皱眉]
09:29:38 孔晓光 丰瑞祥CTO
怎么划分更合理,更适合自己的业务,是命题
09:31:21 马忠信-联金所-深圳
看过几次分享,感觉各位技术人员都能从业务和技术角度分析,对业务的了解不比产品差
09:32:01 马忠信-联金所-深圳
甚至各位对会计分录都很熟悉
09:33:07 孔晓光 丰瑞祥CTO
华尔街投行高级经理都会写代码,你说他是程序员么[调皮]
09:33:10 郭芬-中央结算公司
目前我们和公司业务部门沟通的时候就是感觉业务人员表达不清楚自己的业务场景,或者我们对业务不熟悉导致做出来的东西不好,倒没有觉得技术是什么问题(无非就是钱和时间)。
09:33:16 花生-新网银行PM
独家 | 揭秘代扣江湖灰色产业链 |
09:36:12 蘑菇街_陈宗
做支付的技术 对业务要非常熟悉 要不做出来的产品容易歪
09:36:30 龚正-滴滴-支付金融
[呲牙]
09:41:19 ??桂明 ??
@铁手_蘑菇街_技术_杭州?非常对,赞同。
09:41:20 煜-易物网-技术总监
产品和技术,从来不是对立面。不过是工作职责上的划分。
09:42:06 龚正-滴滴-支付金融
本来产品和技术都是软件开发工程师
09:42:16 龚正-滴滴-支付金融
后来才划分开来 分工明确
09:42:30 龚正-滴滴-支付金融
变成数据分析师 然后
09:43:07 王启荣-合众财险CTO
技术一定要去熟悉业务,才能愉快的沟通。
09:46:26 david-橙子支付-技术总监
技术一般只是了解业务吧,业务到底是怎么玩的,为什么要这么玩,估计很少技术会非常清楚
09:49:22 郭芬-中央结算公司
对,很多技术人员觉得自己比业务人员还了解业务,其实大部分时候技术人员都是了解程序是怎么写的。对于为什么这么玩,不清楚,对业务的前瞻性不够,设计出来的东西扩展性就差,然后老怪业务人员变需求哈哈。
09:49:59 我
20170525交流记录和专题
09:50:14 我
感谢@Fiona 的整理。
09:50:28 Yang
谢谢[抱拳]
09:50:31 Aaron-携程金融支付PL
@郭芬-中央结算(中债登)-北京?深有体会[捂脸]
09:51:21 李丹-风控经理-双乾支付
辛苦
09:59:37 张泽雄-民生金服 项目总监
我说一下我的体会:技术和产品本来就侧重点不同,技术和产品脱节的原因在于架构,架构负责产品与技术的转化,但很多场景下,很多架构师就是一个高级程序员或工程师,现加上产品人员缺乏产品的长期规划及对相关业务领域的深度知识(说的难听点,有时候专业度还不如技术人员)。 总之吧,专业度+沟通不畅+管理不善,存在问题很正常,所以,有些公司干脆打破了这个界限,就像devOps一样,实行产品技术一体化。
09:59:44 陈桂荣 翼支付 -研发组长
[强]感谢
10:00:29 李丹-风控经理-双乾支付
产品技术一体化·······
10:00:32 李丹-风控经理-双乾支付
挺好
10:00:38 煜-易物网-技术总监
是的
10:00:51 人生几何-农行软开 快捷支付开发
工资不给双份……
10:01:02 蘑菇街_陈宗
有这么个职位:产品架构师
10:01:30 张泽雄-民生金服 项目总监
架构师是分很多种的
10:01:46 煜-易物网-技术总监
工资是个伪命题。问问群里那些CTO或者大领导就知道了[玫瑰]
10:02:00 路杨 嘉联支付产品
偏技术的产品,偏产品的架构
10:02:12 张泽雄-民生金服 项目总监
很多大公司的核心人员,给自己的定位就产首架
10:02:13 孔晓光 丰瑞祥CTO
产品跟技术研发的不对等性
10:02:41 郭芬-中央结算公司
技术人员要多学习业务
10:02:47 张泽雄-民生金服 项目总监
说的再高一点,企业架构。。。
10:04:13 孔晓光 丰瑞祥CTO
只要侵入了,就是看谁道行高[呲牙]
10:04:38 张泽雄-民生金服 项目总监
技术人员学习业务是必须的,特别是对于金融行业,技术是为业务服务的,这一点必须明确 ,现在不都提倡IT融合?其实就是把技术应用到业务中,提高业务能力。
10:04:44 人生几何-农行软开 快捷支付开发
双份工资开个玩笑的话,但是人的精力是有限的,要不然怎么要分工,光把技术明白也就非常不错了
10:05:07 孔晓光 丰瑞祥CTO
产品也是技术线
10:05:27 孔晓光 丰瑞祥CTO
还有一个点,就是公司的战略意图,主导着团队构建基础
10:06:13 花生-新网银行PM
产品应向全平台产品经理发展,以后的原型图产品经理的价值堪忧
10:06:21 韩财光
业务就是流程和规则 软件实现需要严格遵循业务规则 理论上业务描述得好技术可以不懂业务 就好像程序在操作某个数字 但不需要理解该数字代表的含义
10:07:46 郭芬-中央结算公司
那就可以自动化编程了,要程序猿干嘛。。
10:08:16 孔晓光 丰瑞祥CTO
我举个例子,只做单边市场,那交易一律是商户发起的,但是双边市场下。交易可以从C端发起
10:08:43 张泽雄-民生金服 项目总监
广义的业务是说,你公司要做什么事,以什么样的方式去做,去为市场服务,从而赚到利润。
10:08:53 孔晓光 丰瑞祥CTO
支付行业很多场景下是金融规则主导,技术先行,运营发展
10:09:39 花生-新网银行PM
@孔晓光-丰瑞祥-技术-北京 这个就不是低 level 的产品了,把控商业模式的产品,要求又上了一个层次
10:09:47 人生几何-农行软开 快捷支付开发
创造价值是技术和业务的终极目标
10:10:35 孔晓光 丰瑞祥CTO
@花生-新网-产品?对,而往往这就是大家目的,不是吗
10:11:30 孔晓光 丰瑞祥CTO
产品是伪命题,产品运营是真理,因为公司都是追求利润的,无产品没噱头,无运营没用户
10:11:55 孔晓光 丰瑞祥CTO
[流泪]求相关人才
10:13:26 freewolf-天津金融资产交易所技术
产品运营对每个公司都是挑战
10:13:30 freewolf-天津金融资产交易所技术
巨大的
10:15:46 张泽雄-民生金服 项目总监
我倒不这么认为,企业能生存,最重的要解决市场的某个需求,产品则这是种需求的实现,运营则是将产品变成商品。一个不能解决市场问题的产品,是没有意义的,运营也就没有意义了。
10:16:29 花生-新网银行PM
生孩子 vs 养孩子
10:17:28 孔晓光 丰瑞祥CTO
生存那叫主营业务,就是很多人想到你这个企业,就知道你干什么的
10:26:09 张泽雄-民生金服 项目总监
@花生-新网-产品 你这个比喻比较贴切,柯达,诺基亚就是很好的例子。
10:33:41 韩财光
创造价值的是业务 技术通过为业务提供服务来体现自己的价值 呵呵
11:44:38 修-拉卡拉-产品-北京
想请问大家个问题,银行通道接口的错误码的封装,是技术人员处理,还是给运营人员开发了配置管理页面,由运营人员自己定义封装?
11:47:01 张泽雄-民生金服 项目总监
我们都是技术人员提交SQL到运维
11:48:08 李行-途牛支付中心研发总监
通道上线,初始化的时候是提SQL
11:48:28 李行-途牛支付中心研发总监
后续有变更,我们有后台提供给运营人员维护的
11:52:06 华-南京亚软-IT总监
@李行-途牛-南京 核心上线你们做到灰度了吗?
11:52:37 李行-途牛支付中心研发总监
公司有灰度环境
11:53:00 李行-途牛支付中心研发总监
但是我觉得跟真正意义的灰度还有点距离
11:54:02 华-南京亚软-IT总监
现在核心变更后影响范围太大
11:54:57 华-南京亚软-IT总监
你们可以控制到新版本服务人群,商户群吗?
11:56:25 郭芬-中央结算公司
灰度环境跟生产环境的数据有区别么
11:56:30 郭芬-中央结算公司
数据库
11:56:53 郭芬-中央结算公司
是同一个还是两一个,是不是需要对不同数据进行分库分表的控制
11:58:50 Tim-魔线科技-产品总监
如果是灰度,只是对人群灰度,为什么要数据区别?
11:59:21 华-南京亚软-IT总监
@Tim_魔线_产品_深圳 因为版本,有可能会有数据库变更;
11:59:26 郭芬-中央结算公司
不同人群使用的时候数据放到同一个库的话,那么数据错了怎么办
12:00:33 张泽雄-民生金服 项目总监
逻辑垂直切分
12:00:49 郭芬-中央结算公司
具体点?
12:01:04 Tim-魔线科技-产品总监
哦哦。你指的数据库变更。
12:01:40 郭芬-中央结算公司
因为你应用有可能是错的,产生的数据也是错的
12:03:53 张泽雄-民生金服 项目总监
就是将生产环境划成一定区,每次只更新一个区。
12:04:30 张泽雄-民生金服 项目总监
数据也是隔开的
12:04:32 郭芬-中央结算公司
哦
12:04:51 Tim-魔线科技-产品总监
对于小的公司,只有一套生产环境,如何做区域划分呢
12:05:07 郭芬-中央结算公司
大体上是明白了,希望能有人做分享啊
12:07:02 张泽雄-民生金服 项目总监
小公司也至少双节点
12:07:04 郭芬-中央结算公司
区域化分应该就是指对唯一的一套生产环境进行划分吧
12:07:51 郭芬-中央结算公司
应用新老版本并行
12:10:49 张泽雄-民生金服 项目总监
新老并行也要看怎么个并行法,如果数据用同一份,数据结构不兼容了,并行不了了。所以竖直划分也含库
12:11:53 张泽雄-民生金服 项目总监
region. zone前期要规划
12:13:04 郭芬-中央结算公司
可不可以这样,让一部分用户用新系统,一部分用户用老系统,新老系统完全分开?晚上的时候新老系统的数据库进行同步或者移植?
12:13:19 郭芬-中央结算公司
这样老系统可以作为新系统的应急?
12:14:02 Tim-魔线科技-产品总监
@郭芬-中央结算(中债登)-北京 你可以找一个家第三方的做AB测试的供应商帮忙做
12:15:28 郭芬-中央结算公司
测试是测试啊,但是新核心上线后,一定有一个试运行的时间吧,这段时间,老系统也不能直接丢了啊。
12:16:26 郭芬-中央结算公司
AB测试是测试阶段一个很好的方案
12:26:28 武伟会-国家电网新能源-PM
新老系统同步运行,前期以老系统为主,等观察一段时间后,新系统相对稳定了,再以新系统为主,最后完全稳定,可以把老系统下线
12:27:17 Tim-魔线科技-产品总监
AB测试不是测试阶段的
12:27:29 Tim-魔线科技-产品总监
是上线阶段给真实用户的
12:27:56 Tim-魔线科技-产品总监
灰度在一定程度上跟AB测试是一个概念。 在一定程度上
12:29:06 Tim-魔线科技-产品总监
灰度和AB测试不是为了看稳定不稳定,是看新功能合适不合适。有没有改差。特别是首页的改版非常的慎重,需要做灰度
12:35:31 郭芬-中央结算公司
哦哦
12:41:55 张泽雄-民生金服 项目总监
产品灰度偏重于产品迭代,为了支持产品灰,系统迭代也灰了,系统的灰就和架构技术相关了
13:46:29 张泽雄-民生金服 项目总监
这个就是最大的问题,前期架构要考虑的
13:46:30 张泽雄-民生金服 项目总监
13:53:16 pangning-安邦集团收付团队研发
这个d
13:53:27 pangning-安邦集团收付团队研发
很难改变
13:53:44 pangning-安邦集团收付团队研发
相当于大改了
13:57:03 张泽雄-民生金服 项目总监
我们以前也弄过这个事,弄了两库,两库之间后台同步。
13:57:21 张泽雄-民生金服 项目总监
比较烦人
14:00:35 郭芬-中央结算公司
求分享解决方案。。
14:07:52 张泽雄-民生金服 项目总监
我的一个想法就是分区,绿的是新的,橙色的是旧的
14:07:53 张泽雄-民生金服 项目总监
14:10:24 李飞-产品经理 掌众金融
这个不能给用户加标识?通过用户标识来跟踪后期的数据反馈?
14:10:31 李飞-产品经理 掌众金融
@张泽雄-民生金服-研发-北京?
14:10:46 韩财光
必须当做是两个完全不同的系统 然后数据软件必须一套 然后根据用户重定向或者强制升级app
14:13:15 张泽雄-民生金服 项目总监
@李飞-掌众金融~pm-北京? 你说的是产品层面的,其实这个方案也是支撑的,你得先保证绿橙两方系统都运行正常,才能支撑产品层的用户分群
14:13:43 张泽雄-民生金服 项目总监
网关层分流就行了
14:15:24 张泽雄-民生金服 项目总监
我的意思是没有系统的灰,产品的灰就没法做
14:16:21 张泽雄-民生金服 项目总监
体验用户一点,全是500错误,产品就彻底完了
14:16:48 李飞-产品经理 掌众金融
没操作过这个,但是像你说的这样工作量我觉得太大了,其实就是两条并行的系统,但灰度可能只是针对个别页面,除非是真的大面积改版
14:16:56 郭芬-中央结算公司
假设分区后,两个区的用户进行交易,联机事务怎么处理。
14:18:57 张泽雄-民生金服 项目总监
@李飞-掌众金融~pm-北京 我说的灰度是系统的灰,这种灰不一定是产品引起的,比较3000台服务器,你一天也部署不完,可以分几天去布,这也是一种灰。 @郭芬-中央结算(中债登)-北京 这种结构一般都是分布式事务。
14:20:43 张泽雄-民生金服 项目总监
分区的另一个目标是为了减少影响,所以也叫滚动发布。
14:21:04 pangning-安邦集团收付团队研发
楼上的 你真是大拿[抱拳]
14:21:35 张泽雄-民生金服 项目总监
[流汗] 我只是随便说的啊
14:21:54 郭芬-中央结算公司
这个对于微服务架构应该是不错的,但是对于银行的新核心估计比较困难。
14:22:28 郭芬-中央结算公司
不知道哪个大银行的新核心用过微服务
14:22:34 张泽雄-民生金服 项目总监
银行一般是采用蓝绿部署吧,我也不太清楚
14:23:32 李飞-产品经理 掌众金融
@张泽雄-民生金服-研发-北京?有类似文章可以推荐吗
14:23:53 张泽雄-民生金服 项目总监
上次我们开会的时候说到了银行系统的微服务化,估计比较慢吧,外围改动太大了
14:24:41 张泽雄-民生金服 项目总监
@李飞-掌众金融~pm-北京 网上找找吧,应该有介绍,
14:25:12 李飞-产品经理 掌众金融
[OK]
14:27:12 张泽雄-民生金服 项目总监
银行有钱,用的都是高大上的高性能主机,互联网都是便宜机器,不过,在架构上都会逐步走服务拆分,因为应对复杂性的一个科学方法就是拆,分而治之
14:28:55 dio
我没记错银行好像都是IBM的系统和机器吧
14:29:41 孔晓光 丰瑞祥CTO
小机当然贵,但是3650低配我也觉得不便宜[憨笑]
14:30:07 Summer 梁夏
@小吴_产品-承泰-上海?银行的aix系统多些
14:30:42 孔晓光 丰瑞祥CTO
@Summer 梁夏-丰瑞祥-GM-BJ 到哪了
14:32:24 张泽雄-民生金服 项目总监
@孔晓光-丰瑞祥-技术-北京 可以不用3650 M5,DELL R430也可以,或HP的,华为的,浪潮的。。。。
14:33:20 EagleCheng-兴业银行架构师
请教一个问题,目前计划用MQ同步同步多个源的数据到汇总库提供查询。MQ数据丢失或者源异常,导致部分数据丢失,有什么好的解决方案吗
14:33:24 张泽雄-民生金服 项目总监
上次我去机房,好像是青云吧,全是华为的
14:33:35 dio
不懂 我几年前的同事好像是银行出来的 这都是他给我说的
14:33:44 dio
不知道是不是我记错了
14:35:23 张泽雄-民生金服 项目总监
@Eagle-兴业-架构-上海 你们用的哪个MQ?
14:35:45 EagleCheng-兴业银行架构师
AMQ
14:36:05 郭芬-中央结算公司
还有很多数据库用IBM的AS400,招行用得就是。我们也用的是400,程序还是原来的面向过程的RPG
14:38:55 张泽雄-民生金服 项目总监
AMQ 不太了解,像Kalfka之类的,应该有参数设置
14:40:03 孔晓光 丰瑞祥CTO
以前用过DELL的,印象很不好,不敢用了。华为的还OK?@张泽雄-民生金服-研发-北京
14:41:37 张泽雄-民生金服 项目总监
华为的我看用的还是比较多的,我们因为集团的关系,全是联想的
14:43:23 韩财光
@Eagle-兴业-架构-上海?是activemq吗 怎么发现丢的 处在什么运行环境 了解下
14:44:11 EagleCheng-兴业银行架构师
现在没发现丢单,现在在做设计,考虑万一出现这种情况的数据一致性
14:47:35 张泽雄-民生金服 项目总监
有两种方案:一种就是每条消息必须得到接收方的应答,比如应答方返回一个唯一编号,发送方确认收到了,才认为发送成功,不再发送,另一种就是定时对账的思路了,
14:47:39 韩财光
@郭芬-中央结算(中债登)-北京?新老要联机那就再弄个模块专门处理的这类? 都是凭直觉的想法
14:49:28 EagleCheng-兴业银行架构师
我们目前的思路,类似于定时对账,每隔一段时间拉清单对一下
14:49:36 张泽雄-民生金服 项目总监
如果你发送方在消息体中有一个连续的编号也是可以的,接收方只要发现断号了,可以要求发送方重发
14:49:58 张泽雄-民生金服 项目总监
把断号的那段发过来
14:50:11 韩财光
是的 既然觉得mq不可靠那就自己加做校验
14:52:15 EagleCheng-兴业银行架构师
另外留了一个运维的口,做应急
14:56:45 EagleCheng-兴业银行架构师
消息强耦合确认应答,这样对于系统性能开销应该会更大,就没考虑这个方案。
14:57:01 张泽雄-民生金服 项目总监
嗯,因为你现在也不能确认会丢包,所以前期可以先做一些checkSum
14:57:43 张泽雄-民生金服 项目总监
如果你不启用这个策略,就做好数据丢失的应对方案吧,
14:57:53 Jack-捷信消费金融技术主管
@Eagle-兴业-架构-上海 用rabbitmq吧
14:58:51 张泽雄-民生金服 项目总监
架构这东西,都是边用边总结,看怎么能适合自己的项目
15:02:24 韩财光
按时间或序列号范围 阶段批量一次算一批做比对 大概率是完整的 有差别再逐个对比出问题的批次 这要求容忍度宽一些
15:09:57 秦红胜-CTO-共致开源-
增加事务方面的控制mq就不会丢数据
15:11:28 秦红胜-CTO-共致开源-
谁能分享一些第三方支付平台的风控资料,多谢
15:23:20 Tim-魔线科技-产品总监
最好能有一整套风控模型的知识分享就好了
15:40:47 EagleCheng-兴业银行架构师
@张泽雄-民生金服-研发-北京?断号的方案挺巧妙,可以虚拟一个连续的号出来。
15:44:36 Jack-捷信消费金融技术主管
用事务去控制 会有性能方面的影响
16:08:09 我
@双眼皮Eagle AMQ还是相当可靠,至少我们还没遇到丢消息的事情。 处理的时候,控制下MQ的事务就行。
16:08:20 我
使用AMQ的桥接来提升可靠性。
16:08:48 名叫旺达的鱼
类似于支付宝的账单列表中的交易对手的头像URL,不管近期记录还是历史记录都是显示最新的头像图片, 查询的时候势必要去获取对手的头像URL, 这些数据相当于每个用户或商户都要缓存起来吗? 还是有其他什么高效的方案?
16:09:31 我
Kafka是会重发消息,倒是不会丢消息。
16:09:43 韩财光
类似tcp协议里的seq ack
16:10:13 我
@高俊奇-黑钻-RD 这种信息一般扔CDN上,性能和带宽不是问题。
16:14:05 EagleCheng-兴业银行架构师
@老熊-爱奇艺-技术经理-北京?就是技术上没考虑丢消息的预防方案?
16:15:39 我
要做对账。
16:15:48 秦红胜-CTO-共致开源-
采用事务模式不会丢消息
16:16:56 秦红胜-CTO-共致开源-
写队列同时写数据库
16:19:58 名叫旺达的鱼
@老熊-爱奇艺-技术经理-北京 图像数据是任在CDN上, 主要URL是动态的(客户修改头像之后),那么我历史账单查询出来之后,要把交易对手的最新URL放进去,这时需要查询这些人员的头像URL,我现在遍历这个列表,是从redis上获取对应的头像URL,感觉还不是很好, 问问有其他什么方案
16:22:42 沈光辉-银联风控-上海
如果对实时性要求很高,redis挺适合的啊
16:23:54 Jack-捷信消费金融技术主管
@老熊-爱奇艺-技术经理-北京 如果生产端发送数据到mq 出现网络抖动,但无法捕获异常重新发送。 怎么处理丢失的消息?
16:25:33 秦红胜-CTO-共致开源-
设置一下mq的确认模式
16:26:42 Jack-捷信消费金融技术主管
如果是异步确认的,消息没法送成功,重发的话是如何重新获取原来的消息
16:30:44 我
@高俊奇-黑钻-RD 更换头像不更换URL
16:30:59 韩财光
mq事务等方式可以提升可靠性 但没写入数据库前都不放心 还是自己做下校验 要不睡不着吧[呲牙]
16:31:19 我
URL按规则来生成,比如 www.domain.com/img/{uid}.png?time=current。
16:37:13 Jack-捷信消费金融技术主管
@韩财光-东软(前)-开发-广州 没用事务处理,只用了异步确认机制
16:40:15 我
@Jack 消息发送也是事务。
16:40:50 Jack-捷信消费金融技术主管
16:41:11 Jack-捷信消费金融技术主管
自己想了个方案,借助日志文件 处理丢失消息
16:42:26 韩财光
是啊 自己校验不可少 mq可靠性高了我们就要轻便快捷点的方式 大概意思
16:51:49 名叫旺达的鱼
@老熊-爱奇艺-技术经理-北京 更换URL是为了,app做图像缓存,这样不要每次都去下载头像,只有当URL和本地不同的时候,才去下载。
16:52:10 名叫旺达的鱼
@老熊-爱奇艺-技术经理-北京 支付宝是换的,https://tfs.alipayobjects.com/images/partner/T1qLBDXmVdXXXXXXXX https://tfs.alipayobjects.com/images/partner/T1BxlDXdFXXXXXXXXX
16:52:40 名叫旺达的鱼
@老熊-爱奇艺-技术经理-北京 我更新了一下头像,头像URL发生变化了
16:54:24 hardy-唯品会金融
有很多用本地事物并补偿来保证消息发送的
16:54:34 韩财光
@Jack?来一个专题分享?就说这个图[呲牙]
16:55:39 Jack-捷信消费金融技术主管
前几天刚好准备了一份材料
16:56:12 Jack-捷信消费金融技术主管
不过需要完善下。
16:56:55 hardy-唯品会金融
另外有本来就支持的事物的 rocketmq相关 mq就是不要本地数据库这层了
16:57:11 Jack-捷信消费金融技术主管
@唯品会-金融-hardy 如果是分布式消息系统,那么如何用本地事物控制?
16:59:15 韩财光
@Jack?看什么时间方便给说说吧 对这些自己手工打造的都感兴趣[微笑]
17:02:42 华-南京亚软-IT总监
这边有人做过小P2P聚合售卖的app吗?
17:03:08 Jack-捷信消费金融技术主管
计划在6月中旬后吧。
17:03:25 韩财光
基本上两个确认是吗 确认收到了 确认存库了 分别在两个关键阶段或节点 异常的就汇总重发
17:05:07 Jack-捷信消费金融技术主管
是的。
17:05:18 Jack-捷信消费金融技术主管
对于消费端比较好办
17:05:27 hardy-唯品会金融
@Jack 我理解是这样的 比如你做支付成功了。然后发消息给订单中心 进行配送之类的 首先支付成功你需要改支付相关的数据状态 然后同时要发消息到mq 发消息成功 而支付状态是失败的。可以把发消息便为 记录数据库操作和改支付状态放在一个事物里面操作。如果事物执行成功然后在执行发消息操作。 如果发消息失败 可以有异步重试线程轮询消息记录尝试去发送
17:05:41 hardy-唯品会金融
不知道和你的上面的图理解是一个意思不
17:09:06 Jack-捷信消费金融技术主管
首先把消息写入日志文件,然后再把消息推送给MQ,通过publish confirm机制确认消息是否成功投递到MQ,如果是失败则把消息ID写入日志文件。通过定时任务同步前一天的丢失的数据到DB。在同步消息到DB中,则需要做消息的幂等性处理。
17:09:54 Jack-捷信消费金融技术主管
Consumer在写入数据库时候出现任何异常,则把消息写入日志文件,通过定时任务同步前一天的丢失的数据到DB。在同步消息到DB中,则需要做消息的幂等性处理。
17:10:46 Jack-捷信消费金融技术主管
然后再有另外一个JOB重新把这些丢失的消息路由到队列。
17:13:00 Jack-捷信消费金融技术主管
这样的话可以不需要事务,可保证消息的强一致性。
17:14:19 hardy-唯品会金融
但是这里感觉记日志有可能出现不一致的情况
17:15:14 hardy-唯品会金融
比如我日志记录了 但是我后面实际的我的数据库更新是失败的
17:15:24 hardy-唯品会金融
这种情况怎么操作
17:17:56 Jack-捷信消费金融技术主管
17:18:50 Jack-捷信消费金融技术主管
方案B可满足需求,
17:22:29 hardy-唯品会金融
producer 这里 sendmessage log 和到mq这里怎么保证一致性
17:25:46 Jack-捷信消费金融技术主管
job首先从send loss message log获取所有丢失的消息ID,然后对比send message log里面原始消息,然后再把这些消息重新发送到mq
17:27:44 hardy-唯品会金融
这里没有问题。 关键是这里面还有一个东西肯定要去更新数据的一个操作
17:28:35 hardy-唯品会金融
这个操作 有send message log 和更新数据库操作 这两个都有可能失败
17:28:47 hardy-唯品会金融
感觉这种场景很多
17:30:05 Jack-捷信消费金融技术主管
确实比较多,要看具体的业务场景。
17:30:51 hardy-唯品会金融
这种场景单纯的 log感觉有些问题
17:31:26 韩财光
producer-mq-consumer-db 这中间几个环节都有可能发生意外 最终要比对producer和数据库的版本才有意义 那就只做这个比对 异常的话从producer开始触发异常检测 让各个节点自己往下走?
17:31:49 Jack-捷信消费金融技术主管
指的log那方面的问题?
17:34:07 韩财光
正常流程和异常自检流程同时跑 事物的概念是确保一次成功多个操作 多是出于数据安全考虑才用事务 而我们的目的是发消息出去 不成就重发
17:35:54 韩财光
目的是传输 以流通量为考量出发点 保证数据完整还是次要的
17:36:22 Jack-捷信消费金融技术主管
事物是依赖在每个连接层面,会不会有性能影响?
17:38:17 韩财光
事务用在这里是不对的我觉得 事务特性要求肯定有性能损耗
17:39:08 Jack-捷信消费金融技术主管
对啊。发送效率会很低
17:39:11 hardy-唯品会金融
嗯 你们这歌场景这里用log方式是可以的
17:40:05 hardy-唯品会金融
如果是一致要求比较高的场景 是需要一些事物来操作 比如核心业务
17:49:02 韩财光
其实我觉得像java有了netty这种框架后 自己想做什么都可以任意发挥了 什么分布式能力别人已经提供了 就在上面跑自己的协议就行了 想象空间很大很大
17:52:54 pangning-安邦集团收付团队研发
请教一个问题
17:53:30 pangning-安邦集团收付团队研发
中间件起的作用有多大,为什么说java最高水平是淘宝的中间件团队
17:54:55 韩财光
你自己设定的这个结论 别人都不一定赞同 怎么解答为什么产生:)
17:56:06 pangning-安邦集团收付团队研发
知乎上看的[流汗]
17:56:33 pangning-安邦集团收付团队研发
我也很纠结,还挺多人认同
17:57:58 pangning-安邦集团收付团队研发
17:59:52 韩财光
都是个人观点 不了解阿里的东西 用过他们云主机管理api 极其烂!
18:00:20 Aaron-携程金融支付PL
因为很多小公司基本抽不出来人专人专门做中间件吧,有个架构部都不错了
18:01:48 张泽雄-民生金服 项目总监
我对淘宝中间件的理解就是淘宝系统的骨架
18:02:07 pangning-安邦集团收付团队研发
他们中间件效率好像很高
18:03:37 张泽雄-民生金服 项目总监
是啊,中间件是一个平台的主干线部分,效率低了平台就完了
18:05:03 张泽雄-民生金服 项目总监
一个平台框架很重要,这其中包括中间件,有了这,业务系统就省很多事了。框架都替你做了
18:07:22 pangning-安邦集团收付团队研发
开源的和他们自己的效率差在哪里
18:07:49 pangning-安邦集团收付团队研发
我用过的几个开源的中间件效率上没有直观感受
18:11:39 张泽雄-民生金服 项目总监
大并发下
18:16:24 李征烈-钱通支付PM
群里有了解虚假手机号码识别技术的吗?
18:18:43 程文东-拉卡拉PL
你是指养号的手机号码?或不常用的手机号码?
18:20:24 李征烈-钱通支付PM
暂时碰到的情况是,做个活动,用户参与达到条件,输入手机号获得奖励。 有人利用第三方软件批量生成一堆号码进行刷,且这些号码还能获得我们下发的短信验证码。
18:22:01 韩财光
有人专门养号码搞黑产的
18:22:07 王启荣-合众财险CTO
根据IP和设备指纹进行封堵吧
18:22:30 孔晓光 丰瑞祥CTO
华强北
18:22:48 王启荣-合众财险CTO
另外兑换时加上其他约束条件
18:22:55 张泽雄-民生金服 项目总监
风控系统呢?
18:24:15 程文东-拉卡拉PL
一些技术/数据服务商,已有虚假号码识别的服务,如同盾
18:25:17 王启荣-合众财险CTO
邦盛好像也能提供类似服务
18:25:20 李征烈-钱通支付PM
目前采用增加限制来解决的,比如IP、设备、风控一些规则
18:25:56 李征烈-钱通支付PM
@王启荣—合众财险—CTO—北京 说到点子上了,我就是看他们家的PPT,里面有这样的技术
18:25:58 程文东-拉卡拉PL
对于养号的号码,可通过运营商的数据,判断下消费金额/记录
18:26:36 张泽雄-民生金服 项目总监
运营啇不会给的
18:26:51 李征烈-钱通支付PM
@文东-拉卡拉-技术-上海 运营商的数据需要商务谈,还有数据服务商,相当于做验证,这种肯定的花钱。、
18:28:03 王启荣-合众财险CTO
不实时兑现,延后兑现,是有时间做更多校验的
18:29:06 王启荣-合众财险CTO
可以把兑换的东西发到邮箱里面,对邮箱进行二次判断
18:29:40 李征烈-钱通支付PM
体验不好啊~ 看来现在都还是治标不治本的办法。
18:30:08 王启荣-合众财险CTO
体验和安全是一个平衡
18:30:46 李征烈-钱通支付PM
是啊!
18:32:28 张泽雄-民生金服 项目总监
虚假手机号治不了本,风控才是王道
18:35:04 dio
风控也是没用,这玩意就是一个平衡的问题,你看你的成本能不能覆盖你的收益
18:36:02 张泽雄-民生金服 项目总监
没风控敢玩金融????
18:37:07 Tim-魔线科技-产品总监
群里有提供支付SDK给别人app用的吗
18:37:35 孔晓光 丰瑞祥CTO
啥样支付SDK
18:37:57 Tim-魔线科技-产品总监
就是提供微信支付,支付宝支付
18:38:06 Tim-魔线科技-产品总监
一股脑的都支持
18:38:07 Tim-魔线科技-产品总监
的
18:38:55 唐-大件会-CTo
ping++
18:39:05 Tim-魔线科技-产品总监
群里有吗
18:39:22 Tim-魔线科技-产品总监
群里有ping++的PM或者技术大神吗
18:40:17 我
@Nada @精神朋克 是ping++的。
18:40:38 Tim-魔线科技-产品总监
多谢老熊,我加他
18:40:50 dio
他的问题是虚假号码对应措施,风控是有成本的,我三年前在p2p呆的时候也被这类搞过,后面调高限制,有些真客户就被挡住了,这个就是个平衡问题,看你怎么做,我之前同事辞职专门去深圳搞这种黑产工作,很多虚假号码其实就是真人,你根本无法分辨情况
18:40:56 我
祥付宝不知道是否有SDK。
18:40:57 Summer 梁夏
@Tim_魔线_产品_深圳?现在很多三方或四方都是支持聚合通道sdk输出的
18:41:04 Summer 梁夏
我们这边也有
18:41:32 人保金服乔阳
我们也有
18:42:28 我
开源的有龙果系统,似乎支持的渠道不多。
18:43:34 李征烈-钱通支付PM
@小吴_产品-承泰-上海 这些真实的人,是不是前几年所称“肉鸡”。
18:44:05 孔晓光 丰瑞祥CTO
you
18:44:17 孔晓光 丰瑞祥CTO
各种SDK
18:44:39 dio
不太清楚,反正是能做到客服回访都能瞒天过海的情况
18:44:51 Summer 梁夏
@李征烈_PM_钱通?现在都被叫做影子了
18:45:19 张泽雄-民生金服 项目总监
我认为,风控就是风控,规则就是规则,可能会有误杀,风控的本质是告诉我们不要做,宁可不做,不要侥幸。 上一次当就血本无归
18:50:31 程文东-拉卡拉PL
在一些互金分支,流量成本已高于风控成本(包括第三方付费数据等),风控也需要和业务平衡。
18:51:33 李征烈-钱通支付PM
哈!
18:52:44 我
风控是出问题会血本无归。
18:53:42 程文东-拉卡拉PL
风控自身,也是和“坏人”不断斗志斗勇,边交学费,边进步
18:54:16 李征烈-钱通支付PM
风控岗行内很值钱的节奏~~
18:54:20 张泽雄-民生金服 项目总监
巴林银行死的很惨吧
18:55:27 Summer 梁夏
风控模型和风控体系现在都是一直趟路一直试错,也算是前人修路为后人造福吧
18:56:40 钟文帅-移付宝科技-产品经理
我发现没专门做过财务清结算和风控的支付产品经理都不特别好找工作了
18:57:40 李征烈-钱通支付PM
是啊
18:57:43 李征烈-钱通支付PM
同感
18:57:48 程文东-拉卡拉PL
是的,之前有段子:没经历过几百万以上坏账的风控,不是好风控[呲牙]
18:57:56 Summer 梁夏
现在行业尤其金融行业对于本职的要求就高于同类,因为出现问题就是真金白银的付出啊
18:58:01 潘儒刚-连连支付PM
这么恐怖啊
18:58:18 Summer 梁夏
@文东-拉卡拉-技术-上海?[强]
18:58:54 张泽雄-民生金服 项目总监
我其实是想表达的是,如果风控都搞不定的业务就不要做了,没有良好的风控在金融路上是走不远的
18:59:03 潘儒刚-连连支付PM
但是风控会不会很局限,尤其是支付方面的,以后转型怎么样
19:00:51 李征烈-钱通支付PM
顺路问个事情,大家有没有针对“卡和手机号码”做过限额的。 如:A支付账户,信用卡A1还款日1万,月累5万。
19:01:09 Summer 梁夏
@索马里-连连支付-风控-杭州?风控是多纬度的,风控掌握了一定的管控模型建立这个到哪里都是比较吃香的
19:03:51 李征烈-钱通支付PM
现在的用户限额、商户限额都是针对虚拟账户做的
19:04:38 dio
这个核心就是成本
19:05:02 dio
上面北京研发哥们说的没错
19:05:27 dio
但是要有语境的
19:06:55 dio
还有就是我接触了一下你说的那个兴业投资,移动端看了一下,怎么老是报错,本来还想去玩一下的,最近股票又股灾了,哎,真无奈
19:15:16 李征烈-钱通支付PM
[阴险] 看来没人做过这款…………
19:18:47 Summer 梁夏
@李征烈_PM_钱通?说下需求呗
19:24:13 李征烈-钱通支付PM
A支付账户,有2张信用卡,当前用户限额日1万,月累计5万。
19:25:21 李征烈-钱通支付PM
这个是限的支付账户,想要针对信用卡“卡号”做限额,如:A卡日1万,月累计5万,B卡同理。
19:28:25 Summer 梁夏
这个只有发卡行根据自家卡bin做管理的吧
19:30:15 张泽雄-民生金服 项目总监
@小吴_产品-承泰-上海?报什么错?你下个普通的mt4就可以了,周五黄金都涨疯了
19:31:39 dio
Mt4下过,哎,英文不好,很多功能看不懂,不会玩
19:32:40 李征烈-钱通支付PM
那换一个问答,给手机号码充值,一个支付账户给多个手机号码充值
19:32:42 张泽雄-民生金服 项目总监
19:32:49 张泽雄-民生金服 项目总监
有中文啊
19:34:32 张泽雄-民生金服 项目总监
这个风控能搞定啊,各个维度限额
19:37:25 李征烈-钱通支付PM
用户和商户的限额,是针对支付账户来限制的。 那么像支付账户给手机号码充值、充流量、还信用卡、充加油卡等等等,个人觉得单拉出来个模块做比较好,想了解大家是咋实现的。
19:39:14 张泽雄-民生金服 项目总监
你说的是限额还是功能
19:40:47 张泽雄-民生金服 项目总监
所有限额,落在风控上就是一个账务模型,变成余额,再加上账户分级,可以控制的很细了,
19:42:50 张泽雄-民生金服 项目总监
每个业务都可以建一个账户来控制累计,单笔直接走规则
19:44:36 李征烈-钱通支付PM
@张泽雄-民生金服-研发-北京 功能
21:48:49 张泽雄-民生金服 项目总监
功能肯定要拉出来,不同业务各自开展
21:51:16 Tim-魔线科技-产品总监
风控不是一棒子打死
21:51:56 Tim-魔线科技-产品总监
现在很多做现金贷的都无视风险
21:52:06 Tim-魔线科技-产品总监
黑白名单无视
21:55:15 李征烈-钱通支付PM
是的,还有死活不让实名认证地
21:57:07 李征烈-钱通支付PM
还有一些有虚拟账户有资金池,还不实名的
22:11:49 王启荣-合众财险CTO
GitHub搜到的一个风控工程https://github.com/ysrc/Liudao
22:51:56 Richard-裕维金服技术负责
22:52:12 Richard-裕维金服技术负责
这个?
22:55:54 韩财光
放假回家 没人维护了[呲牙]
22:56:58 张泽雄-民生金服 项目总监
我说个例子吧,我一个朋友,前两年,一年赚个200万没问题,两年后债务人拿着借来的2000万消失在美国了……
22:59:58 我
似乎没有维护了。有考虑建立一个支付的开源项目组,在群里讨论支付各接口规范并提供参考实现,以及支付数据的社工库。
23:02:13 freewolf-天津金融资产交易所技术
支持
23:02:19 张泽雄-民生金服 项目总监
我觉得先建业务规范、架构规范会更好点
23:03:26 我
是,规范先行
23:03:57 Richard-裕维金服技术负责
金融公司的支付和第三方支付的有多大区别呀
23:04:07 张泽雄-民生金服 项目总监
好主意
23:06:02 张泽雄-民生金服 项目总监
你说的金融公司指什么?
23:10:32 Richard-裕维金服技术负责
消费金融之类得
23:11:29 韩财光
支持 很感兴趣 听说以后第三方支付连银行都通过网联平台了是吗