Centos下六年前的二进制文件修改

前情提要：

       领导一天基于现实利益，答应了甲方新来的亲爸爸抽筋时候搭错筋导致的奇怪想法。

1、把原来一套运行六年多的语音呼叫系统，迁移到另外一个IDC机房；

2、迁移后跟其他的系统的服务器搞一起；

3、系统之间IP网段存在冲突，所以要对语音系统中所有服务器的IP地址进行变更，由10.0.0.0网段修改为10.0.108.0网段；

现实问题是：呼叫系统内为4套相对独立的系统，开发语言涉及C#、golang、Java、C和lua脚本，其中C#、golang开发人员离职也接近6年。改IP容易，各个程序配置项修改不易（也看出服务发现、配置中心的好处）

       拿人工资，没有办法，只能赶鸭子强行上架。经过近2周的梳理，各个配置项基本梳理完整。静候割接时刻不发生问题。

       网络准备到位（两个网段虽然相互通，却是只能配置一个IP）后，最终制定割接方案分为了4步：

1、关停不用的业务资源，相关资源关停不做变更（减少事项、爱咋咋地）；

2、割接辅助性的测试资源，看看能遇到多少坑（提前排雷、有备无患）；

3、择期割接业务G的所有11个资源，改完后做测试。一轮改下来，加上测试，花了近三个小时，（因为部分服务是本人6年前开发，各种回忆很累，相对还是简单）；

4、一周后割接剩余的Q系统和运营商对接语音网关设备。经过前面的实践，以为会一帆风顺，却印证了那句“不出意外的话，就要出意外了”。

       其中Q系统中，涉及对外呼号码做运营商和归属地判断的服务。把原来访问数据服务的IP地址编译进了可执行程序里不可配置……，不可配置害死人。好在程序报错了，提示连不上数据服务，不然要排查到死。此时，服务器已经做了IP变更，回退吗？好不容易申请的割接时间啊！还有几个其他公司的兄弟在等着呢，不能留这么一个下次再来一次，咱丢不起这个人啊。

       经过两分钟的在脑海工具箱中翻腾，两个处理办法出现在眼前。

1、将原IP也恢复出来，恢复连接，待第二天找出六年前的程序源码，修改后编译程序上新，再删除原IP（虽然脸很疼，但也不能丢命不成）。经过操作后，证明此方法可行，算是有个保底的了。

2、第二个，则是进入二进制的世界，直接修改二进制文件中的内容（好在曾经也有过相关的了解和学习）。说干就干，用工具转换后，熟悉的十六进制出现在眼前，直接修改，在一个30前添加31、后面添加38后，原来的0变成了108，删除字符串尾部预留的0000，算是对齐了，激动得往回放。打个电话测试，结果是失败了，提示了另外一个错误“ut”不认识（实际上是utf8）。考虑到这是一个go程序，好像不是以\0做字符串结尾标识。此时仿佛走到了死胡同。

       没办法，本就不多的脑细胞死了一半，就先用第一个方法恢复吧，早点睡觉，睡着后在梦里还可以认真想想办法。

       顺利测试，度过一夜后。找遍代码库，终于找到了源码。要先恢复一个golang编译环境，之前的开发框架都到V3版本了，之前的依赖包要花点时间找找。累、累、累

       说时迟、灵光乍现的时候就到了。找个文本编辑器，把“10.0.0.xx”和“127.0.0.1”写在两行，发现字符长度是相等的，都是9个字符，服务跟依赖的数据服务本就部署在同一个虚拟机下，这不正好可以替换掉吗？不会又遇到其他go的制约项吧？不管了，先改了试试吧，坏处不多。经过两个小人的讨价还价，最终达成一致：试试。是的，就这样试试。谁知道下次改IP是猴年马月呢？到时候这业务是否还存在也是个问题。何况改了后，通过回环地址访问，适用性还是增强了的。

       

 手动修改后，重启测试，果然可以。果断删除原来IP，收工（最后还是贴个截图吧，感兴趣可以验证一下）