20170818-51技术填坑挖坑史

Posted by PaymentGroup on August 18, 2017

一、主题分享

51信用卡成立至今5周年,由一家几十人的账单管理初创公司发展到现在1000多人的10亿美元金融独角兽,期间经历了很多坎坷。

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

51技术填坑挖坑史

二 Q&A

Q:重构的过程是不是需要很大的人力投入,还得注意不影响已有业务?重构的过程是不是需要很大的人力投入,还得注意不影响已有业务?
A:关键看和业务方的协调,毕竟现有架构已经影响的业务的稳定和发展;51信用卡的重构过程采取了分步迭代的过程,先重构业务,将业务模块划分清晰,然后逐个分批次改造。改造的过程可以结合到正常的发版过程中,每次上次部分功能,做好灰度机制。整个微服务改造用了大概一年半时间,从技术选型->架构设计->底层公用组建开发->服务架构推广->分业务分批上线

Q:底层公共组件都开发了哪些
A:主要封装了mysql、redis、log、消息这些基础设施的操作,封装了数据源、连接池、双活、分库分表等处理逻辑

Q:我想问问,你们做微服务技术转型之前,平台的业务量,关键瓶颈在什么地方?
A:转型前的平台业务在每天10万条左右的资产交易

Q:能否透露一下你们技术团队多少人?
A:目前技术团队在500人以上,还在扩张,到年底预计600人

Q: 51刚开始的情况和我们现在的情况有些类似,我们现在核心的收单模块一直没有稳定下来,每次割接总会提心吊胆,因为人手还不太充裕,测试不充分,我想请教下如何能尽快的把产品发布质量提高上去,您有什么建议?
A:去年我们也是类似的情况,现在通过一系列措施减少的故障数:小步快跑的版本迭代制度,每次发版间隔不超过一周,每次发布内容受控且需评审,主技术主测试负责相关上下游系统的沟通,确保不会因为上下游系统的发布问题引起自身系统故障。上线制度严格执行,先上预发,没有问题后再上正式生产,尽量执行灰度发布,先用小部分业务流量试水
A2:嗯,我们也是的,不过还是需要很好的统筹,能够有一定的前瞻性,还看考虑前后变化的过渡方案

Q:你们产品经理跟技术负责人是怎么职责划分跟配合的
A:51的产品经理主要负责需求分析和验收,中间的研发环境由主技术和主测试跟踪,确保能找到唯一负责人,负责人越多等于没人为项目负责,法不责众
Q:也就是技术负责人负责整个项目的推动主导?这样对技术团队的业务深度要求很高
A:是的,我们的目标是通过技术推动业务发展,对技术负责会要求在技术和业务上双修
Q:业务系统微服务核心是组织架构也要随之匹配,这块51的经验是否方便分享一下
A:是的,技术架构调整的前提是组织架构调整,康威定律。做技术架构调整的前提肯定是技术不能满足现有业务,原因就是业务已经发展到新的阶段,更大的规模,这时业务上会做拆分,技术此时可以跟上,和业务部门共同规划业务的调整。51这边会每半年定一个规划,技术的规划由业务的目标而来,然后分解到每季度的okr中,作为技术的考核。

三、自由讨论

1. 网联相关

Q:请问一下,网联成立后,支付机构备付金都要放到网联吗?
A1: 发文来看,是的
A2:备付金不会放到网联,但是可能会放到人民银行, 网联不碰资金

Q:请问以后非支付机构能连网联吗?
A:这个问题培训中没有提到,但是架构自己业务流程中都是为三方支付机构和银行服务

Q:请教一下,收单机构收到网联的结算款,来款银行显示是哪个银行呢个
A1:网联和银联干的事情很像。一个管线上一个管线下,网联提供大批量清算服务。结算还是由央行调拨头寸。
A2:整个机制应该跟银联很像,对账、清算、差错处理等等业务规则都是之前银联的人制定出来的

2. 微信支付分享遗留问题

Q:支付宝的代扣会放给银行服务商吗?
A:银行自己走代扣能力。
Q:我的意思是商户想使用微信支付宝的代扣可以连银行吗?不直连微信支付宝。微信支付宝 不会放这种接口给服务商的么?
A1:商户应该不关心支付宝背后到底走的代扣还是快捷吧?如果银行是以服务商角色连支付宝,也不知道支付宝到底走的是快捷还是代扣吧。另外,为什么商户有要求支付公司走代扣通道的要求呢?商户的代扣要求无非是定时扣款,对于支付宝来说背后走快捷就可以了。

3. 内外分账户问题

