前言
为什么会想写一片这样的文章呢？是因为最近跟公司测试的妹纸沟通了一下，遇上了很多系统上的问题不解，亦或者在测试过程中有一些不明其意的地方，于是稍作总结。没有发人深省的内容，也不是高深的技术干货，仅仅只是开发与测试的三两事。
起因
那天，阳光明媚，碧空万里，正好是发布版本极佳时刻，万万不能错过。当时客户在使用系统的过程中，出现了一个极其细微的bug，而这个bug需要后端Java代码支持配合才可以修复。所以我们规划发布版本解决问题。
犹记得当时测试妹纸拿着测试用的手机跑过来问我，“lennon，你能不能用手机帮我代理到开发环境来验证客户提的问题是否解决？”。刚听到这个问题，我是惊为天人，恨不能原地转360圈懵个十分钟再回答的，因为我一直都以为她们非常清楚的知道当前的系统架构。
我登时语气笃定地说，“就我们当前的生产发布环境来说，是做不到的！”，同时，我也萌发了想跟测试简单说一说系统架构，让她们能够在测试的过程中可以知其然并知其所以然。
前边提到的bug需要Java层面的代码支持配合才可以修复，并且是基于当前我们的部署环境的原因。因为很多问题的解决之道其实非常简单，但是碍于客观原因便不能做到。
DNS解析
在我们的测试/开发中，抓包工具毋庸置疑是日常最常见工具之一。当我们左手拿起手机，右手点开Charles，位的就是把www.XXX.com路径下的请求转发到诸如127.0.0.1或者test.XXX.xom。这么做的目的是为了减少打包时间，尽可能不要劳烦打包人员频繁打包出来测试。
那么在这个转发的过程，究竟发生了什么呢？为何我的生产包却可以访问到本地环境跟开发环境呢？
首先是域名解析成对应的IP地址。
- 检查浏览器是否缓存域名/IP -->
- 操作系统域名解析（host文件）-->
- 在操作系统中有个本地的域名服务器（可通过ipconfig查找） -->
- Root Server 域名服务器请求解析 -->
- 根域名服务器返回给本地域名服务器一个所查询域 的主域名服务器（gTLD，顶级域名，目前只有13，注入.com, .cn, .org） -->
- 本地域名服务器在根据上一步返回的gTLD服务器发送请求 -->
- 接受请求的gTLD服务器查找并返回次域名对应的Name Server域名服务器的地址-->
- Name Server 会查询和存储域名和IP的映射关系表，并返回给DNS域名服务器 -->
- 操作系统本地域名服务器会缓存域名与IP的对应关系 -->
- 将解析的结果返回给用户，至此域名解析的过程结束。
当我们将域名解析为对应的IP之后，我们再拿这个ip地址去访问我们的服务器。那么这里就会要求，一个IP必须只能走到一个服务器上，所以当域名解析成功之后，通过ip可以达到某一个服务器，再通过诸如lvs，nginx转发到对应的tomcat。
image.png
我们注意到，假如我们在host文件中写入127.0.0.1 www.baidu.com，当我们向www.baidu.com发起http请求的时候。所有请求就会被转发到127.0.0.1这个服务器上进行处理。这里类似于我们欺骗了浏览器，告诉它www.baidu.com对应的ip地址是127.0.0.1，但是事实上并不是，这个可以称之为域名劫持。
那么我们就可以通过Charles，将域名www.xxxx.com路径下的所有请求都转发到任意IP地址上，所以我们就可以做到拿到一个装了生产包的手机就可以访问我们的生产环境或者开发环境或者本地环境，逻辑图如下：
image.png
从该图可以非常简单的看到一般的单体架构的应用程序架构图，而实际生产环境远远比该图复杂，但是通过简单的逻辑图可以看明白生产环境与开发环境隔离的内容。
通过抓包工具，我们能做的只能是把请求转发到不同的机器上，来达到不同的访问效果。而生产的tomcat环境，Java程序，数据库等等都是与开发环境完全隔离。（一般情况下不会交叉使用，但是不排除有些公司开发生产使用同一套中间件环境，比如消息队列）
所以做不到比如当请求转发到开发环境，使用已经修复的Java程序，却想验证生产数据。（不是说做不到，只要改Java程序的数据库链接也可以做到，但是生产环境谁会这么做？）
image.png
总结
为什么测试妹纸会想到通过Charle工具在开发环境上的Java程序来验证生产环境中的数据呢？其实本质上对于我们系统的架构不了解，不明白整个运行环境。
网友评论