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

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

=Start=

缘由:

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

正文:

参考解答:

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

参考链接:

=END=

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

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

  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 协议等做为支撑。

  4. 分布式系统原理介绍
    http://guanzhou.pub/2018/06/04/Distributed/

    1 概念
    1.1 模型
    节点
    异常
    1.2 副本
    副本一致性
    1.3 衡量分布式系统的指标
    2 分布式系统原理
    2.1 数据分布方式
    哈希方式
    按数据范围分布
    按数据量分布
    一致性哈希
    副本与数据分布
    本地化计算
    数据分布方式的选择
    2.2 基本副本协议
    中心化副本控制协议
    primary-secondary 协议
    数据更新基本流程
    数据读取方式
    primary 副本的确定与切换
    数据同步
    去中心化副本控制协议
    2.3 Lease 机制
    基于lease 的分布式cache 系统
    lease 机制的分析
    基于lease 机制确定节点状态
    lease 的有效期时间选择
    2.4 Quorum 机制
    write-all-read-one
    Quorum 定义
    读取最新成功提交的数据
    基于Quorum 机制选择primary副本
    2.5 日志技术
    Redo Log 与Check point
    Redo Log
    Check point
    No Undo/No Redo log
    2.6 两阶段提交协议
    流程描述
    异常处理
    宕机恢复
    协议分析
    2.7 MVCC
    2.8 Paxos协议
    角色
    流程
    例子
    2.9 CAP

  5. API网关从入门到放弃
    https://github.com/aCoder2013/blog/issues/35

    采用API网关,实现一个API网关接管所有的入口流量,类似Nginx的作用,将所有用户的请求转发给后端的服务器,但网关做的不仅仅只是简单的转发,也会针对流量做一些扩展,比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等,这样将通用的逻辑抽出来,由网关统一去做,业务方也能够更专注于业务逻辑,提升迭代的效率。

    通过引入API网关,客户端只需要与API网关交互,而不用与各个业务方的接口分别通讯,但多引入一个组件就多引入了一个潜在的故障点,因此要实现一个高性能、稳定的网关,也会涉及到很多点。

发表评论

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