计算实例部署微服务时如何规划东西向流量，重点不是先划出很多网段，而是先弄清服务之间谁调用谁、调用什么端口，再把允许的路径落实到网络和应用策略中。这里的东西向流量，指同一环境内服务实例之间的通信；它与用户或外部系统进入服务的南北向流量不同。
先把调用关系变成清单
从应用配置、接口文档和实际运行记录中整理调用关系。比如，一个示例业务中，网关调用用户服务和订单服务，订单服务调用库存服务，并访问数据库；库存服务不应因为处于同一网络就能访问所有服务。清单至少记录调用方、被调用方、协议与端口、用途，以及是否需要双向通信。
还要区分同步请求与异步消息。同步调用通常需要明确请求方向及响应路径；使用消息队列时，生产者和消费者可能分别连接消息服务，而不是彼此直接开放端口。服务发现名称可以随实例变化，策略则应尽量按服务身份或工作负载标签匹配，避免将临时实例地址写死。
按信任边界划分网络
先按环境和职责划分边界，例如开发、测试、生产环境隔离，业务工作负载与数据服务分区。若使用 Kubernetes，可结合命名空间和工作负载标签组织策略；若使用虚拟机或云计算实例，则可用子网、安全组或主机防火墙表达相近的边界。网段划分应服从路由、地址规划和运维能力，不必为每个微服务单独建网。
网段隔离提供基础边界，但不能代替逐服务授权。同一网段内的实例仍可能互相访问，因此应明确默认规则：未申报的服务间连接不开放。配置 Kubernetes NetworkPolicy 前，需要确认所用网络插件支持并实际执行该策略；仅创建策略对象，不代表数据面一定会拦截流量。
按顺序落地访问策略
- 建立基线：在测试环境记录现有调用，核对配置文件、服务发现记录和监控数据，删除已停用的依赖。不要直接从一次短时观察推断所有定时或低频任务。
- 定义允许关系：以调用清单为准，为每条连接写明来源服务、目标服务、协议和端口。数据库只向确有读写需要的应用开放；管理接口与业务接口分开控制。
- 先观察再收紧：在支持流量审计的环境中先观察命中情况，补齐健康检查、任务调度和故障切换所需连接，再逐步启用拒绝规则。分批实施，保留回退办法。
- 验证正反路径：从获准的调用方检查连接与应用请求，从未授权的工作负载验证连接被阻断；同时检查 DNS 解析、服务发现、健康检查和滚动发布是否正常。
- 持续复核：服务新增依赖或端口变更时更新清单和策略。通过流量日志、拒绝事件、延迟和错误率观察影响，并定期清理不再使用的规则。
网络策略与服务网格怎么选
NetworkPolicy 适合控制工作负载之间的基本网络可达性，配置面相对直接；具体能力取决于集群网络插件，通常不负责细粒度的应用层身份认证。Istio 等服务网格可在代理层提供服务身份、加密和更细的访问控制，也会增加组件、配置和排障复杂度。规模较小、需求以隔离为主时，可先采用网络策略；需要按服务身份授权、统一管理加密或细化请求规则时，再评估服务网格。两者可以组合，但职责应写清楚，避免规则冲突。
让规划可验证、可维护
计算实例部署微服务时如何规划东西向流量，最终要落到可检查的调用清单、网络边界和策略版本上。为每条规则注明业务用途与责任方，先在非生产环境验证，再按服务或命名空间逐步推广。这样既能减少无关服务间的暴露，也能在连接被误拦时快速定位到具体调用关系。
常见问题
东西向流量需要全部经过网关吗？
不一定。网关常用于外部入口；内部服务可直接调用，但应由网络策略或服务网格限制可访问范围。
每个微服务都要单独划分网段吗？
通常不需要。按环境、信任边界和运维能力划分即可，再用服务身份或标签补充细粒度访问控制。
策略上线后怎样判断是否误拦？
结合拒绝日志、应用错误、健康检查和调用链观察；分批启用并准备回退，能降低排查影响。
NetworkPolicy 与服务网格必须二选一吗？
不必。前者可承担基础网络隔离，后者可处理更细的服务身份与请求控制；是否组合取决于需求和运维能力。