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

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

注册中心对比

特性	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.弱一致性：能容忍读取到的数据不一定一致