至暗时刻的一丝曙光：关于对接银行项目的一些感悟（续）

前言

上一次更新银行的文章，已经3个月之前的事情了，没想到这事儿居然还有续集，当时说的啥来着

现在看来，还是太天真了，回首望去，那时的项目进度估计才堪堪走了一小半…（笑哭），本人也从一个懵懂无知的少年，变成了一个饱经沧桑的大叔（项目经理亲口描述，哈哈）

那么后面这几个月，银行的项目实施过程中又经历了哪些磨难与挑战，以及如何避免在以后接到类似银行的项目时疯狂踩坑。在本篇中将会（以个人开发者的视角）一一描述。（里面的很多内容，单拿出来都可以写成一篇篇独立的技术文章，这个以后再慢慢整理～）

（由于行内的材料，图片无法也不可以放到外面，故而本篇中更多的还是以文字的形式进行描述）

ps. 在行外验证过的东西，拿到行内不一定就没问题。

开发

关于开发模式，这3个月来有了一些新的理解（下面是之前一篇文章写的）

具体一点来说，不论如何进行开发，所有的代码开发最好是放在一个仓库中进行，要么统一在行外做完，拿到行内后只做调试。要么就统一直接全部在行内进行开发。

这块已经吃了一个大亏了，因为最初的开发是行内，行外同时推进（为了赶进度，支援的同事在场外协助开发）。如此这般，最后在合并代码（行外往行内倒入）的时候，将会有非常恐怖的工作量在等着你，并且十分容易出错（每同步一次代码我都要吐二两血）。

部署方面

事实证明，系统环境可能会成为阻碍项目推进的最大问题（自信点，把可能去掉）

部署方案的限制

貌似银行，政府，国企之类安全等级非常高的企业，在云容器部署这块都会自己搭建一套用于容器管理、发布的平台。不得不说，我目前接触并使用的这个云容器管理平台真的很难用。

如果可以，尽量申请k8s终端的操作权限（这个貌似上一篇已经提过了～）

资源申请的限制

对于一些性能要求比较高的服务，行内是不允许部署到k8s集群上的，因为行内单个容器的基本资源无法申请理论上无法超过以下配置：

• CPU：4核
• 内存：8G
• 硬盘 10G（系统运行产生的日志不计入其中）

根据行内老师的说法，容器本身是需要小而轻，而十分不幸的是，目前我们系统的报表服务，运行起来比较吃资源（通常需要16C64G，这个跟系统的设计有关）。基于这个原因，经过了长达一个月的讨论与行外测试，我们系统的部署方案由 基于k8s部署 演变成了 k8s + docker 混合部署的方案。

所谓的混合部署，即部分不吃资源的服务仍旧放在k8s容器上进行部署和管理，另一部分比较吃资源并且可能会产生大文件的服务放到虚拟机上单独部署（虚拟机的申请资源大小限制相对比较宽松）

方案经过验证是可行的，但是随之而来的是服务管理成本的大幅提高，之前可以经由k8s统一管理，而现在则需要额外对那些虚拟机进行单独的管理。

（PS. 部署方案变更后由于场面已经控制不住，让公司运维的同学接手了～）

网络环境的限制

行内的网络环境也是一个十分需要注意的点，行内对于网络访问的把控十分严格。不同业务部，甚至是不同办公室之间使用的网段都是经过严格划分的，换句话说，在不申请的情况下，你无法访问你所在的网段以外的网络。

使用长连接需要注意的点

另外，行内不同环境的服务器之间也存在着错综复杂的防火墙。

比如我们（在云上容器）的服务在运行期间访问（在云下虚拟机）数据库时会偶尔出现连接超时的问题。

最终排查的结果是，容器与虚拟机之前存在一道防火墙，按照行内的解释，当长连接空闲超过4分钟之后，防火墙会把这个连接置为一个虚链接。具体原理不是很清楚，直接来说就是服务之间的长连接会继续保持，但无法再继续发送/接收消息了

我们自己的长连接keepalive时间设置的是5分钟，刚好超过了行内防火墙时间 = =…当时真的是排查了许久～

