Network是micro社区正在主力打造的解决多”云”环境的解决方案，下面结合最近的研究做个总结，主要包括network适用的几种场景分析，
以及在这些场景需求下network还有哪些不足。
Proxy
在分析network之前先了解micro的proxy模式，服务之间调用不需要服务发现，而是通过proxy做转发，由proxy完成服务的发现和调用。
network实现了一个特殊的代理，它的服务发现并不只是通过注册中心，同时有network之间共享的服务。
服务可见性
network通过共享服务信息，实现跨network的服务可见，从而实现代理的服务发现，并且共享是有可见性的，当前advertise_strategy有3+1种方案:
none不共享服务- 即只接受外部服务，适合边缘节点，依赖中心服务场景
all共享全部服务best共享最优路由local仅共享集群内部服务，而不共享从其他network共享得到的服务，实际是best的一个筛选项，这也是为什么说它是3+1
截止
v1.6.0版本还没有此功能，需要使用master分支，PR#932增加了此策略的支持， 以micro的发版速度应该要不了多久就会有Release版🤣Network在不断完善，本文参考版本为：
应用场景
多集群
多集群场景分两种一是集群服务共享，二是多中心/主备集群，在advertise_strategy策略选择有区别。
集群服务共享
集群服务共享是指不同集群拥有不同的服务，实现集群间的服务发现，选择的策略是advertise_strategy=local，network仅共享自身服务，
如果DC B与DC C需要共享服务，那么需要直接建立连接，而不是通过DC A
多中心/主备集群
多中心/主备集群是将同一套服务部署在多个中心，可能是多活，也可能是分主备，选择的策略是advertise_strategy=best，但现在network在负载策略上还没有就近原则
中心服务+边缘
对于边缘计算场景，边缘节点可能是不提供服务的，比如只上报数据，可以选择advertise_strategy=none，当然有的可能又是提供服务的，可以选择advertise_strategy=local，
但DC A并不会将DC C的服务共享给DC B。因为network间通过tunnel通信，边缘节点可以是任意网络，只要连接到中心服务的network即可。
不足
Network高可用及性能
要考虑network的高可用，必须支持多副本水平扩展，现在同一集群内network会共享服务，但当前network的服务可见性并没有将集群内node与直连的node节点做区分，
如果集群内出现n个副本，那么最差的情况下可能要在network的pod间跳转n次。理想状态应该是对于集群内仅共享与node直连的集群外服务（这是当前network不具备），
而对集群外共享本集群服务，这样可以确保集群内network代理最多经过两跳即可调用集群外服务。
图中红色标记的go.micro.srv.s-2 gateway-a-2、go.micro.srv.s-2 gateway-a-3不应该出现在network的routes中，避免同一集群内没必要的路由。
有关
network的多副本还需要进一步研究，比如4个后会不会出现链路循环，以及具体路由负载策略等
总的来说是advertise_strategy需要更完善的策略支持，做必要的隔离、筛选，一是服务的可见性问题，二是服务规模增加后network间的数据通信也会成为瓶颈。
路由负载策略
路由负载选择需要优先级、筛选等策略，如local优先，这样我们可以实现主备集群，以及集群间流量切换等场景的应用
安全
更正：这里我们忽略了
tunnel的transport，在transport层是有mTLS支持的，具体参考【go-micro】自签名证书&Tunnel mTLS
network间的连接是通过tunnel完成，而tunnel在安全方面只是在message的header中放了一个token用于相互验证，这也是需要加强的部分。
Network模拟测试
可以本地使用不同的注册中心模拟多个集群，简单的mdns、consul和etcd就可以模拟出三个集群，如果有公网服务器当然更好。