大背景

说需求不讲背景就是耍流氓。 ———– by 一个被虐的码农

那么，背景是这样的，公司现有的测试业务情况如实交代：

  • 局域网自建mongo数据库，用于业务的测试环境数据（IP：192.168.2.100，电信公网IP 200.201.202.203，标记为服务器A）
  • 公网阿里云ECS(IP: 100.101.102.103，标记为服务器B），用于外网测试环境代码的运行，通过服务器A的公网IP来连接mongo数据库
  • 阿里云DNS配置A解析记录 dev.xxx.com 100.101.102.103
  • 在脱离公司的公网环境，需要能正常访问dev.xxx.com的服务

问题来了

运营人员抱怨各种测试服务反应很慢。噢？那么我们来研究下网络数据走向和对应的时间消耗咯

  • 运营人员使用测试服务->DNS解析dev.xxx.com->请求服务器B->通过服务器A的公网IP连接到mongo数据库->上传数据回服务器B->返回数据给和服务器A同一个公网出口的App（哇，这链条长的很开心）
  • 通过配置PHP fpm slowlog得知，发现实际上时间消耗都花在了mongo相关的连接上面了，为什么呢？？？

分析问题

我们用的电信家用宽带，100M下载带宽，上传也就那么4M，完全不能看啊，稍微查询一个大一点的数据集，传输时间够喝一壶了，而且这么4M带宽，还要服务于公司员工正常的上网需求，那么降低这里的上传带宽使用也是很有必要的。

选定方案

so，找到问题了，光说有什么用，得有解决方案啊

  • 把数据库也扔到外网去，那么对整个公司局域网来说，主要消耗只有对公网服务器B的请求下行数据，然而mongo对硬件消耗有点大，作为一个测试环境来讲，升级硬件配置或者再开一台服务器难免有点资源浪费，退而求其次，合理利用局域网服务器做mongo服务才是正路
  • 服务器A硬件配置是强于ECS好多倍的，不要浪费了，那么就在服务器A上面搞事吧
  • 通过分析上面的请求路径，那么我们可以把服务器A的公网上传拦截掉，怎么拦截呢？从DNS上面动手，于是请求路径会变成：APP->解析dev.xxx.com->请求服务器A（192.168.2.100）->服务器A的程序请求localhost的数据库->返回数据给程序->返回给同一个局域网的运营测试人员
  • 这样一来，速度提升的有点可怕，运营人员再也不腰痛了

解决问题

既然有初步方案了，那么怎么解决？

  • 那么需要使用“提速”的运营人员，可以通过配置HOST来实现 dev.xxx.com 解析成 192.168.2.100，如果只有PC平台的产品，倒也不失为一种选择
  • 移动设备怎么办？Android不root，iOS不root没法玩啊，除非这些测试机器允许以某种方式“模拟配置host”，比如Android读取sd卡某个文件，若定义了解析数据，则以解析结果为准，需要预埋代码，改起来也麻烦，一点也不优雅
  • 移动设备实在没办法改呢？那我配置代理咯，代理设备请求到能改HOST的PC设备，也是麻烦
  • 既然这么蛋疼，那我配置一个DNS服务器好了，一番搜索之后，unbound这个软件上场了，配置一个DNS服务器，使用标准端口53，将局域网所有需要”提速“的设备首选DNS改成192.168.2.100即可
  • 本着优化应该对使用者透明的原则，把上面这个配置DNS的步骤也省了，直接用DHCP服务器返回192.168.2.100作为首选DNS

断一下网，重新连接，刷新页面，一切只如初见，那么美好~

题外话

有人说，为了性价比，透明解决问题，为何不把所有服务都放在局域网的服务器A上面，连买ECS的钱都省了。。。

骚年，你还是太年轻

  • 电信运营商怎能允许家用宽带用来做服务器提供服务这种行为，那么谁购买他高贵的企业专线带宽呢？于是我们家用宽带的80端口、8080端口默认都是被封了。
  • 就算运营商不搞事，国家要求所有IDC必须只对有域名备案信息的域名才能提供正常的服务，就算配置了解析，在访问到具体的IP的时候，也是一样不能正常访问你的业务，从这个角度来讲，电信运营商封锁这两个端口也算是为了规避备案问题。
  • 改端口也不是不行，然而综合考虑，改端口方案导致各个业务都需要做额外的配置修改，还是买个ECS做外网测试业务简单粗暴

那么其实除了上面的DNS方案，还有没有其他方案？答案是有的，理论上通过配置路由表SNAT，把对服务器B（100.101.102.103）的流量请求转发到服务器A192.168.2.100，然而该方案似乎有点一刀切，不够灵活，还是留着DNS，需要这种访问链路优化的话，配置首选DNS服务器为192.168.2.100，不需要的时候或者想强行访问服务器B的逻辑，那么只需要配置其他公用DNS即可。

UPDATE 2017-09-05

由于在实际使用过程中（大概1个多月的持续时长），发现对于不甚了解原理的小伙伴来讲，有额外的理解成本，业务也准备上HTTPS访问，那么就又来搞事吧，于是改为下面的方式：

  • 仅保留局域网服务器A，全部使用Let’s Encrypt部署HTTPS访问（电信没封443端口），局域网访问可以使用HTTP或者HTTPS，而公网访问就只有HTTPS能通啦- -
  • unbound DNS配置依然保留
  • 路由表在另外一个服务器上面，暂时未变动