微服务理解篇

一 :架构演变

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 服务发现原理 : 服务端和消费端都将自 己注册到注册中心,注册中心维护一个大的map,保存注册上来的服务信息,各个服务通过定时向注册中心发送消息,

即心跳机制,防止服务实例被注册中心剔除,同时会定时从注册中心拉取最新的实例信息缓存到本地

2 注册中心挂了服务实例之间还嫩相互调用的原理 :

不管是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更像是一体机

六 : 结语

综上所述,仅代表个人认知,欢迎指错

相关推荐
稻草人222216 小时前
java Excel 导出 ,如何实现八倍效率优化,以及代码分层,方法封装
后端·架构
数据智能老司机17 小时前
精通 Python 设计模式——创建型设计模式
python·设计模式·架构
数据智能老司机18 小时前
精通 Python 设计模式——SOLID 原则
python·设计模式·架构
咖啡Beans21 小时前
SpringCloud网关Gateway功能实现
java·spring cloud
bobz96521 小时前
k8s svc 实现的技术演化:iptables --> ipvs --> cilium
架构
云舟吖1 天前
基于 electron-vite 实现一个 RPA 网页自动化工具
前端·架构
brzhang1 天前
当AI接管80%的执行,你“不可替代”的价值,藏在这20%里
前端·后端·架构
Lei活在当下1 天前
【业务场景架构实战】4. 支付状态分层流转的设计和实现
架构·android jetpack·响应式设计
架构师沉默2 天前
设计多租户 SaaS 系统,如何做到数据隔离 & 资源配额?
java·后端·架构
kfyty7252 天前
不依赖第三方,不销毁重建,loveqq 框架如何原生实现动态线程池?
java·架构