聚合支付系建设的一些经验.docx

聚合支付系统建设的一些经验付钱拉介绍付钱拉致力于为中小微企业或者创业者提供一站式金融服务和解决方案，开发者仅需几行简单代码就能同时接入主流支付服务商，轻松实现收款。付钱拉已服务近2000家中小微企业，服务包括聚合支付、线下扫码、鉴权服务、资金管理、银行流水、征信报告、余额增值、理财超市、供应链金融、企业理财、监控服务、生活缴费、分期付款等13种金融云解决方案。作者冯忠旗，付钱拉高级技术经理，曾经是IBM中国开发中心IaaS私有云技术负责人。2014年加入付钱拉，主导付钱拉技术平台的研发和负责平台相关的实时预警系统、报表系统、电商服务解决方案和理财服务解决方案等。个人比较关注高并发、高可用的架构设计，对分布式系统建设过程中的业务拆分、分库分表、消息队列、性能调优等方面有深入研究和实践经验，有团队管理经验，热衷于技术研究和分享。引言目前付钱拉系统日处理交易额200多亿，每天平均交易量400万笔，业务类型线上线下各不相同，作为一个资金交易系统，为了保证系统高可用和资金交易安全，付钱拉填过不少坑。本文通过真实案例和切身实战经验来描述付钱拉走过的这些坑，希望正在经历像付钱拉（创业团队或者中小初创团队）曾经一样面临这些问题的团队能够提早避免。任何系统建设从0到1相对比较简单，但是要做到从有到好或者更好那就比较不容易，比如经常发现开发同事开发一个新功能，自己单元测试通过就提测了，到了测试那里一堆问题，主要原因是好多时候开发人员只保证了代码主分支业务没有问题，但是异常分支业务都没有考虑就提测了，代码的异常分支处理才是代码逻辑最需要考虑的点。本文会从两个个角度展开描述，一个是针对已经存在的系统如何主动发现问题，另外一个是基于系统建设过程中不同项目阶段的问题描述。常见问题开发人员如何提高代码质量，减少频繁迭代产生的bug？线上环境突发事故，第一时间如何决策减少事故影响范围？开发人员排查问题速度过慢？随着业务的增长，问题越来越多，第一优先级需要解决什么？系统突然CPU、内存利用率暴增，如何定位代码？数据库连接数被耗尽，怎么办？各种OOM如何预防？随着系统交易量的增加，高可用系统的设计点很多，如何快速抓住建设要点？......通过本文的阅读，会对这些问题在不同的地方给出答案。从操作系统层面发现业务系统问题墨菲定律中提到会出错的总会出错，代码的bug也一样，会发生的一定会发生，只是看在哪种场景下会触发。未运行的代码是静止的，只有运行中的代码才能能真实地体现业务系统的状况，如何不阅读代码从操作系统层面去发现正在运行的代码问题是非常必要的。无论多复杂的系统运行在linux之上无非就是一个进程，进程下面又由多个线程去执行每一行代码的业务逻辑，所以从操作系统层面只需要关注进程和线程即可。对于java编写的应用主要性能关注点是操作系统CPU和内存两个指标，在运行中的代码内存比CPU更加容易出问题。为什么java编写的代码内存比较容易出问题呢？如今硬件效率的提升导致（CPU的速度和支持多任务）处理器运算速度和和存储设备不是同一个量级，计算机都不得不加入一层高速缓存来作为内存与处理器之间的缓冲，缓存的引入提升了效率，但是带来一致性问题，程序的复杂度也增加了，比如java主内存和工作内存同步问题。如何从操作系统级别发现一些问题？了解应用和外部接口有哪些交互？是否有异常现象？应用除了处理本身代码逻辑以外，往往还需要和外部服务或者接口通信。通过 netstat -anop | grep pid 就可以发现系统正在和哪些外部接口通信，比如下图中3306的端口显示系统有连接mysql数据库，并且有11个连接。系统有时候报错“has already more than max_user_connections active connections”，这时候通过此命令就可能发现有比较多的连接数，当连接数非常多的时候最大的可能是代码在不停的操作数据库或者有慢SQL导致的连接不释放，也就是说当你发现应用连接数大于日常正常数量的时候，系统的代码可能就有问题。同理，下面第二张图通过netstat -anop | grep 6379得知应用有连接redis.线程数异常？任何资源都是有限的，应用设计的时候需要考虑资源限制才能避免应用在某些时候因为资源过度使用而奔溃，线程数的控制就非常重要。线程的无限制创建，最终导致其不可控，特别是隐藏在代码中的创建线程方法。当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换，Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换，这时候体现在操作系统层面一种现象是下图中load average过高，这个值多少合适一般和cpu个数有关系，假如有两个cpu