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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券