我在M2公司做架构之某网与Webservice

做任何系统都会有数据来源这个词,数据来源既可能来源于系统运转的过程中,也可来源于第三方数据推送或者具体数据文件的录入等。

一、主动模式/被动模式

这是我所负责的工作之一,负责对接第三方某网数据,在对接过程中,产生了两种方式,一种是主动模式,另外一种是被动模式。所谓主动模式,就是对方提供API,我通过API去取数据,然后再通过特定算法进行数据入库。所谓被动模式,就是我方提供API,对方将数据推送过来。主动模式和被动模式的一个主要区别在于主动权方面,如果是对方提供API,我方每天想怎么取数据就怎么取数据,如果是被动模式,那么我方需要被动等待对方推送,当然了,推送的规则是由我方制定。这两种方式均在我与某网的对接过程中落地过。最终,由于一些客观因素,采用了被动模式。

二、XML或JSON

确定模式之后,接下来就该定数据格式,究竟是XML呢?还是JSON?如果是XML的话,需要采用WebService,如果是JSON,则采用RestFul。WebService基于SOAP,而RestFul基于Http。

最初采用WebService,于是就有了下面的文章:
SpringBoot整合Apache-CXF实践
WebService安全机制的思考与实践

最终技术顾问提供了一个API文档,加上相关的讨论,最终放弃了WebService,转而使用RestFul的方式。这种方式非常常规且普遍,这里就不做具体说明了。

三、与某网联调的过程中出现了哪些问题?

  • Nginx请求体数据限制;
  • 特殊加解密算法对数据的加解密;
  • 参数校验不完善。

Nginx请求体数据限制,通过调整请求体数据限制即可解决,文章如下:
413 Request Entity Too Large

至于特殊的加解密算法对数据的加解密问题以及参数校验不完善,基本上是属于代码性质的问题,就从代码层面进行优化处理。

四、实际中某网数据推送过程中出现了哪些问题?

1.某网问题

  • 数据服务器换了域名导致数据无法推送;
  • IDC机器网格故障导致数据请求不到;
  • 数据服务器访问权限问题;
  • 数据接口问题;
  • 服务器网络问题;
  • 内部某产品故障。

2.我方问题

  • 服务之间的调用(将请求数据初步解密后组装并请求给数据处理微服务进行入库);
  • 第三方数据请求日志的存储。

我方的问题很容易就能处理,但某网的问题很难处理,也许是历史遗留的东西太多了,导致时不时就出现这些问题,这给我们的启示是:当我们成了数据API的提供者时,不论是我方推送数据,还是彼方从我方拿数据,相关的API设计一定要考虑全面,这个全面不仅仅是指安全性方面,同样也指故障处理机制方面。

文章目录
  1. 一、主动模式/被动模式
  2. 二、XML或JSON
  3. 三、与某网联调的过程中出现了哪些问题?
  4. 四、实际中某网数据推送过程中出现了哪些问题?
    1. 1.某网问题
    2. 2.我方问题