From 255918a20c9a70525487bac78a1d85f75840ab38 Mon Sep 17 00:00:00 2001 From: Xargin Date: Tue, 14 Aug 2018 15:09:58 +0800 Subject: [PATCH] update dc --- ch6-cloud/ch6-06-config.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ch6-cloud/ch6-06-config.md b/ch6-cloud/ch6-06-config.md index 3867a3f..b6f6158 100644 --- a/ch6-cloud/ch6-06-config.md +++ b/ch6-cloud/ch6-06-config.md @@ -125,8 +125,16 @@ func main() { } ``` -### 配置膨胀之后 +## 配置膨胀 随着业务的发展，配置系统本身所承载的压力可能也会越来越大，配置文件可能成千上万。客户端同样上万，将配置内容存储在 etcd 内部便不再合适了。随着配置文件数量的膨胀，除了存储系统本身的吞吐量问题，还有配置信息的管理问题。我们需要对相应的配置进行权限管理，需要根据业务量进行配置存储的集群划分。如果客户端太多，导致了配置存储系统无法承受瞬时大量的 QPS，那可能还需要在客户端侧进行缓存优化，等等。 这也就是为什么大公司都会针对自己的业务额外开发一套复杂配置系统的原因。 + +## 客户端容错 + +在业务系统的配置被剥离到配置中心之后，并不意味着我们的系统可以高枕无忧了。当配置中心本身宕机时，我们也需要一定的容错能力，至少保证在其宕机期间，业务依然可以运转。这要求我们的系统能够在配置中心宕机时，也能拿到需要的配置信息。哪怕这些信息不够新。 + +具体来讲，在给业务提供配置读取的 sdk 时，最好能够将拿到的配置在业务机器的磁盘上也缓存一份。这样远程配置中心不可用时，可以直接用硬盘上的内容来做兜底。当重新连接上配置中心时，再把相应的内容进行更新。 + +加入缓存之后务必需要考虑的是数据一致性问题，当个别业务机器因为网络错误而与其它机器配置不一致时，我们也应该能够从监控系统中知晓。