服务治理相关资料收集/学习

本文最后更新于2018年3月17日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

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

正文:

参考解答:

服务化之后,随着规模的扩大,一定要考虑“服务治理”,否则服务之间的依赖关系会乱成麻。

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3833.html

《服务治理相关资料收集/学习》上有7条评论

  1. 后端技能树修炼:CAP 定理
    https://mp.weixin.qq.com/s/BlNIXtviCGYPhNpg6mihJg

    CAP 定理表明,任何分布式计算机系统只能同时满足一致性(Consistency),可用性(Availability)和分区容错性(Partition Tolerance)三者中的任意两个。

    由于任何分布式系统任何时候只能同时满足 CAP 定理中的两个属性,因此,我们可以根据这一点将分布式系统分为三类:
    CA 系统:数据在所有节点之间是一致的,我们也可以从系统的任意节点中进行读和写,但节点间通信网络不能出故障
      MySQL
      MSSQL
    CP 系统:数据在所有节点之间是一致的,而且能够容忍分区出错并防止数据不同步
      Google BigTable
      Hbase
      MongoDB
      Redis
    AP 系统:系统中所有节点总是在线的,但无法保证获取到的是最新数据,但只要网络正常,节点间就会进行同步
      Cassandra
      Voldemort
      Dynamo DB
      CouchDB
      SimpleDB

    要强调一点,CAP 定理关注的是对数据的读写操作,而不是分布式系统的所有功能,它要求分布式系统节点间是互相连接且有数据共享的,例如 Memcache 的集群中节点相互间没有连接和数据共享,因此不是 CAP 定理讨论的对象,同理 ZooKeeper 的选举机制也不是 CAP 探讨的对象。

  2. 分布式中几种服务注册与发现组件的原理与比较
    http://blueskykong.com/2018/10/05/discovery/

    Eureka、Consul、Zookeeper的基本原理与比较。

    在一个分布式系统中,服务注册与发现组件主要解决两个问题:服务注册和服务发现。
    · 服务注册:服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port,以及暴露服务自身状态以及访问协议等信息。
    · 服务发现:服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务。

    除此之外,服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。
    · 监控:微服务应用中,服务处于动态变化的情况,需要一定机制处理无效的服务实例。一般来讲,服务实例与注册中心在注册后通过心跳的方式维系联系,一旦心跳缺少,对应的服务实例会被注册中心剔除。
    · 负载均衡:同一服务可能同时存在多个实例,需要正确处理对该服务的负载均衡。

  3. CAP 一致性协议及应用解析
    https://mp.weixin.qq.com/s/26x8O1bRzurl84e3nM6TTA

    一、一致性
    1.1 CAP 理论
    C 一致性:分布式环境中,一致性是指多个副本之间,在同一时刻能否有同样的值
    A 可用性:系统提供的服务必须一直处于可用的状态。即使集群中一部分节点故障。
    P 分区容错性:系统在遇到节点故障,或者网络分区时,任然能对外提供一致性和可用性的服务。以实际效果而言,分区相当于通信的时限要求。系统如果不能在一定实现内达成数据一致性,也就意味着发生了分区的情况。必须就当前操作在 C 和 A 之前作出选择

    1.2 CAP不能同时满足的证明

    1.3 常见场景
    CA without P: 在分布式环境中,P 是不可避免的,天灾(某软公司的Azure被雷劈劈中)人祸(某里公司 A 和 B 机房之间的光缆被挖断)都能导致P。
    CP without A:相当于每个写请求都须在Server之前强一致。P (分区)会导致同步时间无限延长。这个是可以保证的。例如数据库的分布式事务,两阶段提交,三阶段提交等。
    AP without C: 当网络分区发生,A 和 B 集群失去联系。为了保证高可用,系统在写入时,系统写入部分节点就会返回成功,这会导致在一定时间之内,客户端从不同的机器上面读取到的是数据是不一样的。例如 redis 主从异步复制架构,当 master down 掉,系统会切换到 slave,由于是异步复制,salve 不是最新的数据,会导致一致性的问题。

    二、一致性协议
    2.1 两阶段提交协议(2PC)
    2.2 三阶段提交协议(3PC)
    2.3 Paxos协议
    2.4 Raft协议

    三、Zookeeper 原理
    3.1 概述
    3.2 基本概念
    3.3 常见的误区
    3.4 选举同步过程
    3.5 同步的过程

    四、使用 Raft + RocksDB 有赞分布式 KV 存储服务

    五、总结
    本文从三个方面介绍了一致性,首先是描述分布架构中的核心理论-CAP,以及其简单的证明。第二部分介绍了 CAP 里面协议,重点介绍了 Raft 协议。第三部分,重点介绍了常用的 zookeeper 原理。

    为了保证数据 commit 之后不可丢,系统都会采用(WAL write ahead log)(在每次修改数据之前先写操作内容日志,然后再去修改数据。即使修改数据时异常,也可以通过操作内容日志恢复数据)

    分布式存储系统中,是假设机器是不稳定,随时都有可能 down 掉的情况下来设计的。也就是说就算机器 down 掉了,用户写入的数据也不能丢,避免单点故障。为此每一份写入的数据,需要在多个副本中同时存放。例如 zk 节点数据复制,etcd 的数据复制。而复制数据给节点又会带来一致性的问题,例如主节点和从节点数据不一致改如何去同步数据。也会带来可用性的问题,如 leader 节点 down 掉,如何快速选主,恢复数据等。好在已有成熟的理论如 Paxos 协议,ZAB 协议 Raft 协议等做为支撑。

hi进行回复 取消回复

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