记一次曲折离奇的联调

        好吧，承认自己是标题党，其实这次联调和其他许多次联调一样，没有什么曲折离奇的地方。抑或是，顺顺当当的联调是世间罕有，而跌宕起伏充满波折的联调才是常态。Who knows?反正我是一提到联调就心里犯怵，如果是多方联调，心就直接down到了谷底。闲言少叙，直接入正题，先叙述一下这次的联调背景和过程吧（为了不泄密，有些地方会虚化，见谅）。

      

        兄弟系统C和我所在的系统B，为了实现一个快速创建游戏论坛的功能，需要调整3个接口。改动不大，每个接口都只是新增了一个字段，代码改动量较小。一开始联调进行得也很顺利，双方灰常轻松地就调通了改动的仨接口。本来以为这就算完事了，我还窃喜，这么顺当的联调被我给碰上了，难得啊！容我大笑三声哈哈哈~！谁成想，麻烦事才刚刚开始。系统C反馈，接口调用成功了，我们也告诉他们论坛创建成功了，但是向我们查询该游戏的论坛信息时，我们说“sorry俺没有”，TMD这是怎么回事。国骂是没有用的，问题出现了，必须硬着头皮解决。先了解清楚整个流程：

     

        结合这个示意图简单点说，就是C系统和B系统的第一次交互是成功了，B系统和D系统的交互也成功了，但是D系统和X系统的交互是否成功未知，X系统和B系统的交互是否成功未知，且这两次交互一定有哪一步是失败了因此导致C系统第二次和B系统交互拿数据时拿不到。有人要吐槽了，为啥D系统要和X系统交互，为啥D系统不直接把论坛信息同步给B系统，而是绕了个圈去X系统那里，不好意思，这个是历史原因，且每个系统的职责不同，因此这里不作讨论。

      

        弄清楚了整个流程，初步确定了问题发生的节点，赶快就找D系统的负责人问，你们有没有向X系统通知呀，成功了没有呀，答，通知了，未成功，连接超时。于是再把X系统的人拉进讨论组，开始定位通知超时的原因。这里就稍微曲折了一点，讨论后发现通知的url是旧的ip地址，且X系统的环境挂了（@#￥%……&*），于是D系统的负责人换url，X系统的负责人部署环境，两厢OK后再次通知，还是失败。到这个节点大家头都有点大了，因为想不出理由通知不成功呀！X系统的人说自己测了系统OK，D系统的人说通知还是超时不信给你看日志。就在这离奇的当口，D系统的人发现无法telnet通X系统的ip和端口，一对，好吧，D系统的服务器ip是公网的，X系统的服务器ip是内网的，再一次@#￥%……&*。

        问题到这里其实已经明了了，网络不通，内网可以向公网发请求，但公网肯定不能向内网发请求。困扰了三方（其实是四方，C系统一直在通过我了解问题的进展）的问题终于定位。可是要怎么解决呢？由于B系统、C系统和X系统都是使用的内网（开发联调阶段都是部署在内网服务器上的），显然让D系统在内网部署一套环境就完美解决问题了。但D系统负责人说，申请不来内网服务器，而且即使申请下来了，也没有功夫维护这么多环境，希望再一次破灭（容我哭一会%>_<%），开发联调是注定不能走一个完美的全流程了。but，天不亡我，最后还是找到了解决方案！给大家30秒的时间想一下最后我们是怎么解决这个问题的……O(∩_∩)O哈哈~天才的想法侵袭了D系统的负责人，他老人家来了一句“以后开发联调时跟我说一声，我开本地服务，你们请求我本机就行了”，bingo，yeah，fantastic，wonderful！

        最后，为这曲折离奇让人哭笑不得的一次联调做个总结吧：

1.一次完整的流程尽可能减少关联系统的个数，比如现有的流程可以优化为——D系统在创建论坛成功后将论坛信息通知给B系统（或者直接就在同步响应中返回），B系统拿到论坛信息后，再通过接口推送给X系统。这样符合B系统的定位（基础数据存放系统），对创建论坛这个流程来说，闭环上少了一个系统X，大大降低了联调复杂度。

2.出现接口不通时，赶快检查是否网络问题，确认了网络是通的之后再检查应用的问题，对有内网和外网多环境的系统来说，确认这一点尤其重要。