<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Service Discovery on PlumePHP</title><link>https://plumephp.com/tags/service-discovery/</link><description>Recent content in Service Discovery on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Fri, 21 Nov 2025 10:00:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/service-discovery/index.xml" rel="self" type="application/rss+xml"/><item><title>微服务架构设计模式：API网关、服务发现与分布式通信实战指南</title><link>https://plumephp.com/microservices-design-patterns/</link><pubDate>Fri, 21 Nov 2025 10:00:00 +0800</pubDate><guid>https://plumephp.com/microservices-design-patterns/</guid><description>&lt;h2 id="引言"&gt;引言&lt;/h2&gt;
&lt;p&gt;微服务不是银弹。Martin Fowler 提出的&amp;quot;Microservice Premium&amp;quot;警示我们：微服务引入的分布式事务、服务发现、运维复杂度远超单体。更常见的是&amp;quot;Microservice Theater&amp;quot;——团队表面上拆分了几十个服务，实际上共用一个数据库、部署紧耦合、任何改动都需要跨团队协调。&lt;/p&gt;</description></item><item><title>Go 与微服务：服务发现与注册实战</title><link>https://plumephp.com/85-service-discovery/</link><pubDate>Sun, 12 May 2024 10:45:00 +0800</pubDate><guid>https://plumephp.com/85-service-discovery/</guid><description>&lt;h1 id="go-与微服务服务发现与注册实战"&gt;Go 与微服务：服务发现与注册实战&lt;/h1&gt;
&lt;p&gt;想象一下这样的场景：你的电商系统从单体架构拆成了 20 个微服务。用户服务、订单服务、支付服务、库存服务……它们分布在不同的服务器上，IP 地址随时可能变化（容器重启、自动扩缩容）。这时候问题来了：&lt;strong&gt;订单服务怎么知道支付服务的地址？&lt;/strong&gt;&lt;/p&gt;</description></item></channel></rss>