基础设施将支持为支付而开发的软件流程。在进入这个话题之前，让我们先谈谈软件过程。近年来，软件流程变得越来越不受欢迎。在一些互联网公司中，软件过程的概念往往被等同于拖延、拖延和冗长。他们倾向于将他们的软件流程标记为敏捷，并为各种混乱的管理提供了一个很好的借口。即使你先写代码，然后补充需求，你也可以用敏捷开发的借口。但是，这种例行公事对于获取财务软件不起作用，尤其是处理货币的支付系统的开发。毋庸置疑，混乱管理造成的各种漏洞很容易吸引各行各业的攻击者，它们也需要开发者遵守一些底线，以便与各种银行渠道对接。事实上，在各大互联网和第三方支付公司中，支付系统的开发一直进行着最严格的流程管理。在公司各个项目内部竞争巨大的压力下，支付系统开发者不好意思说我们正在进行最严格的软件流程，所以系统升级缓慢。那么，如何在保证过程质量的前提下，在保证系统不断发展和升级的同时，提高系统的质量，避免漏洞，降低风险呢？

从案例开始

支付系统的开发过程与其他系统有什么区别？对于今天的大多数公司来说，通用系统的开发人员都是所谓的全栈工程师：从编写前端和后端代码、测试、上线到运营。如果在线上有bug，登录服务器并查看日志以找到原因，或者直接去数据库更改编号。但这些行为对于支付系统来说都是禁忌。介绍一个真实案例，某游戏公司的技术合伙人在开发过程中，将一些偏远省份的收单账号更换为自己的账号。一年多来没有人找到它。直到有一天，一位投资者出差到某个省份，使用这个系统进行付款，发现收款公司的名称与原来的公司略有不同。这位细心的投资者要求公司调查此事，却发现这很无聊。

如果开发者用自己的账户替换接收账户怎么办？您会修改数据库以向您的帐户余额添加更多零吗？这些都是真正的问题，而且都已经完成了。虽然人与人之间还是需要基本的信任，但支付系统的基础从来就不是建立在信任的基础上，而是用最大的恶意来揣摩人性，从而存在可以利用的漏洞。因此，对于支付系统的发展，通俗地说，有这样的要求：发展不是在线的;网上没有发展。也就是说，开发人员不能参与实时和在线系统的运行。在这种情况下，如何保证开发的系统能够顺利启动，又如何保证在线系统在出现问题时能够第一时间诊断和解决？这需要一系列的基础设施支持。

微服务和自动化

传统软件流程的一大问题是，所有阶段都需要人工干预。引入微服务架构背后的想法是通过降低系统的复杂性来实现流程自动化。在这方面，首先提出了在极限编程（敏捷）中使用持续集成的思想。在微服务架构之后，提出了持续交付的概念。微服务架构如何支持这些流程，可以参考相关资料，本文不再详细介绍。而从支付系统来看，其基础设施建设又有什么不同呢？如果从微服务的角度来看，它和其他业务系统开发没什么区别。只是要求更严格。建设的原则也是。人们管理代码，代码管机。通过流程自动化，逐步消除软件过程中的人工干预，加速迭代，提高质量。

如何衡量支付系统基础设施建设的成熟度？我们无法查看诸如部署了多少软件以及使用了多少台机器之类的硬性指标。敏捷开发中的一些最新思想可以帮助我们定性地衡量这种进展。软件开发过程包括编码、构建、集成、测试、交付（预发布）和部署。我们可以用这个过程的自动化程度来衡量基础设施发展的阶段。

持续集成、持续交付和持续部署对应于自动化软件过程的三个阶段。持续集成，自动化编译、发布、集成编译，最后自动部署到集成测试环境。测试完成后，需要人工验证并上线。另一方面，持续交付更进一步，在自动化测试的基础上，支持自动部署到暂存环境。在确认准在线环境满足在线使用需求后，手动部署到在线环境中。持续部署是自动化的最终目标，一旦开发出来，系统就可以自动在线验证和实施。

无论处于哪个阶段，它都需要得到自动化基础设施的支持。以下是主要的基础设施软件及其选择。

