对接某东南亚银行时,发现其中一个银行的超时率比较高。

联系银行后,得到的反馈是那边处理的很快,接到请求时就很晚了。 抓包和日志做综合对比,发现是产生日志十秒后,才开始有TCP的SYN握手包,后面的ACK和HTTPS的handshake都是正常的。

怀疑两种可能: 1、域名解析慢。 2、代码有问题,处理有队列或有等待连接池资源等问题。

考虑到这个通道的量比较少,队列和等待连接池的概率比较低,预期大概率是解析问题。

解决方案:在服务所在服务器绑host,一直观察到第二天,确认问题暂告解决。

遗留问题:如果银行端域名解析变更,会导致服务不可用。目前仅有失败率监控,监控到问题后再处理,会有个时间差。 后续解决方案:开发域名解析缓存机制组件,周期刷新解析结果。待调研实现后补充。

目前已经有自有的支付二维码,新接入支付宝的二维码。 计划在二维码上做融合:同时支持自有的App及支付宝扫码。

支付宝的二维码内容,是一个支付宝自己的https的链接,扫描后会拉起收银台支付。 自建二维码也有类似的一套流程。

方案A:全线使用支付宝的二维码(订单码),自有App兼容。 因为会受制于支付宝,否决。

方案B:生成中间二维码,根据UA识别支付宝,自动生成支付宝的二维码中的订单URL并302跳转。实测Android和iOS通过。 后续微信之类的支付接入,也会采用类似方案。

几年前的方案,上周沟通时,忘了,备忘一下。

两种方案:
一、实时方案
按标准的HTTP协议处理,即http的Accept-Language头信息来自动匹配相关的配置文件。

二、非实时方案(周期性版本检查)
提供独立的错误码和错误信息对应的查询接口,返回指定语言的提示信息。

这两种方案都需要指定错误码,并扩展错误信息。

在Spring boot(版本1.3.1)项目中,先有一个Configuration的Class,再建另一个,发现新建的这个无法生效。老的没问题。

很偶然的改了一下方法名,就可以了。

然后证实多个Configuration下,如果存在同名的方法,就会不认。返回值不同也不行。

留下点文字,记录这个坑。

你要造一艘船,先不要雇人去收集木头,而是要先去激发人们对海洋的渴望。
这是船长的最核心的领导力。

深以为然。

偶然看到一篇文章,提到了电子证据,就拿这个公司提供的服务被法庭采信作为旁证。
简单理了一下,略长见识,只不过里面还是有一些不足。不是广告,也不是要去抹黑谁,纯做技术讨论。

给出官网:http://www.tsa.cn/
具体的操作流程文档:http://www.tsa.cn/r/cms/www/tsa/files/%E5%8F%AF%E4%BF%A1%E6%97%B6%E9%97%B4%E6%88%B3%E4%BA%92%E8%81%94%E7%BD%91%E7%94%B5%E5%AD%90%E6%95%B0%E6%8D%AE%E5%8F%96%E8%AF%81%E5%8F%8A%E5%9B%BA%E5%8C%96%E4%BF%9D%E5%85%A8%E6%93%8D%E4%BD%9C%E6%8C%87%E5%BC%95v1.pdf
操作流程文档所在页面:http://www.tsa.cn/html/dzzjghbq/

中华人民共和国电子签名法(2015年修正):http://www.miit.gov.cn/n1146285/n1146352/n3054355/n3057254/n3057259/c3868973/content.html
rfc3161官方文档:https://tools.ietf.org/html/rfc3161

操作流程文档的思路:
1、开始屏幕录像。确保中间的环境检查和后续取证操作都被录像。
2、用公安部认可的杀毒软件更新后查杀,确认无木马。
3、清缓存、cookie、自动填充等数据,确保其回到最原始状态。
4、查进程列表,事后用于确认没有非法进程。
5、检查hosts文件,确保没有绑定host。
6、确认IE浏览器没有设置代理。
7、ipconfig /all 显示完整的配置信息。
8、ping 域名,确认其合法。
9、tracert 确认其访问路径。
10、访问tsa官网,显示当前时间。
11、取证,文件放到指定目录,用官网方式生成tsa专用签名(先生成文件hash值,然后去官网引入时间戳后签名)。
12、录像文件签名,留证。

其中11和12的时间间隔足够短,来证明没有时间来改动录像,证实操作步骤的合法性。两个证据一起决定了整体的可信。
官网列举了一堆案例,来证明其可信。

- 阅读剩余部分 -