

首页  思维导图  详情



微服务学习-请收藏

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人，可以考虑

服务拆分方法

业务维度拆分

安装业务的关联程度，比较密切的业务拆分为一个微服务

功能维度拆分

按照是否有公共的被多个其他服务调用，且依赖的资源不与其他的业务耦合

主要考虑的问题

服务如何定义

服务如何发布和订阅

服务如何监控

服务质量

故障定位

如果觉的有用，请帮忙点赞收藏，谢谢！

 Collect

Get Started

 Collect

Get Started

微服务架构

 Collect

Get Started

Kubernetes微服务架构图、K8s微服务架构图

 Collect

Get Started

收藏试题





0 条评论

下一页