现在常用的开源分布式框架一个是阿里开源的dubbo,还有一个就是Spring cloud
最初的服务化解决方案是 相同服务提供一个统一的域名,然后客户端发送http请求,由Nginx负责请求分发和跳转,耦合了服务调用逻辑,相当于一个重量级的ESB;有以下几个缺点:
1:作为消费者不知道由哪个服务实例提供服务
2: 无法观测到服务消费者和服务提供者之间的通信频率和调运行状况
3:消费者的失败重发,加大了服务开发难度,Nginx没有统一的管理策略
综合种种原因,分布式框架诞生,dubbo就是一款很优秀的开源框架;他集成了服务注册中心和服务监控中心
服务提供者通过服务注册中心注册自己需要提供的服务,消费者则从注册中心订阅自己需要的服务;监控中心则是
统计消费者和提供者之间的通信频率、调度时间、运行状况
从框架的自身结构来看,dubbo也有其缺点
1:服务提供者和服务消费,很依赖第三方组件(zookeeper,redis),一旦该组件出了问题,框架本身也会启不起来
2:消费者严重依赖服务提供者,双方代码耦合度较高,一旦服务提供者在导jar包的过程中出错,程序就会出现问题
分布式框架系统定理 : C —— 数据一致性 A —— 服务可用性 P —— 服务对网络分区故障的容错性,分布式框架很难都满足,一般符合其中两者;包括dubbo在内的其它使用zookeeper的分布式框架是满足CP,因为当客户端发送请求时,集群正在进行master选举或者半数以上的机器宕掉,服务可用性就很难做到;而对于持续集成,快速演化微服务来说,可用性就显得尤为重要,spring cloud由此诞生
spring cloud和dubbo的区别
两者的区别也是各自的优劣
1:dubbo的服务注册与发现是用的zookeeper,spring cloud服务注册与发现用的是Eureka 后者各个节点之间都是平等的不存在主从关系,只要一个节点还在,就能保证服务正常调用,即使全部节点都死掉,服务与服务之间也能通过缓存调用信息,这就保证了微服务之间的调用足够的健壮
2:对于调用方式dubbo采用rpc的方式,代码耦合度高,spring cloud中的提供方和消费方通过http rest方式,不存在代码的强依赖显得更为灵活
---------------------
作者:苍白大神
来源:CSDN
原文:https://blog.csdn.net/u012547613/article/details/79283196?utm_source=copy