微服务学习-请收藏
2021-07-22 00:02:45 27 举报AI智能生成
微服务学习-请收藏
作者其他创作
大纲/内容
架构
服务描述
RESTful API
跨语言平台，组织内外皆可
缺点：使用了HTTP作为通讯协议，相比TCP协议，性能较差
IDL文件
跨语言平台，组织内外皆可
缺点：修改或者删除PB字段不能向前兼容
XML配置
java平台，一般用作组织内部
缺点：不支持跨语言平台
注册中心
架构
注册中心架构
工作流程
1.服务提供者在启动时，根据服务发布文件中配置 的发布信息向注册中心注册自己的服务
2.服务消费者在启动时，根据消费者配置文件中的配置服务信息向注册中心订阅自己所需要的服务
3.注册中心返回服务者提供地址列表给服务消费者
4.当服务提供者发生变化，比如有节点新增或者销毁，注册中心将变更通知给服务消费者
问题？
两个服务是否会相互调用？
服务框架
通信框架
网络连接
http通信
socket通信
服务端处理请求
同步阻塞（BIO）
同步非阻塞（NIO）
异步非阻塞（AIO）
通信协议
数据传输协议
例如http
问题：传输协议和网络连接不是应该一致吗？
序列化和反序列化
Protobuf
性能高、高压缩
json
可读性好
xml
服务监控
监控对象
用户端监控
接口监控
资源监控
基础监控
监控指标
请求量
响应时间
错误率
监控维度
全局维度
分机房维度
单机维度
时间维度
核心维度
对核心业务应当重点保障，分开监控
监控系统原理
数据采集
服务主动上报
通过在业务代码中或者服务框架中计入数据收集代码，主动上报服务的调用信息。
代理收集
先把调用的详细情况记录到本地日志文件中，然后解析日志文件，采集调用信息。
注意：过高的采样率会导致系统写入磁盘的I/O过高，影响到正常的服务调用。
数据传输
UDP传输
Kafka传输
数据处理
数据聚合
接口维度聚合
机器维度聚合
持久化存储
索引数据库
时序数据库
数据展示
曲线图
饼状图
格子图
问题：能不能把系统监控也列为一个单独的服务？
服务追踪
作用
作用：通过跟踪记录，了解到一次用户请求都发起了哪些调用，经过哪些服务的处理。并且记录每一次调用所涉及的服务详细信息，如果调用失败，可以通过这个日志快速的定位是在哪个环节出现了问题。
优化系统瓶颈
优化链路调用
生成网络拓扑
透明传输数据
基本概念
traceid
用于串联某次请求在系统中经过的位置
spanid
用于区分系统不同服务之间的调用先后关系
annotation
用于业务自己定义一些自己感兴趣的数据
架构
数据采集层
数据处理层
数据展示层
服务治理
节点管理
注册中心主动摘除机制
消费者摘除机制
负载均衡
随机算法
轮询算法
最少活跃调用算法
一致性hash算法
服务路由
恢复发布的需要
灰度发布是指，通过类似按尾号进行灰度的规则限定只有一定比例的人群才会访问新发布的服务节点
多机房就近访问的需求
服务容错
FailOver失败自动切换
服务消费者发现调用失败后，自动从可用的服务节点列表中选择下一个节点进行调用
可以设置重试次数，这种策略要求是幂等的，就是说无论调用多少此，只要是同一个调用，返回的结果都是相同的。一般适合服务器调用是读请求的。
FailBack失败通知
服务消费者调用失败或者超时后就不再重试，而是根据失败信息，来决定后续的执行策略。
例如非幂等的场景中，调用失败后，应当查询服务端的状态，看调用到底是否已经生效，如果没有生效可以再调用一次，如果已经生效就不能再次调用。
FailCache失败缓存
服务消费者在调用失败或者超时后，不立即发起调用，而是隔一段时间再次调用。可能在一段时间内，服务都有问题，这时候立即调用会加剧问题，
FailFash快速失败
就是在调用失败后，不在重试，一般在非核心业务的调用时，会采用快速失败的策略，记录一下日志就返回了。
Dubbo
服务发布过程
服务提供者发布XML配置
提供方的信息（应用名）
注册中心地址
dubbo的端口
提供服务接口
声明和本地bean一样实现服务？？？？什么是bean？
消费者发布XML配置
消费方应用名
注册中心地址
生成远程服务代理，可以和本地bean一样使用服务
注册中心
存储服务信息
分组信息
服务名
节点信息
节点地址
节点其他信息
工作流程
服务提供者提供注册流程
注册的节点是否在白名单内
注册的cluster（服务的接口名）是否存在
服务的分组是否存在
将节点信息添加到对应的service和cluster下面存储
服务提供者提供反注册流程
查看服务分组是否存在
查看cluster是否存在
删除存储中的service和cluster下对应的节点
更新cluster的sign值
消费者查询流程
首先从localcache（本机内存）中查找
接着从snapshot（本地快照）中查找
最后从注册中心查找
服务消费者订阅变更流程
服务消费者从注册中心获取到了服务信息后，就会在本地保留cluster和sign值
消费者每过一段时间，就会调用getSign（）从注册中心获取服务端该cluster的sign值，并与本地保留的sign值做对比
如果不一致，就更新班底的localcache和snapshot
其他
多注册中心
并行订阅服务
批量反注册服务
服务变更信息增量更新
定义
微服务架构是将负责臃肿的单体应用进行细颗粒度的服务化拆分，每个才分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率
特点
服务拆分颗粒度更细
服务独立部署
服务独立维护
服务治理能力要求高
使用条件
初期不适合服务化
项目第一阶段主要目标是快速开发和验证想法，架构不适合过度设计。单体应用更加高效、节省成本
根据经验（不是我的），单体应用同时开发的人员超过10人，可以考虑
服务拆分方法
业务维度拆分
安装业务的关联程度，比较密切的业务拆分为一个微服务
功能维度拆分
按照是否有公共的被多个其他服务调用，且依赖的资源不与其他的业务耦合
主要考虑的问题
服务如何定义
服务如何发布和订阅
服务如何监控
服务质量
故障定位
如果觉的有用，请帮忙点赞收藏，谢谢！
0 条评论
下一页
