From 9870c24afcaf556fbaadf7ab5b680ca1b43eaebc Mon Sep 17 00:00:00 2001 From: sfw Date: Tue, 7 Aug 2018 18:36:59 +0800 Subject: [PATCH] ch5-10-fix typo --- ch5-web/ch5-10-service-discovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch5-web/ch5-10-service-discovery.md b/ch5-web/ch5-10-service-discovery.md index 85622ba..788683f 100644 --- a/ch5-web/ch5-10-service-discovery.md +++ b/ch5-web/ch5-10-service-discovery.md @@ -6,7 +6,7 @@ ip+port 的组合往往被称为 endpoint。通过“订单服务”去找到这 ## 为什么不把 ip+port 写死在自己的配置文件中 -在大型网站的语境下，为了高可用每一个服务都会一定会有多个节点来分担压力和风险，而现在随着 docker 之类的工具的盛行，依赖服务的节点是存在迁移的可能性的。所以对于依赖服务会慢慢不在将其 ip+port 写死在自己的服务的配置文件中。否则在依赖服务迁移时，就需要跟着依赖服务修改配置，耗时费力。 +在大型网站的语境下，为了高可用每一个服务都会一定会有多个节点来分担压力和风险，而现在随着 docker 之类的工具的盛行，依赖服务的节点是存在迁移的可能性的。所以对于依赖服务会慢慢不再将其 ip+port 写死在自己的服务的配置文件中。否则在依赖服务迁移时，就需要跟着依赖服务修改配置，耗时费力。 如果依赖服务所在的机器挂掉了，也就意味着那个 ip+port 不可用了。这时候上游还需要有某种反馈机制能够及时知晓，并且能够在知晓之后，不经过上线就能将已经失效的 ip+port 自动从依赖中摘除。