在微服务协作开发、灰度发布之流量染色介绍了如何通过流量染色在开发环境进行多服务、多版本的协作开发， 但这都是在服务已经发布到集成环境情况下，开发过程中对于单个服务的开发/维护者往往需要快速的将本地服务集成到在线环境，以完成更好集成测试，而不是等待发布流程， 这样一是节约时间，二是避免将有问题的服务发布到线上集成环境，对Ta人造成影响。本文将介绍在micro生态如何通过network将本地服务加入到线上集成环境，既可以快速测试，又不影响集成环境。

方案

整体方案一是go-micro的服务的proxy方式，，并且在代理中有router筛选功能，二是network提供连接不同网络环境的能力。

1. 首先在线上和本地部署network服务，有关network的内容可以参考本文【go-micro】Network初探， 有了network的基础剩下的工作就是proxy的router筛选功能，实现参考 PR#897， 从实现我们知道通过Micro-Router、Micro-Network和Micro-Gateway三个metadata可以对router进行筛选，而使用Micro-Address以及基于label的筛选还处于TODO状态。

2. 其次在线上及本地所有服务都需要是用network做为代理(MICRO_PROXY=go.micro.network)包括网关(注意默认网关不支持服务筛选，导致网关不能用network做代理)，这样服务间所有流量都通过network进行代理转发。

3. 最后考虑所有服务都可以自助路由到个人本地，我们不能直接使用Micro-Router，因为Micro-Router会在全链路生效，需要使用metadata来传递router筛选信息， 再通过Client/Call Wrap实现Micro-Router的恢复和清理，在识别到调用服务需要筛选时添加Micro-Router，否则清理Micro-Router，避免向下传导，实践参考router_filter

实践参考 micro-in-cn/starter-kit#本地服务接入-network代理

局限性/问题

• 所有服务都要使用network做代理，如果框架能够在CallOption中支持动态使用代理将会更好
• 所有服务都需要添加Client/Call Wrap，需要统一的规范约定
• 在网关层与流量染色遇到相同的问题即：不支持服务筛选，导致网关不能用network做代理，需要去掉SelectOption
  • 另一个思路是在本地开micro api + 聚合服务，聚合服务再通过 network 代理访问线上服务，可以满足一般场景的需求
• 为了避免误协作过程中路由到Ta人本地环境，可以再增加Micro-Network规则，线上与本地network使用不同名称(未实测)
  • 如果框架能够在路由选择上有route.Link=local这样的本地优先策略会有一个更好的体验