两种服务间通信方式的选型

美拍规划整体架构时坚持”分而治之与化繁为简”：明确每个服务模块的单一职责，模块内部尽量内聚、模块之间做到解耦，这样才能针对单一模块做更精细化的优化，也能用最合适的技术去解决合适的场景问题。落到服务间的实际交互和通信上，美拍主要走两种方式，且刻意按场景做了区分。基于HTTP的方式：用法比较简单，主要用于跨团队、跨语言（比如PHP和Golang之间）的场景，工作主要在七层Nginx层完成，包括负载均衡、节点探测、并发保护等。基于Config Service+RPC的方式：主要用于内部系统之间的交互，基于etcd实现动态服务发现和配置服务，同时基于gRPC框架在Client层面扩展实现了负载均衡、节点健康状态探测、failover等基础功能，并通过metrics埋点结合统一的TraceID来跟踪服务的分布式调用链路状态。这条选型背后的判断标准是：HTTP方式牺牲了一部分性能和治理精细度，换来了跨语言跨团队场景下最低的接入门槛和最广泛的兼容性；RPC+服务发现方式牺牲了一部分实现复杂度和调试门槛，换来了内部系统间更精细的流量治理能力（健康探测、failover、全链路追踪）。选择哪种方式不是看”哪个更先进”，而是看”这次通信发生在什么边界上”——跨越团队和语言边界的通信，优先保证兼容性和低接入成本；纯内部系统之间的通信，则可以为了更强的治理能力承担更高的实现复杂度，因为这部分复杂度是团队自己能完全掌控的。