那时刻
2021-03-12老师的问题，我的个人看法是，采用etcd应该是可行的。 1.高可靠。etcd基于raft的多副本可以满足。 2.高性能。公司业务多，规模大，可以依据不同业务不同etcd的方法，分担etcd的写压力，以及数据存储量有限的问题。各自业务的etcd可以水平扩展。 3.支持多业务、多版本管理、多种发布策略。etcd可以做到多版本管理，多发布策略的话，可以级联多个etcd的方法。 另外，可能更加理想的存储架构方式是采用计算与存储分离的方法，计算部分处理读写以及扩展，存储部分处理多版本，多业务，多发布策略。作者回复: 嗯，整体想法不错，特别是考虑到数据容量问题，但是还需要考虑更多问题，比如性能问题，一个业务可能数万个client, 直接读etcd性能肯定扛不住的，其次是复杂度管理，比如一个业务分配一个etcd集群，那这过程是手动的还是自动的呢? 能否自动快速就接入一个新业务而无需相关运维操作呢？ 或者有没有更好的存储方案。
共 2 条评论5
大爱无疆2021-04-09做一个etcd proxy，proxy 实现 hash，将不同的/key 映射到后端不同的etcd集群上。 这样 相当于实现了 支持分片的 分布式存储。作者回复: 嗯啊，这个想法在有的公司落地了，但是不支持跨多节点的事务，有一定局限性，proxy稳定性也是个考验
3
Geek_daf51a2021-03-12思考题很棒，我认为etcd并不合适，适合使用可平行扩容的分布式数据库如tidb，运维复杂度不更低点吗，容量也更大，还能支持各种key value大小配置3
刁寿钧2021-03-15其实还期待讨论下APISIX搭配证书使用etcd的姿势，哈哈共 1 条评论1- Geek_ed84ef2021-04-05给服务路由配Lease跟APISIX提供的健康检查插件有什么区别吗?好像都是服务异常后可自动摘除节点
Coder2021-03-13我认为使用支持分片的nosql数据库比较合适，比如redis集群版本，一主两副本、还是很可靠得
云原生工程师2021-03-13我认为etcd不太合适，应该使用类似阿里云drds、腾讯云tdsql这样分布式数据库，不过数据推送机制就没了，需要轮询了，但是容量不需要担心，支持多业务就表中增加一个字段或独立的表