ASPIRE

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

=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=

Docker

,
,

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

  4. 程序员练级攻略（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、整个网络是同构的。
    `

    回复

  5. 中小团队落地配置中心详解
    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确定内容正确
    `

    回复

  6. 自己写分布式配置中心[上篇]-单机模式
    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.小结
    `

    回复

  8. 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. 小结
    `

    回复

  11. 浅谈协同文档中的数据一致性
    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 的强一致性无法满足，但通过损失部分可用性，允许暂时的客户端不一致情况，通过协同编辑冲突算法，可以解决数据不一致问题，达到了最终的数据一致性。
    `

    回复

  13. 一文总结：分布式一致性技术是如何演进的？
    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，背后的技术是怎么样演进的，我们可以从算法本身来做个对比，下面主要从可理解性、效率、可用性和适用场景等几个角度进行对比分析。
    `

    回复

  14. 服务发现技术选型那点事儿
    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”的目标更为复杂，果然在分布式的世界中，真是没有一口饭是免费的。
    `

    回复

发表回复

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