微服务相关概念

技术

服务治理基本概念

  1. 服务的伸缩控制
  2. 身份验证与授权 *
  3. 服务注册与发现 *
  4. 反向代理与负载均衡
  5. 路由控制 *
  6. 流量切换 *
  7. 日志管理 *
  8. 性能度量、监控与调优 *
  9. 分布式跟踪 *
  10. 过载保护 *
  11. 服务降级 *
  12. 服务部署与版本升级策略支持 *
  13. 错误处理 *
  14. 国际化

服务的伸缩控制

身份验证与授权

服务注册与发现

  1. dubbo zookeeper

反向代理与负载均衡

  1. vertx
  2. nginx
分布式 服务治理 算法 CAP

Dubbo

技术

Dubbo在项目中的作用

分布式服务架构

  1. 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。
    并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

  2. 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
    这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

  3. 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
    为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。
    其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

架构

角色

  1. Provider: 暴露服务的服务提供方。
  2. Consumer: 调用远程服务的服务消费方。
  3. Registry: 服务注册与发现的注册中心。
  4. Monitor: 统计服务的调用次调和调用时间的监控中心。
  5. Container: 服务运行容器。

调用关系

  1. 服务容器负责启动，加载，运行服务提供者。
  2. 服务提供者在启动时，向注册中心注册自己提供的服务。
  3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
  4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
java 分布式 dubbo 服务治理 rpc

Paxos

技术

作者介绍

1982，Lamport 提出了一种计算机容错理论，并于1900年论证。
这是一种
基于消传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。

时间时钟、面包店算法、拜占庭将军及paxos算法的创建性容错

paxos的目的

提高分布式系统容错性的一致性算法

核心

一致性算法

算法三个角色：

Proposer
Acceptor
Learner

规则

paxos 描述：

参与者之间可以进行通信，可以记录一些信息，来确定最终的值
消息内容不会被篡改

知行学社的分布式系统与Paxos算法 对paxos算法核心思想的描述

  • 在抢占式访问权的基础上引入多acceptor

  • 保证一个epoch,只有一个proposer运行，proposer按照epoch递增的顺序依次运行。

  • 新的epoch的proposer采用后者认同前者的思路运行。

  • 在肯定旧epoch无法生成确定性取值时，新的epoch 会提交自己的取值。不会冲突。

  • 一旦旧epoch形成确定性取值，新epoch肯定可以获取到此取值，并且会认同此取值，不会破坏。

分布式 算法 一致性算法 CAP

zookeeper学习及项目实践

技术

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 。

它设计一种新的数据结构——Znode，然后在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操作。有了这些数据结构和原语还不够，因为我们的ZooKeeper是工作在一个分布式的环境下，我们的服务是通过消息以网络的形式发送给我们的分布式应用程序，所以还需要一个通知机制——Watcher机制。那么总结一下，ZooKeeper所提供的服务主要是通过：数据结构+原语+watcher机制，三个部分来实现的。

使用场景下会使用zookeeper

  1. 项目中在监控mongodb的oplog来进行同步数据库的变更给别的部门.若想做的多机互备,就需要使用到分布式锁,由一台机器进行对oplog的变化进行同步
  2. 项目在定时发送提醒,多台服务器进行周期扫库操作,也同样用到了1中的分布式锁
  3. 假设我们有20个搜索引擎的服务器(每个负责总索引中的一部分的搜索任务)和一个总服务器(负责向这20个搜索引擎的服务器发出搜索请求并合并结果集)，一个备用的总服务器(负责当总服务器宕机时替换总服务器)，一个web的cgi(向总服务器发出搜索请求)。搜索引擎的服务器中的15个服务器提供搜索服务，5个服务器正在生成索引。这20个搜索引擎的服务器经常要让正在提供搜索服务的服务器停止提供服务开始生成索引，或生成索引的服务器已经把索引生成完成可以提供搜索服务了。使用Zookeeper可以保证总服务器自动感知有多少提供搜索引擎的服务器并向这些服务器发出搜索请求，当总服务器宕机时自动启用备用的总服务器.—分布式系统协调 ZooKeeper

zookeeper来源是什么?

ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。

协议

  1. 每个Server在内存中存储了一份数据；
  2. Zookeeper启动时，将从实例中选举一个leader（Leader选举算法采用了Paxos协议；Paxos核心思想：当多数Server写成功，则任务数据写成功。故 Server数目一般为奇数）；
  3. Leader负责处理数据更新等操作（Zab协议）；
  4. 一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。

结构组成

  1. Leader 负责进行投票的发起和决议,更新系统状态
  2. Learner–>跟随者Follower 用于接收客户请求并向客户端返回结果,在选择中参与投票
  3. Learner–>观察者Observer 可以接收客户端连接,将写请求转发给Leader节点,但其不参悟投票过程,只同步Leader的状态.其目的是为了扩展系统,提高读取速度
  4. client 请求发起方

具体用在哪里

  1. 配置管理,一处修改,监听者进行更新
  2. 命名服务
  3. 分布式锁 即 Leader Election
  4. 集群管理
  5. 队列管理

Zookeeper文件系统

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：

  1. PERSISTENT-持久化目录节点:客户端与zookeeper断开连接后，该节点依旧存在
  2. PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点:客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
  3. EPHEMERAL-临时目录节点:客户端与zookeeper断开连接后，该节点被删除
  4. EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点:客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

Zookeeper的特点

  1. 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。
  2. 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。
  3. 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
  4. 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。
  5. 原子性：更新只能成功或者失败，没有中间状态。
  6. 顺序性：所有Server，同一消息发布顺序一致。

场景分析

  1. 分布式锁的场景使用
zkCli.sh -server x.x.x.x:4180

ls /key

>[data, leader]

[zk: x.x.x.x:4180(CONNECTED) 6] get /key/leader

cZxid = 0xc1098cd0b0
ctime = Sun Jul 16 13:10:01 CST 2017
mZxid = 0xc1098cd0b0
mtime = Sun Jul 16 13:10:01 CST 2017
pZxid = 0xc112aec1c0
cversion = 152
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 2

[zk: x.x.x.x:4180(CONNECTED) 7] ls /key/leader
[_c_7ea9234d-3973-4e1d-8a6a-e2e30062cdc4-latch-0000000076, _c_5444e12a-c7ef-48bb-8ee6-271eea4a1c29-latch-0000000075]
[zk: x.x.x.x:4180(CONNECTED) 8] get /key/leader/_c_7ea9234d-3973-4e1d-8a6a-e2e30062cdc4-latch-0000000076
24
cZxid = 0xc112aec1c0
ctime = Fri Mar 30 16:58:50 CST 2018
mZxid = 0xc112aec1c0
mtime = Fri Mar 30 16:58:50 CST 2018
pZxid = 0xc112aec1c0
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0xd5848ddc5ec71f6
dataLength = 2
numChildren = 0

[zk: x.x.x.x:4180(CONNECTED) 9] get /key/leader/_c_5444e12a-c7ef-48bb-8ee6-271eea4a1c29-latch-0000000075
5
cZxid = 0xc1123e0f90
ctime = Tue Mar 27 10:55:03 CST 2018
mZxid = 0xc1123e0f90
mtime = Tue Mar 27 10:55:03 CST 2018
pZxid = 0xc1123e0f90
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x259977a5b1b3de0
dataLength = 1
numChildren = 0


经典文章链接

zookeeper系列
Leader选举
基本概念

java 分布式 zookeeper