book/advanced-go-programming-book
1
0
Fork 0
mirror of https://github.com/chai2010/advanced-go-programming-book.git synced 2025-05-24 20:52:22 +00:00
Code Issues Releases Wiki Activity

update sd

Browse Source
This commit is contained in:
Xargin 2018-06-25 20:12:20 +08:00
parent 14ea90abbe
commit 1795c3d16e
1 changed files with 23 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
ch5-web/ch5-10-service-discovery.md
View File

@ -6,13 +6,9 @@ ip+port 的组合往往被称为 endpoint。通过“订单服务”去找到这
## 为什么不把 ip+port 写死在自己的配置文件中
TODO 从系统的演化角度来讲，加图
在大型网站的语境下，为了高可用每一个服务都会一定会有多个节点来分担压力和风险，而现在随着 docker 之类的工具的盛行，依赖服务的节点是存在迁移的可能性的。所以对于依赖服务会慢慢不在将其 ip+port 写死在自己的服务的配置文件中。否则在依赖服务迁移时，就需要跟着依赖服务修改配置，耗时费力。
在大多数公司发展初期，物理机器比较少，内网 ip 也很少。一些创业公司虽然开发人员众多，但因为业务限制，每一个服务的 QPS 都不高。因此确实有很多公司服务之间是通过 ip+port 来进行相互调用的。再原始一些的话，甚至可能所有服务都在一个工程下，那也就没有什么依赖问题了。
随着公司业务规模的发展，可能慢慢会衍生出流量较大的接口，早期我们也没有那么多设计上的讲究，所以就按流量先进行接口拆分。一旦进行了拆分，那就会涉及到模块/服务之间的依赖问题。而流量大的服务往往一台机器还不够，所以你面临的是多个 ip+port 的组合的依赖。随着业务越来越复杂，这种类型的服务越来越多。我们还是需要把这一大堆 ip+port 按照服务名来进行划分，并能够通过名字找到对应的 ip+port 数组。
拆分后，如果依赖服务所在的机器挂掉了，也就意味着那个 ip+port 不可用了。这时候上游需要有某种反馈机制能够及时知晓，并且能够在知晓之后，不经过上线就能将已经失效的 ip+port 自动从依赖中摘除。
如果依赖服务所在的机器挂掉了，也就意味着那个 ip+port 不可用了。这时候上游还需要有某种反馈机制能够及时知晓，并且能够在知晓之后，不经过上线就能将已经失效的 ip+port 自动从依赖中摘除。
我们先来看看怎么通过服务名字找到这些 ip+port 列表。
@ -22,7 +18,27 @@ TODO 从系统的演化角度来讲，加图
不过使用公共的 dns 服务也存在问题，我们的 dns 服务会变成整个服务的集中的那个中心点，这样会给整个分布式系统带来一定的风险。一旦 dns 服务挂了，那么我们也就找不到自己的依赖了。我们可以使用自己本地的缓存来缓解这个问题。比如某个服务最近访问过下游服务，那么可以将下游的 ip+port 缓存在本地，如果 dns 服务挂掉了，那我至少可以用本地的缓存做个兜底，不至于什么都找不到。
TODOTODO，这里应该有图
```
┌────────────────┐ .─────────────────.
│ My Service │─────────▶( local dns cache )
└────────────────┘ `─────────────────'
│
│
│
┌───────── X ──────────┤
│ │
│ │
│ │
▼ │
.─────────────────. │
( dns service ) │
`─────────────────' │
│
▼
┌────────────────────────┐
│ dependent service │
└────────────────────────┘
```
服务名和 endpoints 的对应也很直观，无非 `字符串` -> `endpoint 列表`。