关于keepalive时间的设置，redis在配置中就提供了相关的选项，而mongo则可以配置基于系统的keepalive，具体操作就不详细描述了，Google一下就行。

静态资源共享

挂载

系统在运行过程中，有生成静态文件的需求，基于docker-compose和k8s部署都有实现静态资源文件共享的方案，从最基础的nfs，到NAS以及对象存储（OSS）的挂载。

使用SDK

然而事情有时候并不会像想象的那般顺利，除了进行挂载以外，你可能不得不接受以使用SDK的方式实现文件的共享。但是如果这一项改动带来的过高的成本的话，还是需要尽力争取稳定性和集成度更高的方案（虽然挂载的性能在一定的程度上确实不如SDK）

测试

纵使行内有各种各样的大坑，但在测试方面，确实还是有值得一提和借鉴的地方。
系统在不同环境下部署，需要接受的测试也大不相同，主要就分为一下三个部分，其中不乏一些最差及最佳实践在其中。

SIT（集成）测试

SIT相当于开发环境，系统还处在开发推进的过程当中，这个阶段主要依赖于开发人员的自测。由于不会有其他用户使用，故而不管是调试还是查看系统日志，以及定位一些功能上的问题都是非常方便的。

UAT（验收）测试

在这个阶段，就会有测试的老师开始介入，对系统进行全面的测试（主要为功能测试，说白了就是页面点点点）。

这个时候会有大量前期定下的测试用例开始推进，涉及到服务的方方面面，以及部分极端的场景。开发所需要的做的就是快速响应并修复（通常在T+1时间内完成）用例执行过程中出现的问题，让后续测试顺利推进下去

点点点的灾难

针对与系统的基础功能及新开发的一些定制模块，行内专门召集了一批测试的老师针对各个模块进行业务模型的分析，编写不同场景下的测试案例，这些案例通常会有上千个。

这里有一个矛盾点，如果测试用例中出现了不能通过页面操作执行的功能，比如需要测试一些定时任务，在时间紧张的情况下，需要开发修改代码快速模拟场景达到测试的需求。针对一些包含时间的逻辑，频繁的修改代码虽然能够保证测试需求，但是也会占用大量开发的时间（本人在配合测试人员推进测试用例时就遇到了这样的问题，需要频繁的修改处理时间的代码以快速响应测试的场景用例）

这还会带来另外两个问题，首先，频繁的代码修改可能会引起跟预期不符的结果（可能当时看上去是正确的）；其次，这些改动在测试完成后都是需要进行还原的，这里就存在一个还原可能会漏掉代码的风险点。

PT（压力 / 稳定性）测试

行内在性能测试方面做的可以说是很不错的（确切来讲，是行内花钱请来做性能测试的厂商很专业），这里简单描述一下整个测试的过程以及如何排查。

每次调优的过程都可以单独出一篇文章了，这些内容就放到后续的写作当中。

首先确认哪些服务需要进行压力测试，主要分为网页测试和接口测试。网页的测试可以通过roadrunner或者JMeter对待测服务进行网页脚本的录制，接口测试则也是使用类似的工具。

测试过程也被成为发压，即在一定并发用户数下不间断请求，并查看系统处理的响应时间，CPU / 内存使用率，从而判断系统是否达标。

下面简单梳理一下几个系统测试不达标的问题及相应的解决方案（出现的问题只针对本项目，不排除其他问题导致系统性能不达标，已排除机器资源不够的情况）。

数据库服务器CPU过高

通过top命令查询，发现确实是数据库进程占用了大量的CPU，那么，什么时候数据库会消耗如此多的资源资源呢，主要体现在两个方面：

1. 大量请求打到了数据库
2. 出现了慢查询

针对第一个问题，我们通过查看数据库的连接数进行判断。如果确实是因为请求过多，我们可以考虑给对应的模块加缓存来缓解数据库的压力

