微服务架构概论-无状态通信
2023-01-12 10:51:12 0 举报
微服务架构中无状态通信原理剖析
作者其他创作
大纲/内容
服务端
微 服务
R
AIPApiIP
W
Socket
C
服务是无状态的业务一定是有状态的应用一定是用状态的
网卡
一致性幂等性事务性
LB 负载均衡算法轮询随机最少连接hash 源 IP session：亲密度权重动态权重
IOSC
线程
kernel
zk
QUEUE
FD
重复提交不能通过服务无状态解决
BB
负载均衡LVS
基于数据的负载均衡一致性会破坏可用性CAP定理就会带入设计的复杂度
多级缓存技术
T2
message
MSG:search1
服务方法search
Restful
encoder decoder
I/O模型层
通过消息不能识别依托于这种消息(依赖协议)无状态 http如果在消息上加上ID，那么就是有状态了
全链路追踪、压测
User
FRONT-END应用
MVC分层进程
约束
拆解分层
B
传递一致性paxos
LB
server
S
TCP
内部状态的推敲tradeoff淘宝技术这十年
1，连接TCP
订单结账
分治缓存
Dispatcher
DBREDISTOMCAT
负载均衡限流降级熔断治理！
可用性最终一致性
APP Client
连接管理模型
C/S：前后端的概念？不清晰B/S：清晰C/P：C/S->IOS app 非常清晰了 Api接口
动态代理
T1
通信：RPC <> RESTFUL(除了http，还没有一个工业级的协议)
A
可用性全量主备主从 读写分离性能的优化
可扩展
LVS
选主的这个需求：主从模式主备模式
假设你有10CPU线程池线程数量队列
HTTP PROXY
keepalived
REDIS
防穿透技术
连接是独享的，不能穿插其他message
SERVICE
连接池
通信：协议消息标识
搜索引擎倒排索引htmljson
FRONT-END
重复提交
SOA
动静分离技术
API网关CORS 开
MSG:buy2
Loop
通信完成7层才能完成通信
连接 < 通信
服务无状态 ： 分布式问题
通信无状态
Z
服务方法buy
队列+线程池
算法
S1
tomcatMVC
zkClient
Proxy
缓存
buffer
远程调用：rpc == restful == 人通过浏览器访问server
y
限流技术
VIP
service商品详情页
在堆服务做负载均衡的同时，其实包含了高可用的特性
通信无状态无状态通信
Node.jsNginx(模板)
DB
x
问题：长连接 网关nginx 代理 连接网约车？wifi -- 4G接入互联网，socket 不稳定 内网模式下 RPC hadoop，spark两次通信和连接没有关系角色--> 连接（通信）--> 【心跳】【状态】-->耦合，约束http
client
通信：协议http《没有id》
高并发高可用可扩展
淘宝技术这十年
高可用
微服务划分需要考量成本3
BACK-END
API网关
nginx node.js七层 URI 三次握手反向代理+LB（）
降级技术快速失败
Service Mesh
1，如果只有1个线程，能不能行？2，只有1个线程池，10个线程3，设计成10个线程池，每个线程池1个线程（）*，资源隔离，线程池管理方式若干个线程池，每个线程池若干线程
location uri { proxy_pass http://url; LB}
AIP
因为服务方是天生基于HTTP 的servernginxhttpdtomcatjetty on http容器
有约束关系的无状态有状态
熔断开关开关半开
RS2
协议：httprestful！
redis
连接方式
RS1
跨域CORS
“微“服务
S2
CDN
1，重复提交对不对？欢迎：可用性，补偿2，可能是并发：分布式锁+识别
业务高内聚性能提高网关
SERVICE业务
双方是否有约束很难解耦！！
参数dubbo C-PC 连接数连接池 线程池？？
连接管理模型 每请求 每连接连接池
内幂（拒绝，正确） 外一 （一致性）
FRONT-ENDLOGIN
服务方法ooxx
单体 -》 多机微服务
补偿中转，代理进步：service mesh
Node.jsNginx(模板)网关
粘性亲密性
负载均衡技术
API 网关
私域
高性能
网关
倾斜sharding代理
动态扩缩容负载均衡
全量
RpcEnv
index.html标签 jpg 其他域名域名CDN
电商图片ZBPB缩略图先生成缩略图吗
同步成本，一致性问题
静态
一样镜像
单点故障压力大
<id1>:message1
lvs lb 四层 数据包
功能服务
服务偏业务
redisdb
service商品详情页计算 缩略图缓存
1，consumer provider 不能有约束 【基于http的restful】2，多次通信和连接没有关系，和上次通信没有关系 【http天生就是这么设计的】*，更容易实现架构的扩展，和整合
状态即【数据】程序=算法+数据结构数据在C端数据在P端数据在S中数据在D中算法在C端算法在P端算法在S端数据在R时数据在C时：唯一ID数据在D时：唯一ID数据在U时基于成本的tradeoff
流程TCP/IP
<id2>:message2
并发下分布式锁串行化同步转异步状态机流转原子性乐观锁CAS
你品，你细品
有状态
微服务划分参考AKF
APP
session 共享状态
C/S -> B/Sajax 同源限制
灰度发布技术
传递一致性paxoszab
service mesh
前后端分离
LB健康检查
Restfulon http 工业级
客户端在负载情况下不受影响在RPC模式下没有绝对的影响的！！！约束
熔断技术
通信
数据2中存储方式全量分片
高并发
ESB可有可无的
通信无状态无状态通信去设计
data行为数据
C / B
基于计算(TOMCAT)的负载均衡隐含了HA
RPC V.S RESTFUL
SSO
有状态通信无状态通信？
0 条评论
回复 删除
下一页
