顺德网站制作案例效果百度网盘官方下载
一 :架构演变
1 单体架构: 简单理解为一个服务涵盖所有需求功能
2 垂直架构: 按照业务功能将单体架构拆分成小模块服务, 如:订单系统,用户系统,商品系统 ##缺点 引入分布式事务,分布式锁等,优点:模块解耦##
垂直拆分:根据业务层级拆分,比如商城的订单系统,用户系统,商品系统
水平拆分:根据业务拆分,用户系统,对处于同一个层级的服务做拆分,典型案例如数据库表将用户表拆分,分表操作
3 rpc(Remote Procedure Call Protocol):基于垂直架构,各个业务系统单独部署,但是之间需要有通讯,产生rpc概念 ##这块的Rpc只表示远程调用的概念,不作为通讯协议理解##
4 soa(Service-Oriented Architecture): 基于Rpc远程调用概念和垂直架构的背景,soa作为一种服务治理的思想出现,解决垂架构各个业务系统独过于独立的问题,使得各个业务系统能相互感知,由此诞生出注册中心(zookeeper,Eureka,Nacos,ServiceComb等)
5 微服务: 垂直架构就已经是微服务的雏形,搭配soa的思想后,各个业务系统将自己注册到注册中心,由注册中心维护各个服务的信息,完成各个服务之间的交互 ##soa是服务统一管理的思想,微服务是业务的具体实现##
二: 微服务治理体系
1 ServiceComb:go语言的,java版本的,基于RPC协议的
java chassis:开箱即用,在内部集成了Feign,Hystrix,Ribbon,优化了的熔断限流隔离机制,在Hystrix的基础上优化了线程的创建,负载均衡等,内部集成了SpringCloud的诸多组件,也是基于Rpc
Service-Center:注册中心是双层架构的,两个sc公用一个数据存储区,将实例信息缓存在其中,消费端和注册中心建立长连接,监控注册中心的服务实例信息
saga: ap模式的,各个服务各自提交各自的,谁有问题最后尝试重试,做事务补偿,或者向前做回滚,最终保持一致性
2 Eureka:
实例注册
心跳机制
定时拉取(实例缓存)
3 Nacos
实例注册
心跳机制
定时拉取(实例缓存)
4 zookeeper
实例注册->建立长连接->拉取最新实例缓存
参考图(网图)
三 :服务发现
1 SpringCloud服务发现原理: 服务端和消费端都将自 己注册到注册中心,注册中心维护一个大的map,保存注册上来的服务信息,各个服务通过定时向注册中心发送消息,即心跳机制,防止服务实例被注册中心剔除,同时会定时从注册中心拉取最新的实例信息缓存到本地 2 Dubbo服务发现原理: 服务端将自己注册到zk上,消费端在zk上订阅自己需要的服务,zk将消费方需要的服务通过长连接推送到消费端,消费端将信息缓存在本地,然后消费方发起Rpc调用服务端服务端有信息变更,注册中心zk会通过长连接将信息推送到消费端,dubbo没有心跳机制,但是基于长连接检测服务存活状态3 注册中心挂了服务实例之间还能相互调用的原理:不管是dubbo(zookeeper)还是Eureka,Nacos,都会定将注册中心的实例信息缓存到本地,注册中心不能用了,只是新的服务无法完成注册以及服务发现,但是之前已经存在的服务还是可以走缓存完成正常的调用
四 :注册中心连接方式
1 长连接和短链接概念:
长连接是双方简历socket不间断持续通讯,短链接建立socket后发送一次消息即关闭socket,形象一点,长连接就像是打电话,短链接就像是发消息
2 常见注册中心的分类
短连接: Eureka,Nacos(分版本,老版本短链接,新版本长连接)
长连接: zookeeper,ServiceComb,Nacos(分版本,老版本短链接,新版本长连接)
3 类比:
长连接: 及时的同步实例信息,如果有变更实例，注册中心将基于长连接及时的变更后的数据给消费者
短连接:实例变更,注册中心上的实例信息不会第一时间通知到消费短服务,消费端是定时拉取的
注意:存在时间差的
五 :注册中心cap理论的应用
CP:zookeeper保证了cp,强一致性,zk的master挂了后会重新选举领导,选举期间注册中心对外不可用,zk一般是长连接,严格要求各个实例上的节点信息一致
AP:Eureka和RocketMq的命名服务器一样,各个service是平等的,但是Eureka会相互注册,Eureka的某个节点挂了,其他节点照样可以正常工作,只是暂时的节点数据不一致,当挂掉的节点恢复后会从那个正常节点上同步数据,Eureka保证了临时节点数据不一致,但是基本可用,最后一致
注意: nacos的新版本支持AP和CP,设置即可
六: 微服务体系的类比
1 http协议和rpc协议:
相同点:都是基于tcp/ip的传输层协议
不同: http传输数据是面向互联网大众应用的,做的封装和数据格式比较的繁杂,报文体系比较大,数据载体冗余,造成传输效率就比RPC低,RPC传输协议是面向服务对象,是一种专门根据服务量身定制的协议,因此只能在两个约定的服务上,不能跨应用,否则无法解析数据,Rpc去除了http多余的封装,数据包比http数据包小的,量身定制,数据包缩小,因此RPC比http效率高,Rpc也可以基于http
2 Dubbo和SpringCloud对比以及ServiceComb体系
Dubbo是长连接,注重的是服务分层,讲究的是效率,基于rpc
SpringCloud是短链接,基于http,是诸多丰富组件的合成体
ServiceComb是长链接,基于RPC,集成了SpringCloud的常用组件,SpringCloud像是台式机,ServiceComb更像是一体机
六 : 结语
综上所述,仅代表个人认知,欢迎指错