分布式配置管理相关资料收集/学习


=Start=

缘由:

这几年微服务的概念比较火,在看了一些文章、检索了一些资料后发现,微服务和SOA、服务治理、配置管理等概念或实现联系紧密,所以要想较为深入细致的理解微服务的概念,先学习它的前置概念知识很有必要,在这里,我先整理一下检索到的「配置管理」相关资料,方便后续参考学习。

正文:

参考解答:

配置管理:

开源分布式配置中心选型
http://vernonzheng.com/2015/02/09/%E5%BC%80%E6%BA%90%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E9%80%89%E5%9E%8B/

一篇好TM长的关于配置中心的文章
http://jm.taobao.org/2016/09/28/an-article-about-config-center/

淘宝分布式配置管理服务Diamond
http://codemacro.com/2014/10/12/diamond/

分布式配置管理平台Disconf
https://github.com/knightliao/disconf
http://disconf.readthedocs.io/zh_CN/latest/design/src/%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86%E5%B9%B3%E5%8F%B0Disconf.html

Apollo配置中心设计
https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E8%AE%BE%E8%AE%A1
http://www.infoq.com/cn/articles/open-source-configuration-center-apollo

QConf 是一个分布式配置管理工具
https://github.com/Qihoo360/QConf/blob/master/README_ZH.md

Spring Cloud 如何选择分布式配置中心
http://cxytiandi.com/blog/detail/12466

如何设计一个配置中心的后端架构
http://limboy.me/tech/2018/03/06/how-to-architecture-config.html

Spring Cloud构建微服务架构(四)分布式配置中心
http://blog.didispace.com/springcloud4/
Spring Cloud构建微服务架构(四)分布式配置中心(续)
http://blog.didispace.com/springcloud4-2/
Spring Cloud构建微服务架构:分布式配置中心【Dalston版】
http://blog.didispace.com/spring-cloud-starter-dalston-3/

分布式环境下配置中心实现思考【推荐】
http://blog.csdn.net/jiyiqinlovexx/article/details/38326865


分布式配置管理除了要起到集中式管理各项目的配置功能、动态更新配置之外,还可以通过收集各项目的配置使用情况,给出配置治理的相关意见,包括:

  • 长期不使用的配置;
  • 过大的配置;
  • 跨项目使用的配置:包括使用的其他项目的配置以及配置被其他项目使用的情况;
参考链接:

如上

=END=


