常用的微服务组件和中间件
注册中心对比
特性 | 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.弱一致性:能容忍读取到的数据不一定一致