Q:请问下分户账户(外)和分户账户(内)做了哪些事情?

A:外部户和内部户,外部户这个很好理解,就是客户账户。内部户就是银行内部账户。都是用来核算的。 Q:会计系统中也会存在分户账户吗? A1:银行内部会有一个总分核对的动作,总账和分户账进行核对。 A2:就这张图拿第三方支付公司来说:分户账户(外):商户的账户 分户账户(内):支付公司在银行开发备付金账户。不知道有没有少了。

四、近期招聘需求

以下职位,有兴趣的同学,可以微信联系老熊,或者在本条目下留言(不公开)。

1. 今日头条【北京】

  1. 清结算产品经理,熟悉清结算业务,负责账户系统、清结算系统、对账系统、会计系统的功能设计、优化;

2. 万达快钱公司【上海】

简历发送到邮箱: 313014997@qq.com

  1. hadoop工程师, 要求:熟悉分布式数据处理,有3年以上Hadoop或 HBASE开发经验;了解数据仓库逻辑架构,了解ETL流程、元数据管理、数据质量监控等数据仓库主要环节;
  2. Java开发:三年以上Java开发
  3. 支付产品经理: 负责支付产品(熟悉支付行业常见支付工具及逻辑)、增值产品(增加用户积极性和参与度,提升产品新增用户量和使用度)

3. 银杏树公司【北京】

  1. 产品经理,熟悉银行对公业务,能组织相关软件产品的需求调研和项目开发组织,有区块链技术背景更优先;
  2. 行业售前专家,对象是行业B2B平台,熟悉B2B交易场景和供应链金融,能写能讲;
  3. 软件开发高级工程师,熟悉java后台开发和数据库技术,有银行后台应用开发经验的优先

4. 51信用卡【杭州】

简历发送到邮箱: thq_recruit@163.com

  1. Java开发工程师:3年以上的Java开发经验,对技术有热情和追求;有扎实的java基础,熟悉分布式,缓存,异步消息等技术的原理,能对分布式常用技术进行合理应用,解决问题;熟练运用Spring,MyBatis等框架进行开发工作;掌握多线程及高性能的设计与编码及性能调优;有高并发应用开发经验优先;
  2. Java开发架构师:精通Java语言,对相关技术领域的开源产品有深入的理解 ;精通领域建模,熟悉主流技术架构体系,熟悉SOA,敏捷开发等理念;熟悉缓存技术、搜索技术、异步框架、集群与负载均衡、消息系统等领域 ;具有大型分布式、高并发、高负载、高可用系统设计、开发和调优经验

5. 深圳盒子支付【深圳】

简历发送到邮箱:lidecan@iboxpay.com

  1. 支付产品经理:精通银行卡收单业务及聚合支付业务逻辑,负责清结算、账户等系统的设计及优化。
  2. 收单风控产品经理:熟悉银行卡收单业务及聚合支付业务逻辑,负责制定、完善业务风险管控机制及策略,分析并出具业务风险评估报告,有效管理关键风险指标。
  3. JAVA高工/架构师:熟悉银行卡收单业务及聚合支付业务逻辑,负责支付线核心模块与系统的设计与实现,基于JAVA技术构建分布式、跨机房、高并发、高可用的支付系统。

6. 京东金融-支付业务部【北京】

简历发送到邮箱:huangwenhao@jd.com 招java高级软件工程师2人

  1. 大学本科及以上学历,JAVA基础扎实,熟悉io、多线程、集合等基础框架,熟悉分布式、缓存、消息等机制;
  2. 5年以上使用JAVA进行web开发的经验;精通AOP、MVC等框架。熟悉web开发的相关技术:html/javascript/ajax/xml等 ;
  3. 熟悉JAVA EE规范,熟悉常用的设计模式;精通Java及Web的开发和应用;熟悉大流量、高并发、高性能的分布式系统的设计及应用、调优;
  4. 熟悉SQL,了解Mysql、Oracle等大型数据库;
  5. 熟悉Linux下的常用命令;
  6. 良好的沟通技能,团队合作能力,勤奋好学;

五、近期人才

感谢大家对公众号的关注。最近有几位资深的支付同学正在找机会:

同学A:杭州, 五年工作经验,在多个知名互联网公司参与支付系统开发工作,欢迎推荐互联网支付相关的资深工程师职位。

同学B:北京, 三年工作经验,在某知名互联网公司负责支付产品设计,欢迎推荐支付或者互金的产品经理职位。

可以在公众号下留言,或者直接联系老熊。 谢谢先。

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