《“分布式配置管理相关资料收集/学习”》 有 14 条评论

  1. 程序员练级攻略(2018):分布式架构入门
    https://time.geekbang.org/column/article/10603

    8 条荒谬的分布式假设(Fallacies of Distributed Computing)
    http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
    `
    1、网络是稳定的。
    2、网络传输的延迟是零。
    3、网络的带宽是无穷大。
    4、网络是安全的。
    5、网络的拓扑不会改变。
    6、只有一个系统管理员。
    7、传输数据的成本为零。
    8、整个网络是同构的。
    `

  2. 中小团队落地配置中心详解
    https://mp.weixin.qq.com/s/uGUvV4jl4YIvNztuepdC8A
    `
    # 配置中心选型
    选型的原则:简单,易落地,不挑平台,不挑语言,尽量少的依赖。
    对比了Disconf、Apollo等方案,最终选择了Etcd+Confd的方案,基本符合上边的原则,且Etcd我们在部署Kubernetes的时候已经有过使用,算是轻车熟路。

    # 配置中心部署
    etcd集群
    confd服务

    # 联调测试
    1.在Etcd服务器新建一个KV值
    2.启动confd
    3.通过上边日志可以看到/tmp/nginx.conf文件已经正常同步且更新了,查看/tmp/nginx.conf确定内容正确
    `

  3. 自己写分布式配置中心[上篇]-单机模式
    http://wuwenliang.net/2018/12/05/%E8%87%AA%E5%B7%B1%E5%86%99%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83-%E5%8D%95%E6%9C%BA%E6%A8%A1%E5%BC%8F/
    `
    目录
    0.说说配置中心
    1.定义配置实体
    2.项目类结构
     2.1.概述
     2.2.配置持有者ConfigHolder及配置获取者Config
     2.3.配置服务后台更新线程池加载器ConfigCommandLineRunner
     2.4.被观察者接口Observable
     2.5.观察者接口Observer
     2.6.配置新增观察者实现–ConfigDirectUpdateObserver–直接修改更新配置
     2.7.观察者修改观察者实现–ConfigMD5UpdateObserver
     2.8.接口IConfigPullHandler,定义对配置项的更新策略
     2.9.【重要】配置被观察者ConfigSubject–自动更新魔法的主角
     2.10.其他辅助类
    3.使用效果
    4.小结
    `

  4. springboot2.x整合nacos配置服务实现配置获取及刷新
    http://wuwenliang.net/2019/02/22/springboot2-x%E6%95%B4%E5%90%88nacos%E9%85%8D%E7%BD%AE%E6%9C%8D%E5%8A%A1%E5%AE%9E%E7%8E%B0%E9%85%8D%E7%BD%AE%E8%8E%B7%E5%8F%96%E5%8F%8A%E5%88%B7%E6%96%B0/
    `
    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您实现动态服务发现、服务配置管理、服务及流量管理。
    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
    Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

    可以看到,Nacos主要面向分布式配置级服务发现等领域,由于之前使用过阿里云的ACM配置服务体验良好,而Nacos便是ACM的开源版本,因此我们选择了Nacos作为业务框架的分布式配置中心。

    1. 引入nacos-config-spring-boot-starter
    2. application.properties中引入Nacos的config-server地址
    3. 编写配置读取类NacosConfigAnnoatationService
    4. 控制台配置配置项
    5. 测试配置更新
    6. 小结
    `

  5. 浅谈协同文档中的数据一致性
    http://www.alloyteam.com/2020/01/14221/
    `
    # BASE 理论
    但将这个理论(CAP理论)放在协同场景下,好像又不适用了?假设在网络差的情况下,两个客户端同时提交,虽然暂时一致性无法满足,本地客户端会看到不同的内容,但网络恢复后,通过协同冲突算法数据也能保持一致,这不是既满足了一致性又满足了可用性吗?

    这个是对的,只是这里的一致性不等于 CAP 理论的一致性,CAP 理论是假设在没有网络延迟的情况下的强一致性,也就是数据时刻都是一致的。而协同编辑的场景,我们需要了解另外的概念:BASE

    既是无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

    BA:Basically Avaliable(基本可用)

    S: Soft State(软状态)

    E: Eventually consistency(最终一致性)

    BASE 的核心思想:在不满足强一致性的情况下,也可以通过其他手段来达到最终一致性。

    1、基本可用
    允许损失部分可用性,允许牺牲响应时间、降级系统功能等操作

    2、软状态
    允许存在数据中间状态,不要求强一致性,并不影响整体可用性,允许副本之间的数据同步延迟。

    3、最终一致性
    所有的副本,在最终都能达到数据一致的状态,但不要求实时的强一致性。
    最终一致性又会有许多划分:读写一致性、写读一致性、单调读一致性、单调写一致性等。

    在 BASE 理论中,我们可以看到协同编辑文档的场景中,虽然 CAP 的强一致性无法满足,但通过损失部分可用性,允许暂时的客户端不一致情况,通过协同编辑冲突算法,可以解决数据不一致问题,达到了最终的数据一致性。
    `

  6. 一文总结:分布式一致性技术是如何演进的?
    https://mp.weixin.qq.com/s/KSpsa1viYz9K_-DYYQkmKA
    `
    # 分布式一致性
    分布式一致性,简单的说就是在一个或多个进程提议了一个值后,使系统中所有进程对这个值达成一致。

    为了就某个值达成一致,每个进程都可以提出自己的提议,最终通过分布式一致性算法,所有正确运行的进程学习到相同的值。

    阿里妹导读:分布式一致性(Consensus)作为分布式系统的基石,一直都是计算机系统领域的热点。近年来随着分布式系统的规模越来越大,对可用性和一致性的要求越来越高,分布式一致性的应用也越来越广泛。纵观分布式一致性在工业界的应用,从最开始的鼻祖Paxos的一统天下,到横空出世的Raft的流行,再到如今Leaderless的EPaxos开始备受关注,背后的技术是如何演进的?本文将从技术角度探讨分布式一致性在工业界的应用,并从可理解性、可用性、效率和适用场景等几个角度进行对比分析。

    工业界对分布式一致性的应用,都是为了构建多副本状态机模型(Replicated State Machine),实现高可用和强一致。

    分布式一致性使多台机器具有相同的状态,运行相同的确定性状态机,在少数机器故障时整体仍能正常工作。

    # Paxos
    Paxos达成一个决议至少需要两个阶段(Prepare阶段和Accept阶段)。
    Prepare阶段的作用:
    争取提议权,争取到了提议权才能在Accept阶段发起提议,否则需要重新争取。
    学习之前已经提议的值。

    Accept阶段使提议形成多数派,提议一旦形成多数派则决议达成,可以开始学习达成的决议。Accept阶段若被拒绝需要重新走Prepare阶段。

    # Multi-Paxos
    Basic Paxos达成一次决议至少需要两次网络来回,并发情况下可能需要更多,极端情况下甚至可能形成活锁,效率低下,Multi-Paxos正是为解决此问题而提出。
    Multi-Paxos选举一个Leader,提议由Leader发起,没有竞争,解决了活锁问题。提议都由Leader发起的情况下,Prepare阶段可以跳过,将两阶段变为一阶段,提高效率。Multi-Paxos并不假设唯一Leader,它允许多Leader并发提议,不影响安全性,极端情况下退化为Basic Paxos。

    Multi-Paxos与Basic Paxos的区别并不在于Multi(Basic Paxos也可以Multi),只是在同一Proposer连续提议时可以优化跳过Prepare直接进入Accept阶段,仅此而已。

    # Raft
    不同于Paxos直接从分布式一致性问题出发推导出来,Raft则是从多副本状态机的角度提出,使用更强的假设来减少需要考虑的状态,使之变的易于理解和实现。
    Raft假设系统在任意时刻最多只有一个Leader,提议只能由Leader发出(强Leader),否则会影响正确性;而Multi-Paxos虽然也选举Leader,但只是为了提高效率,并不限制提议只能由Leader发出(弱Leader)。

    从Paxos到Raft再到EPaxos,背后的技术是怎么样演进的,我们可以从算法本身来做个对比,下面主要从可理解性、效率、可用性和适用场景等几个角度进行对比分析。
    `

  7. 服务发现技术选型那点事儿
    https://mp.weixin.qq.com/s/boh5smQ6ApTwScKYyhuD-Q
    `
    微服务脱胎于 SOA 理论,核心是分布式,但单体应用中,模块之间的调用(比如让消息服务给客户发送一条数据)是通过方法,而所发出的消息是在同一块内存之中,我们知道这样的代价是非常小的,方法调用的成本可能是纳秒级别,我们从未想过这样会有什么问题。

    但是在微服务的世界中,模块与模块分别部署在不同的地方,它们之间的约束或者协议由方法签名转变为更高级的协议,比如 RESTful 、PRC,在这种情况下,调用一个模块就需要通过网络,我们必须要知道目标端的网络地址与端口,还需要知道所暴露的协议,然后才能够编写代码比如使用 HttpClient 去进行调用,这个“知道”的过程,往往被称为服务发现。

    分布式的架构带来了解耦的效果,使得不同模块可以分别变化,不同的模块可以根据自身特点选择编程语言、技术栈与数据库,可以根据负载选择弹性与运行环境,使得系统从传统的三层架构变成了一个个独立的、自治的服务,往往这些服务与业务领域非常契合,比如订单服务并不会关心如何发送邮件给客户,司机管理服务并不需要关注乘客的状态,这些服务应该是网状的,是通过组合来完成业务。解耦带来了响应变化的能力,可以让我们大胆试错,我们希望启动一个服务的成本和编写一个模块的成本类似,同时编写服务、进行重构的成本也需要降低至于代码修改一般。在这种需求下,我们也希望服务之间的调用能够简单,最好能像方法调用一样简单。

    但是 Armon(HashiCorp 的创始人)在他的技术分享中提到,实现分布式是没有免费午餐的,一旦你通过网络进行远程调用,那网络是否可达、延迟与带宽、消息的封装以及额外的客户端代码都是代价,在此基础上,有时候我们还会有负载均衡、断路器、健康检查、授权验证、链路监控等需求,这些问题是之前不需要考虑的。所以,我们需要有“产品”来帮助我们解决这类问题,我们可以先从 Eureka 开始回顾、整理。

    # 一些思考

    进行技术选型的压力是非常之大的,随着技术的演进、人员的更替,很多系统逐渐变成了无法修改、无法移动的存在,作为技术负责人我们在进行这件工作时应该更加注意,选择某项技术时也需要考虑自己能否负担的起。

    Spring Cloud 提供的微服务方案在易用性上肯定好于自己在 Kubernetes 上发明新的,但是我们也担心它尾大不掉,所以在我们现在接触的项目中,对 Spring Cloud 上的应用进行迁移、重构还是可以负担的起的,但我非常担心几年后,改造的成本就会变的非常高,最终导向重写的境地。

    我们将调用方式分为“同步”与“异步”两种情况,在异步调用时,使用 MQ 传输事件,或者使用 Kafka 进行 Pub / Sub,事实上,Event Driven 的系统更有灵活性,也符合 Domain 的封闭。

    服务与服务之前的调用不仅仅是同步式的,别忘了在异步调用或者 pub-sub 的场景,我们会使用中间件帮助我们解耦。

    虽然中间件(middleware)这个词很容易让人产生困惑,它并不能很好的描述它的功能,但最少在实现消息队里、Event Bus、Stream 这种需求时,现在已有的产品已经非常成熟,我们曾经使用 Serverless 实现了一个完整的 web service,其中模块的互相调用就是通过事件。但是这并不是完美的,“如无必要,勿增实体”,加入了额外的系统或者应用就得去运维与管理,就需要考虑失效,考虑 failure 策略,同时在这种场景下实现“exactly once”的目标更为复杂,果然在分布式的世界中,真是没有一口饭是免费的。
    `

回复 hi 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注