点融支付系统架构的演进
原文地址：
https://mp.weixin.qq.com/s?__biz=MzIwMDI1MTYwMQ==&mid=2651931185&idx=1&sn=a059ed23bca99bb0e0932ca9c4ec58da&chksm=8d65e38fba126a99e5f6328afba71038719038e6dd0926e684d4fd36e8a8642c67f6a9cebb1e&scene=21#wechat_redirect
自动化一切可以自动化的。这里有一些风险，一会儿会提到。简单来说，你需要自动化部署，自动化部署的前提是你需要自动化测试。自动化测试的前提是什么？你需要有一个稳定的测试环境。但是三方支付公司的测试环境通常有各种各样的问题，甚至有些三方支付公司根本不提供测试环境。这时候怎么办？我们自己写。我们在跟三方支付公司测试联调完毕以后，系统上线以后，我们会写对应的mocker，也就是我们把所有三方支付公司的请求处理都mock一遍。不过现阶段可能比较简陋，因为我们更多的是迫于业务的要求，我们更多是正向的测试，没有负向或者没有edge case，这样难免会有些问题。另外mocker会导致说，你不确定三方API是否有变更，这会带来一定的风险。我们更多依赖于支付公司不会轻易发生这样的变化。
未来我们要怎么做？我们用了一些开源框架，对于我们后续的变化会有极大的好处，比如说实时数据分析。当我们可以便捷的进行数据分析，这时候我们可以做适当的智能路由。比如说常见的场景是某一个银行把支付通路给关了，但是它并没有提前告知到支付渠道，支付渠道也不可能提前告知到我们。这个时候，我们传统来说会采用轮巡的方式，比如每五分钟或者每一分钟监测一下，这个时间段这个支付渠道大概有多少笔失败的订单、失败的原因是什么。这时候会有一个问题是说，你一定会有一个时间段的误差，也就是它未必是真实的表象。这时候如果我们有实时数据，如果我们能够做实时分析，那这个会形成一个良好的生态链路，也就是说当一个渠道真正有问题的时候，我们可以拿到第一手资料，进行第一手分析，然后做一个动态的智能切换。
最近比较火热的Serverless和Lambda架构，它的好处在哪？其实我们不需要一个stand by的server，比如说我们在考虑计费，我们在做策略试算的时候，其实我们不需要一个24小时stand by的server在那里等着某一个时间段突然爆发的请求，我们只需要说，在需要处理的时候快速的去响应快速的去处理。像Amazon提供的Lambda架构是一个理想的状态，就像刚刚说的计费，计费不需要那么实时，我甚至可以跑批处理。
如果独立开一个计费模块的话，你会发现你要一个7×24小时stand by的东西，但是它只是偶尔要处理一些东西。其实我只需要在处理的时候去获取我需要的计算机资源即可。
我们需要保证的，最核心的一点是说，我们希望保证交易的双方是可信的，交易双方的数据是不被篡改的。这个时候我们也会有区块链，相信大家知道，应该是一个理想的选择。但是区块链有一个问题是，交易双方的数据会被整个链路所有人共享。也就是说我跟某个特定银行的交易会被整个链路其他银行或者其他公司共享。虽然数据加密可以解决这个问题，但是我本身就不希望数据流向其他链路。
最近出来的Corda，提供的是分布式总帐的方案。它和区块链的区别在哪？交易数据仅存在于交易双方。当然这个还是比较新的，因为它本身的语言事件也是用Kotlin，还是比较巧的，有待考证。但是本身来，对于支付服务的演化，未来很重要的一点应该是区块链，我们希望服务可以被大家使用，我们也希望我们的服务是可信的，而且数据不被篡改。通过技术，我们应该是可以实现这样的目标。