针对第二个问题，则可以通过分析数据库的慢查询日志进行分析。如果在日志中出现类似于FULL SCAN（全表扫描）等字眼，则可以判定是查询操作下数据遍历数据导致占用过高的资源（大数据量下数据库遍历非常耗时且吃资源）。那么对于这个问题，我们可以用过给对应的表添加索引来解决。索引的添加也是比较有讲究的，需要符合最左匹配原则，并且尽量使用覆盖索引以减少回表的操作。

系统运行服务器CPU过高

如果服务器在处理请求的过程中出现了CPU使用率过高的情况，通常可能的原因为：

1. 出现了大量的IO操作
2. 没有充分利用系统的资源

排查过程中发现由于线上的日志等级较低，在较大的并发下，系统疯狂的输出日志导致了CPU使用率超标。

系统采用的是协程 + 多进程的标准配置方案，在此模式下，服务启动的进程数量最好是要和系统的CPU核数据量一致，才能够让处理性能最大化。

接口响应时长超标

上面两个问题如果都解决了，那么这个问题应该也能够解决掉了。如果依旧超时，可以考虑横向拓展服务模块增加请求的处理能力。

间歇性CPU冲高

这个问题的话，数据库和系统服务都可能会有，主要看系统有没有类似定时任务这样的东西。可能会在固定或者一个比较规律的时间上执行，如果这个任务本身比较耗时或者没优化好，就会导致服务的CPU资源被疯狂消耗。

安全测试

这块主要是公司其他大佬在负责，我了解的不是很详细，讲一些我知道的点。

首先，银行对代码实现的安全性要求非常高，我们系统的代码拿到行内扫描的时候，就被扫出了50+的安全问题（前后端都有，其中红线问题累计16个），影响范围比较广的有如下几个：

1. 大量使用了eval
2. 配置代码中存在敏感信息（e.g. 用户信息，明文密码…）
3. 明文传输用户敏感信息
4. 网站请求没有遵循 SCP 策略，及网络安全政策

具体的就暂时不展开来讲了，后续会在本篇基础上继续更新，有兴趣的可以自行查阅相关资料。

吐槽：并行测试，多点爆炸

由于时间上非常的赶，行内老师想出了一个骚操作，在功能尚未完成的基础上，UAT测试、压力测试、开发三者并行。

如果说经过上千个UAT用例测试的代码是稳固的城墙的话，并行开发的过程中新增的代码就是一个个不可控的风险点，犹如一颗颗地雷一样埋进了城墙当中，在适当的时候，引起连环爆炸。

至于压测，则有点巧妇难为无米之炊的感觉，功能都没开发完整的情况就开始了测试，那之后出来的报告又有几分可信度呢？

文档

最后项目要上线了，各种上线材料及文档必须相应的跟上。这需要业务，开发，运维三方共同协作完成。主要需要有的是：

1. 部署文档（运维）
2. 项目初始化文档（开发）
3. 功能模块说明文档（业务，开发）
4. 数据库文档（开发）
5. 其他

由于项目最后的部署及操作都要交给行内的人来执行，这些文档必须要写的极为详细，否则到时候出问题，麻烦的还是自己。

结语（和一些吐槽）

还有八天，2020年就要结束了，我负责跟进的这个银行的项目也终于要接近尾声（这次是真的尾声）。我本人在这个项目结束后，也选择了离开。不夸张的说，银行的这个项目给予了我前所未有的压力（996的工作强度在这个项目下不值一提，007是常态，并且一直要与低效的开发环境和沟通环境做斗争），也促使我极大的成长了一波（主要是心态上的）。

曾经的数个夜晚，我因为巨大的压力（开发时间压缩再压缩，大量的任务仍待完成）而崩溃，第二天又暗自发誓，一定要全力推进，保证项目上线，这样的过程周而复始。那句毒鸡汤说得好：

那些打不倒你的，终将使你变得更加强大！

但是也不能头铁，毕竟身体健康最重要，此时，另一句话就显得非常适用了

逃避虽然可耻但很有用

换个环境，带来可能就是另一次蜕变～用马保国老师的话来讲，就是三个字：

接！ 化！ 发！

最后放个马老师照片镇场子，谢谢大家（抱拳）！

更新

2020-11-28

1. 针对测试方面增加了一些描述和感想（集成测试和安全测试）