Proxy系统架构升级
为什么要使用代理？
爬虫是个高风险行业，如果操作不当，很容易造成“攻击”假象，给数据源技术部门带来很多麻烦。另外随着大家的安全意识逐步提高，风控标准也越来越严。为了避免身份被识别，请求外部数据接口时，通常会用“马甲”，也就“代理”的方式，与目标网站请求交互。
交互流程
•信息上报
代理服务器本地启动一个常驻进程，周期频率上报心跳信息
•服务端接收请求，参数解析
获取ip和port，查询记录，如果为空则标记为首次注册，并记录注册时间。后续上报的都是心跳维护，记录最后心跳时间。直到下一次拨号，重新循环
•阶段识别、处理
后台配置 “可用时间”、“延迟时间”、“代理过期”。通过最后心跳时间减去注册时间得到的值，查询在时间轴的位置
【可用时间】：如果处于该时间区段内，爬虫调度框架可以接口获取并使用
【延迟时间】：主要是为了临界点取到ip后，延缓一段时间，不至于马上失效
【代理过期】：也称为“不可用”，满足公式“最后一次心跳 - 注册时间 > 【可用时间】+【延迟时间】”，此时代理的生命周期已经结束，需要向代理服务器发出重连指令，生成新的ip和端口。轮询任务来控制。
轮询任务
•【轮询任务】，扫描出记录满足条件，最后一次心跳 - 注册时间 > 【可用时间】+【延迟时间】
a）标记代理不可用 b）向代理服务器发出重连指令，生成新的ip和端口
•【轮询任务】，ping机房到代理的网络是否通畅
a）如果 timeout，设置为不可用
•【轮询任务】，检测代理是否过长时间没有心跳
a）now-上一次心跳的时间 > 心跳周期 * 2（即超过2个心跳周期没有接收到代理机的心跳请求），标记代理不可用 b）now-上一次心跳的时间 > 心跳周期 * 6，向代理服务器发出重连指令，生成新的ip和端口
架构升级
背景
之前系统是用go语言开发的，代码混乱，扩展性差，且经常宕机，线上报警
另外团队技术栈主用java，会go的较少，无论开发新功能还是日常维护，存在很大的资源风险。
升级方案
请求双写
最好的方式是代理服务器那边代码改动，将数据同时上传到新、老系统。但那部分的代码是C写的，之前团队规范有些欠缺，源代码找不到了。
所以只能退而求其次，改go 系统的代码，将请求流量同步一份到新系统中，走内部域名
读切换
观察一段时间后，没什么问题。开始切读流量
第一步：先找非核心应用，修改URL地址，从新系统接口获取代理ip
第二步：观察一段时间，没问题，范围开始扩大，逐步切换其他系统，将大部分流量打到新系统
写切换
代理机心跳上报的流量打到新系统中，由于历史原因，只能从DNS解析入手。但有很大风险，除了写接口用的外部域名，很多代理查询也是走的外部域名，涉及接口较多，还是担心有问题，方案需要支持回滚
所以 ，java 新系统的注册接口也做了适配，支持流量回溯到GO 系统，数据备份，以备回滚。
特别注意：设计方案时，考虑到后面会有域名解析导致的流量切换，涉及很多接口，一切全切，所以设计新系统的接口路径、入参、出参规范完全和老系统一样，这样可以做到流量的平滑切换！
双写下线
观察一段时间，如果线上运行正常，对GO老系统的写请求下线
对Go系统的线上服务器资源回收