我在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设计一定要考虑全面，这个全面不仅仅是指安全性方面，同样也指故障处理机制方面。