架构理论微服务组件以及分布式理论

Posted 2023-04-03 terrybg

常用的微服务组件和中间件

注册中心对比

特性	Nacos	Etcd	Consul	Eureka	Zookeeper
公司	Alibaba	CoreOS	HashiCorp	Netflix	Apache
活跃度	非常活跃	活跃	较活跃	较活跃	一般
开发语言	Java	GO	GO	Java	Java
CAP	AP/CP	CP	CP	AP	CP
一致性算法	Raft	Raft	Raft	无	Paxos中ZAB
暴露接口	HTTP/DNS	HTTP/grpc	HTTP/DNS	HTTP	客户端

分布式锁：Redis（Redision、RedisLock + Lua脚本）、Zookeeper、mysql

分布式配置中心：Nacos、SpringCloud Config、Apollo、Consul、Zookeeper

网关：Gateway、Zuul、nginx

负载均衡：Nginx、Haproxy、Keeplived + LVS、Ribbon、F5

分布式消息中间件：Kafka、RabbitMQ、RocketMQ

服务保护：Alibaba Sentinel、Hytrix

分布式事务：Alibaba Seata、LCN

分布式任务调度：XXL-Job

分布式日志采集：elk + kafka

分布式服务追踪：SkyWalking、Sleuth + zipkin

数据库读写分离分库分表技术：Sharding Sphere-Jdbc、MyCat

数据库同步工具：Canal

分布式理论

注册中心的CAP理论

一致性（Consistency）：同一时间所有节点数据一致。

可用性（Availability）：部分节点故障服务仍然可用。

分区容错性（Partition tolerance）：任意信息的丢失或失败不会影响系统的继续运作。

P是一定要实现的，C和A两者不可兼得。所以注册中心是CP、AP模式。

常见的注册中心

Eurka：AP模式。

Zookeeper：CP模式。

Nacos：AP模式、CP模式二选一。

Consul：CP模式。

BASE理论

BASE理论是建立在AP的基础上，AP模式缺点会造成数据短暂不一致。

Basically Available（基本可用）：指出现故障的时候，允许损失部分可用性，保证核心可用；

Soft-state（软状态/柔性事务）：允许系统在不同节点间副本同步的时候存在延时；

Eventual Consistency（最终一致性）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性

数据一致性的三个级别

1.强一致性：无论何时都要保证数据一致。

2.最终一致性：允许一定的延迟，但是数据最终会一致。

3.弱一致性：能容忍读取到的数据不一定一致

微服务架构服务注册中心的数据一致性问题

微服务架构服务注册中心的数据一致性涉及的理论是CAP理论。CAP（Consistency，Availability，Partition Tolerance）理论，是由Eric Brewer教授提出并由Seth Gilbert 和 Nancy Lynch两人证明了其正确性的一套分布式理论。该理论阐述了一个分布式系统的三个主要方面，分别是数据一致性（Consistency）、系统可用性（Availability）和分区容忍性（Partition Tolerance），如图1所示。数据一致性是指分布式环境下，多个节点的数据是否强一致；系统可用性是指分布式服务能一直保持可用状态，当用户发出一个请求后，服务能在有限时间内返回结果；而分区容忍性特指对网络分区的容忍性，其中，分区容忍性又是不可或缺的。CAP 理论说明，在分布式系统中，一致性、可用性和分区容忍性3个要素最多只能同时满足两个，三者不可兼得。

图1  CAP的三个要素图

CAP理论包含3个内容，分别是一致性、可用性和分隔容忍。一致性模型可以分成以下三类：第一强一致性，数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现；第二弱一致性，数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到；第三最终一致性，弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW 算法分析来实现。这三者的相互渗透融合，可形成图2的交叉内容。

                            

图2 CAP相互交叉的三种组合图

交叉内容可以形成3种组合，分别是CA 组合（Consistency高一致性 + Availability高可用性）、CP组合（Consistency高一致性 + Partition tolerance分区容错性）和AP组合（Availability高可用性 + Partition tolerance分区容错性）。其中CA组合可以通过2PC 两阶段事务提交来保证。其缺点无法实现分区容错性，一旦某个操作失败，整个系统就出错，这种组合一般应用在传统的关系数据库，如Oracle数据库等。CP使用Paxos算法来保证，可用性降低，其应用有HBase、MongoDB数据库等。AP使用Gossip算法等实现最终一致性，其应用有Cassandra、Dynamo等。

下面通过几个实际软件平台来进行说明。

① ZooKeeper框架采用CP组合

ZooKeeper框架是采用CP组合策略模式，即Consistency高一致性 + Partition tolerance分区容错性。也就是说，服务注册功能对一致性的要求要高于可用性。ZooKeeper框架采用的是 Paxos算法。

这主要是针对ZooKeeper集群会出现的一种特殊场景，当ZooKeeper集群的master节点因异常原因与其他节点失去联系时，剩余节点会重新进行Leader选举。可是选举Leader的时间太长，一般需要30 ~ 120s，且选举期间整个ZooKeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。而这种情况在应用环境中是经常性概率事件，虽然服务能够最终恢复，但较长的选举时间会导致ZooKeeper集群的服务长期处于不可用状态。

② Eureka框架采用AP组合

Eureka框架是采用AP组合策略模式，即Availability高可用性 + Partition Tolerance分区容错性。也就是说，框架对可用性的要求要高于一致性。

Eureka框架提供了一个弱一致的服务视图，使用尽力而为的复制策略，在设计时优先保证可用性。Eureka框架各个节点都是平等的，部分节点挂掉后剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka框架注册时或如果发现连接失败时，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用，这实际上就是高可用性，也许检索到的信息可能不是最新的，即不能保证强一致性。因此，Eureka框架可以很好地应对异常原因导致部分节点失去联系的情况，而不会像ZooKeeper框架那样使整个注册服务瘫痪。

③ Consul框架采用CA组合

Consul框架采用CA组合策略模式，即Consistency高一致性 + Availability高可用性。也就是说，高可用性和高一致性。

Consul框架能提供较高的可用性，使用Raft算法，通过k/vStore服务来保证一致性。同时Consul框架也提供强大的一致性保证，因为服务器使用Raft协议复制状态。客户端节点参与健康检查，该检查分发健康检查工作，发现请求被路由到选举出来的领事来进行领导，这使他们默认情况下强烈一致。Consul框架强烈的一致性意味着它可以作为领导选举和集群协调而锁定服务。Consul框架强一致性带来的是服务注册相比会稍慢一些。因为Consul框架的Raft协议要求必须过半数的节点都写入成功才认为注册成功，Leader挂掉时，重新选举期间整个Consul不可用。故Consul框架保证了强一致性却牺牲了可用性。