███████ 见群龙无首,吉。
███████ 亢龙,有悔。
███████ 飞龙在天,利见大人。
███████ 或跃在渊,无咎。
███████ 君子终日乾乾,夕惕若厉,无咎。
███████ 见龙在田,利见大人。
███████ 潜龙,勿用。
███ ██ 元亨利贞。

- 阅读剩余部分 -

这是我看到的最深刻的一个解释

  • 我们经常在岸上看到水里的鸭子是悠闲安逸的缓慢游动,如果有人在水下看,会发现鸭子的脚在不停的划动。
  • 久而久之,有可能这种拼命的划动,也是一种轻松

你必须拼尽全力,才能看起来毫不费力。是以无为而无所不为。

非常励志的一种解读

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

联系银行后,得到的反馈是那边处理的很快,接到请求时就很晚了。 抓包和日志做综合对比,发现是产生日志十秒后,才开始有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下,如果存在同名的方法,就会不认。返回值不同也不行。

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