融数数据基于Kubernetes的微服务治理和构建平台.docx

? ? 融数数据基于Kubernetes的微服务治理和构建平台 ? ? ? DNS： A——IP地址 CName ——主机名 PTR——与A相反 SRV——DNS SRV是DNS记录中一种，用来指定服务地址。与常见的A记录、cname不同的是，SRV中除了记录服务器的地址，还记录了服务的端口，并且可以设置每个服务地址的优先级和权重。访问服务的时候，本地的DNS resolver从DNS服务器查询到一个地址列表，根据优先级和权重，从中选取一个地址作为本次请求的目标地址。 ? ? ? 我们都知道 CAP 是 Eric Brewer 提出的分布式系统三要素：强一致性 (Consistency)可用性 (Availability)分区容忍性 (Partition Tolerance) 几乎所有的服务发现和注册方案都是 CP 系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持 stale reads ）。 ? ? ? 服务发现之 Etcd VS Consul ? 值得注意的是，分布式系统中的数据分为控制数据和应用数据。使用etcd的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况。 ? ? 抄自这里 ? ************************************************************************************************ 网上找来找去都是zk和etcd的比较，和consul的比较很少，这个感觉还算靠谱，也在别的地方看到过对consul的吐槽，记录下 ************************************************************************************************ ? 导语 在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。 在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，redis 的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。 有了这些需求，于是发展出了一系列的开源框架，比如 ZooKeeper, Etcd, Consul 等等。 这些框架一般会提供这样的服务： 服务注册主机名，端口号，版本号，或者一些环境信息。 服务发现可以让客户端拿到服务端地址。 一个分布式的通用 k/v 存储系统基于 Paxos 算法或者 Raft 算法 领导者选举 (Leader Election) 其它一些例子：分布式锁 (Distributed locking)原子广播 (Atomic broadcast)序列号 (Sequence numbers)… 我们都知道 CAP 是 Eric Brewer 提出的分布式系统三要素：强一致性 (Consistency)可用性 (Availability)分区容忍性 (Partition Tolerance) 几乎所有的服务发现和注册方案都是 CP 系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持 stale reads ）。 ZooKeeper 作为这类框架中历史最悠久的之一，是由 Java 编写。Java 在许多方面非常伟大，然而对于这种类型的工作还是显得有些沉重，也正因为其复杂性和对新鲜事物的向往，我们第一时间就放弃了选择它。 本文将从协议和应用层来比较 Etcd 和 Consul，并最终给出了笔者的偏好。 Etcd Etcd 是一个使用 go 语言写的分布式 k/v 存储系统。考虑到它是 coreos 公司的项目，以及在 GitHub 上的 star 数量 (9000+)，Google 著名的容器管理工具 Kuberbetes 就是基于 Etcd 的。我们最先考虑的就是它。 在介绍 Etcd 之前，我们需要了解一些基本的概念。我们知道在单台服务器单个进程中维护一个状态是很容易的，读写的时候不会产生冲突。即便在多进程或者多线程环境中，使用锁机制或者协程