开发环境和线上环境平滑对接的思路

这是学习笔记的第 1835篇文章

运维开发中很可能会碰到一些通用的环境限制问题。

比如我们是在开发环境中测试，在代码逻辑完善后推送到线上版本，目前我们的开发环境和线上环境的架构方式类似下面的形式。

其中运维系统即dbops是其中的一个节点，dbops节点不直接和线上环境对接，而是通过中控或者代理的角色来接入，而其他的外部系统对接，是系统层面的对接，是不会直接和某一个单一模块去对接的。

在这种场景下，如果网络之间存在隔离或者限制，开发环境中想测试外部接口的数据情况，几乎是不可能的。

很多时候我们都是把相关的接口数据模拟出来，然后在代码逻辑中解析对应的JSON数据格式，基本测试通过后就发布到线上。这个过程中，其实测试是没有弹性的，因为可能根据接口的输入参数返回结果会有差异，但是这些场景可能在模拟的时候不能面面俱到，另外，一旦测试不够充分，返工的代价是很高的，改动量和发布的代价相比是有很大的差异的。

而且如果在线上要分析接口对接中的问题，复杂度会高得多，线上的环境会对接很多业务场景，日志输出是比较多的，刚好对接第三方接口的输出只是其中的很小一部分，如果要在庞大的日志中去查找相应的信息，这个复杂度会是指数级的增加。

所以在这个基础上，我决定对已有的情况做一些改进策略，初步的思路是通过封装一类特殊的API来实现平滑的对接测试。 期望调用做接口对接测试在本地和在服务端的效果是一样的（目前的接口方法暂定为GET,POST）

整个设计可以改造为如下的方式：

我们定义一个内部的API,走多重认证模式，

第一层是已有的用户认证，需要专有的账号和Token设置，

第二层是通过API的调用方式来过滤，限定调用方法可以避免很多意料之外的场景。

第三层是使用白名单来过滤，不是所有的API都可以通过这种内部通道直接交互，而是API列表。

第四层是白名单信息要做定时清理，保证权限的入口是一个收敛的状态。

在这几层保证下，相对来说，我们的开发环境调用指定的API服务是相对可控的，而且调用的参数和方式保证和线上一致，这样发布的时候就可以改动最小范围的代码，能够实现平滑的业务对接。