目前团队中前后端联调是较之个人单独开发相对耗时的一个环节，主要体现在：
- beta环境下的部署时间较长。首先部署beta需要经过push分支、合并冲突、build、部署四个步骤。在不考虑分支冲突的情况下，由于白天CI服务器压力较大，以商户后台应用为例，build耗时约1-2min，部署耗时约3-5min。本地的build则相对快得多，冷部署时间则和beta服务器差不多。
- 代码迭代过程中等待时间所占比例较多。迭代具体指
代码更新 - 编译&部署 - 验证 - 代码更新的开发循环，而在beta编译和部署时间则是这个循环的大头，包括切换CI页面的时间、操作push&update的时间、等待build的时间、等待部署的时间，每一步都需要肉眼确认，无法自动化。虽然人脑上下文切换的时间如果熟练之后也挺快的，但是beta部署不像本地部署可以应用，beta部署的时间代价无法缩减。 - 其他分支可能的干扰。由于beta上存在其他并行开发的分支，如果存在分支冲突，根据冲突行数和对业务代码的了解程度的不同，则存在极不确定的merge时间，但是实际上merge步骤应该放到联调后和上线前，以保证不会因为分支上线时间的调整导致merge工作量的浪费。
本文的目的是通过将联调本地化，减少部分枯燥劳动、以及无效的等待时间，提高团队的开发效率。
业务团队目前开发的API基本是两种形式：WebAPI和RpcAPI，WebAPI通常是指以超文本传输协议（HTTP/HTTPS）为基础的API，是现代流行的对外部第三方开发者提供服务的方式。例如Github API，它的编码风格——特征状态转移（Rest）被大家视为经典；RpcAPI则是通过各类RPC协议为基础的API，各个公司的组件有所不同，团队中用的是Pigeon。
下文将分为相应的两个部分阐述。
基于Tomcat的WebAPI
为了做到本地联调，只需要确保前端能访问到后端Tomcat上的应用即可。以macOS为例，我收集了相关的资料，有些步骤是实验证明不必要的，有些步骤则是必须的。
防火墙权限和端口映射配置
【不需要】关闭系统偏好设置-安全性与隐私-防火墙
【需要】设置防火墙的端口转发和访问本机外网IP的权限。具体的设置方法不再赘述。
# 对本地IP的Tomcat默认端口8080访问重定向到80端口，这样就可以直接使用域名访问了，避免有些应用会禁止非80端口的访问。rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 80 -> 127.0.0.1 port 8080rdr pass on en0 inet proto tcp from any to 127.0.0.1 port 80 -> 127.0.0.1 port 8080# 类似的，允许外部机器通过外网IP（172.22.54.89）访问本机，顺便把8080端口重定向也设置了rdr pass on lo0 inet proto tcp from any to 172.22.54.89 port 80 -> 172.22.54.89 port 8080rdr pass on en0 inet proto tcp from any to 172.22.54.89 port 80 -> 172.22.54.89 port 8080
Hosts配置
配置文件位于/etc/hosts。
【不一定需要】将beta域名的DNS地址重定向到本地
#127.0.0.1 web-application.dev.meituan.com
IP地址配置
【不一定需要】双方机器的IP切换到不同路由器下。
这是因为无线热点配置了AP隔离的安全特性：挂在同一Wifi AP下的机器禁止通过路由机（其实是交换机）本身相互访问。
| ID | 机器 | SSID | IP |
|---|---|---|---|
| 1 | mac | mtdp | 172.22.54.89 |
| 2 | mobile | mtdp_tech | 172.22.38.121 |
| 3 | mobile | mtdp | 172.22.50.98 |
1号机访问2号机的traceroute回显，可以看到正常访问。
1号机访问3号机的traceroute回显，可以看到网络包在网关这一层就被丢弃了。这也就解释了mac和手机处于mtdp时，Charles抓包失败的情况。
Tomcat的配置
配置文件位于%TOMCAT_HOME%/conf/context.xml。
【不需要】设置如下的IP过滤器，保持默认即可。
【不需要】更改Engine的defaultHost为外部IP，保持localhost即可。
【不需要】更改Host的name为外部IP，保持localhost即可。
基于Pigeon的RpcAPI
【需要】配置相同的泳道。
Pigeon是公司内部的Rpc组件，支持泳道特性，大大简化了配置过程。配置了泳道，所有的请求也会被隔离起来了，在A泳道里的请求只会发送给A，而不会发送给B。利用该特性，我们可以把Rpc上下游的服务都加入到同一个泳道中，使双方的IP位于服务发现列表的第一位。
上下游双方编辑本地文件/data/webapps/appenv，在文件末尾新添加一行swimlane=XXX，此处的值可以是任意的，尽量不要和其他人配置相同就可以了。然后双方各自启动服务，在test.pigeon.sankuai.com中或者访问ServiceIP:4080/services确认已位于统一泳道。