如何快速高效地设计开发与建设聚合支付系统

如何快速高效地设计开发与建设聚合支付系统呢？下面主要从两个方面介绍。
从项目角度看业务系统问题
拿一整套聚合支付系统开发流程来说，解决问题就感觉像游戏打怪升级，并且比较有意思的现象是高级的bug一定出现在低级的bug之后，只有解决了低级的bug，才会出现更加高级的bug。项目周期可大致分为以下五个阶段：初创阶段（协调），普通成长阶段（质量），实时监控阶段（预警），高速发展阶段（高速扩张），成熟运行阶段（稳定），接下来从这几个阶段来分析可能遇到的问题。

初创阶段：项目初创阶段，团队属于磨合期，初期沟通低效，时间成本高。这个阶段作为技术团队首先要提高对外和对内的协作效率，对外主要沟通对象是产品和测试，对内就是技术团队内部合作问题。因为每个人考虑问题的角度不一样，这个阶段很有可能花费大量时间沟通，这个阶段各个团队的负责人至关重要，入口和出口统一的话，会解决很多问题。

普通成长阶段：系统开始迭代开发，业务正常发展，线上有用户使用，但是偶发发现有商户或用户投诉系统产品功能不完善，开发人员开发的功能有bug，其实这个时候进入了质量问题暴漏阶段，问题主要体现在产品设计有漏掉、开发代码质量不高、测试场景不充分等，所以这个时候建议有一定项目管理流程和机制，并不是一味地提倡快速迭代，因为步子迈得太大一定会容易摔跤。

实时监控阶段：如果系统没有监控，和裸奔没有什么区别，就好比你驾驶着一辆没有仪表盘的车辆，每天都提心吊胆，担心系统出问题后用户投诉。实时监控系统是所有项目人员的眼睛，有了实时监控相当于给系统撒了一张网，让系统所有的点都是可控的、预期的，给人安全感。

高速发展阶段：随着业务的前期的发展和积累，监控系统也能帮助我们看住系统，这时候业务发展稳定，可能就悄悄来到了高速发展阶段。业务量骤增导致系统并发响应慢、数据库数据量增长过快、单点故障等现象，这个时候其实遇到的问题是性能问题。
这个阶段最需要解决的就是高可用问题，优先需要做到的几点是：分布式部署、灰度发布和实时预警。分布式部署可以横向扩展避免单点故障，灰度发布可以解决上线带来的事故并且能够秒级回滚，实时预警让系统处于看管之中。

成熟运行阶段：经历了以上阶段之后，就是成熟运行阶段了。从系统来说，成熟运行阶段只关心一个问题就是线上偶发事故的响应机制。任务系统都一定会发生事故，像最近的发生的Gitlab和AWS事件，事故发生了不可怕，如何快速恢复是最重要。

从操作系统发现业务系统问题
墨菲定律中提到会出错的总会出错，代码的bug也一样，会发生的一定会发生，只是看在哪种场景下会触发。未运行的代码是静止的，只有运行中的代码才能能真实地体现业务系统的状况。无论多复杂的系统运行在linux之上无非就是一个进程，进程下面又由多个线程去执行每一行代码的业务逻辑，所以从操作系统层面只需要关注进程和线程即可。对于java编写的应用主要性能关注点是操作系统CPU和内存两个指标，在运行中的代码内存比CPU更加容易出问题。

为什么java编写的代码内存比较容易出问题呢？如今硬件效率的提升导致处理器运算速度和和存储设备不是同一个量级，计算机都不得不加入一层高速缓存来作为内存与处理器之间的缓冲，缓存的引入提升了效率，但是带来一致性问题，程序的复杂度也增加了，比如java主内存和工作内存同步问题。如何从操作系统级别发现一些问题，如：
1、应用和外部接口有哪些交互，是否有异常现象？
2、线程数据是否异常
3、检查系统瓶颈
4、检查系统应用的线程
5、观察应用GC情况
6、检查应用日志
7、检查系统应用的进程