Go：微服务架构

微服务架构全景图

服务注册和发现

Client side implement

            1.调用需要维护所有调用服务的地址

            2.有一定的技术难度，需要rpc框架支持

Server side implement

            1.架构简单

            2.有单点故障

问题：在微服务架构中，为什么不选择传统的LVS方案？

注册中心

etcd注册中心

            1.分布式一致性系统

            2.基于raft一致性协议

etcd使用场景

            1.服务注册和发现

            2.共享配置

            3.分布式锁

            4.Leader选举

服务注册和发现的思考

            一定需要一致性么？

            Eureka 是一个AP系统，netflix开发，用来做高可用的注册中心

Raft协议详解

应用场景

            1.解决分布式系统一致性的问题

            2.基于复制的

工作机制

            1.leader选举

            2.日志复制

            3.安全性

基本概念

角色

            1.Follower角色

            2.Leader角色

            3.Candicate角色

Term（任期）概念

            在raft协议中，将时间分成一个个term（任期）

基本概念

复制状态机

心跳（heartbeats）和超时机制（timeout）

 

Leader选举

触发条件：

            1.一般情况下，追随者接到领导者的心跳时，把选举定时器清零，不会触发

            2.追随者的选举定时器超时发生时（比如leader故障了），会变成候选者，触发领导人选取

            3.选举过程  一开始，所有节点都是以Follower角色启动，同时启动选举定时器（时间随机，降低冲突 概率）

选举过程

            1.当定时器到期时，转为candidate角色

            2.把当前任期加+1，并为自己进行投票

            3.发起RequestVote的RPC请求，要求其他的节点为自己投票

            4.如果得到半数以上节点的同意，就成为Leader（Leader）。

            5.如果选举超时，还没有Leader选出，则进入下一任期，重新选举。

限制条件

            1.每个节点在一个任期内，最多能给一个候选人投票，采用先到先服务原则

            2.如果没有投过票， 则对比candidate的log和当前节点的log哪个更新，比较方式为谁的 lastLog 的 term 越大谁越新，如              果term 相同，谁的 lastLog 的 index 越大谁越新。如果当前节点更新，则拒绝投票。

日志复制

Client向Leader提交指令（如：SET 5），Leader收到命令后，将命令追加到本地日志中。此 时，这个命令处于“uncomitted”状态，复制状态机不会执行该命令。

Leader将命令（SET 5）并发复制给其他节点，并等待其他其他节点将命令写入到日志中，如 果此时有些节点失败或者比较慢，Leader节点会一直重试，知道所有节点都保存了命令到日志 中。之后Leader节点就提交命令（即被状态机执行命令，这里是：SET 5），并将结果返回给 Client节点。

Leader节点在提交命令后，下一次的心跳包中就带有通知其他节点提交命令的消息，其他节点 收到Leader的消息后，就将命令应用到状态机中（State Machine），最终每个节点的日志都 保持了一致性。

安全性

一个Candidate节点要成为赢得选举，就需要跟网络中大部分节点进行通信，这就意味着每一 条已经提交的日志条目最少在其中一台服务器上出现。如果候选人的日志至少和大多数服务器 上的日志一样新，那么它一定包含有全部的已经提交的日志条目。

RequestVote RPC 实现了这个限制：这个 RPC包括候选人的日志信息，如果它自己的日志比候选人的日志要新，那么              它会拒绝候选人的投票请求。

最新判断标准

            1.如果两个日志的任期号不同，任期号大的日志内容更新

            2.如果任期号一样大，则根据日志中最后一个命令的索引（index），谁大谁最新

实例分析

参考资料

            https://www.jianshu.com/p/aa77c8f4cb5c

            https://container-solutions.com/raft-explained-part-33-safety-livenessguarantees-conclusion/

            http://thesecretlivesofdata.com/raft/ 强烈推荐

            https://raft.github.io/raft.pdf

            https://github.com/maemual/raft-zh_cn/ 中文翻译

            http://www.yuxiumin.com/2017/08/12/raft-protocol-intro/ 异常情况

RPC调用

数据传输

            1.Thrift协议

            2.Protobuf协议

            3.Json协议

            4.msgpack协议

负载均衡

            1.随机算法

            2.轮询

            3.一致性hash

异常容错

            1.健康检查

            2.熔断

            3.限流

服务监控

日志收集

            1.日志收集端→ kafka集群→数据处理→日志查询和报警

Metrics打点

            1.实时采样服务的运行状态

            2.直观的报表展示

总结

            1.微服务的架构

            2.服务注册、发现机制

            3.raft协议基本了解

            4.RPC相关概念

            5.监控和报警相关概念