版本控制

版本控制是所有自动化工作的基础。国内大部分企业都完成了从 git 的转型，git 已经成为版本控制的标准配置。支付系统在版本控制方面与其他系统没有太大区别。这里需要描述的是微服务架构的版本控制。我们知道，在版本控制方面，代码合并是一场难以避免的噩梦。微服务可以很好的解决这个问题，因为服务的粒度很小，每次更改一次，一个人就可以做。每个服务都可以独立启动，以避免修改冲突。这使得版本控制相对简单：

代码审查

支付系统中的每一行代码都经过审计！代码审查对于支付很重要，是避免恶意代码不可或缺的一部分。一般来说，付款代码必须得到至少 2 人的批准。代码需要每天审查，而不是在发布之前统一审查。审计工具通常需要与版本控制集成。在 git 上，git 或。虽然是一个比较新的系统，但还是推荐使用的，它可以强制代码审查，控制代码审查过程，确保两个人都没事后才能进仓库。

它的优点是可以针对所使用的系统进行扩展。默认情况下，不支持强制代码审查。但是，如果不强制执行代码审查，开发人员将能够在没有代码视图的情况下提交其代码。未能及时编码也会影响进度。此外，开发人员在不执行代码审计的情况下提交代码是很常见的。好消息是有非常好的可扩展性，可以根据需要实现各种额外的功能。它是一个扩展点，通过用户提供的对 HTTP 请求的回调来侦听 git push、 和其他事件。例如，可能需要至少两个 LGFM（）。通过监听，两个 LGFM 被聚合并自动上传代码。

代码审计

或者静态代码审查。PMD这两者都是常用的工具，推荐使用系统，可以用来实现集成，也可以有一个web UI来检查代码质量。提供的审核规则也很全面，可以根据公司的需要进行定制。

日志收集和分析

支付系统的原则是，发展学生不接触在线系统。如果在线系统出现问题，我该怎么办？开发者总是依靠日志来排查问题，而日志聚合系统是支付平台必备的基础设施。考虑到日志最终需要合并到一个日志仓库中，这个仓库可以有很多用途，特别是对于日常维护中的日志查询工作。大多数指标都可以在日志上计算。借助此系统，还可以进行监控：

日志是通过 、 汇总 和 最后通常归档的。也可以进行统计分析，但不建议这样做。通过使用组件访问完成监控指标的提取和计算，并将结果推送到服务器，可以实现可扩展的监控。 并且可用于日志采集，从实际使用情况来看，两者在性能上并没有太大的差异。这是一个Java系统，它是一个Ruby系统。使用它涉及到系统的扩展，具体取决于您可以持有的语言。 是否有必要在数据库的两个日志中间添加一层，即写入HDFS等？日志直接存储在数据库中是非常必要的，将来分析将仅限于这个库。引入后，您可以对需要日志数据的应用程序执行准实时数据流分析，并将结果保存到所需的数据库中。

系统监控

现在它基本上是监控的标准。传统的监控实现部署在被监控的机器上，从日志中收集所需的数据，分析监控指标，并将其发送到服务器。

此方法要求在每台计算机上部署一个客户端，并配置一个数据收集脚本。可以将部署与操作系统一起作为必需软件进行安装。

持续集成

毫无疑问，CI 是要走的路。但这只是一个工具，如何使用它还得与业务相结合才能实现。面对上面列出的如此多的工具和使用要求，如何确保开发人员实现代码并尽可能自动化代码的一种解决方案是将这些活动与集成工具串在一起。我不会详细介绍这个原则，也不会在这里详细介绍它所带来的不满和不满，而是重点介绍如何使用它。使用的关键点是设置每个作业。作业设置分为联机作业和测试作业。测试环境作业分为三组：部署、启动和停止。在线分为四组：预部署、部署、启动和停止。在每个组中，每个项目对应一个可执行作业。

在测试环境中部署并执行以下操作：

在线环境部署如下：

本文仅为上述支付系统涉及的主要基础设施的初稿，其他基本设置将在未来逐步完善。也欢迎您添加和改进。如需最新版本，请单击“查看原文”以获取。