在微服务架构中,监控系统按照原理和作用大致可以分为三类:
组件介绍
Elasticsearch
是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。Logstash
是一个完全开源的工具,他可以对你的日志进行收集、过滤,并将其存储供以后使用(如,搜索)。Kibana
也是一个开源和免费的工具,它Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助您汇总、分析和搜索重要数据日志。Kafka
:接收用户日志的消息队列工作流程图
1.生成项目网络拓扑图
2.快速定位问题
3.优化系统
主要原理就是子节点会记录父节点的id信息,要理解好三个核心的概念:Trace、Span、Annotation。
Trace
Span
Annotation
具体流程:
CAT
Open Zipkin
pinpoint
方案选型比较
Metrics一般有5种基本的度量类型:
1.Gauges(度量) 2.Counters(计数器) 3.Histograms(直方图) 4.Meters(TPS计算器) 5.Timers(计时器)
Prometheus
PromQL
:是Prometheus自带的查询语法,通过编写PromQL语句可以查询Prometheus里面的数据。Alertmanager
:是用于数据的预警模块,支持通过多种方式去发送预警。WebUI
:是用来展示数据和图形的,但是一般大多数是与Grafana结合,采用Grafana来展示。OpenTSDB
InfluxDB
系统层
应用层
用户层
监控指标
1.单机可用性风险
2.单机房可用性风险
3.跨机房集群可用性风险
1.超时
2.限流
3.降级
4.延迟异步处理
5.熔断
断路器其实就是一个状态机原理,有三种状态:
Closed
:闭合状态,也就是正常状态
Open
:开启状态,也就是当后端服务出故障后链路断开,不提供服务的状态
Half-Open
半闭合状态,就是允许一小部分流量进行尝试,尝试后发现服务正常就转为Closed状态,服务依旧不正常就转为Open状态。
Hystrix原理图
Hystrix断路器的原理图
传统单体应用的访问示意图:
在微服务架构下,一般有以下三种方案:
如图,这是一种采用基于令牌Token的授权方式。在这个模式下,是由授权服务器(图中Authorization Server)、API网关(图中API Gateway)、内部的微服务节点几个模块组成。
流程如下:
注意:此处也可以不换成JWT而是直接返回原Access Token。但是换成JWT更好,因为Access Token是一串不可读无意义的字符串,每次验证Access Token是否合法都需要去访问Authorization Server才知道。但是JWT令牌是一个包含JOSN对象,有用户信息和其它数据的一个字符串,后面微服务节点拿到JWT之后,自己就可以做校验,减少了交互次数。
这里面就使用到了OAuth2.0的原理,不过这只是OAuth2.0各类模式中的一种。
OAuth2.0 的流程如下图:
用户数据/资源存放的地方,在微服务架构中,服务就是资源服务器。在上面的例子中,微信头像存放的服务就是资源服务器。
是指用户,资源的拥有人。在上面的例子中某个微信头像的用户就是资源拥有者。
是一个用来验证用户身份并颁发令牌的服务器。
想要访问用户受保护资源的客户端/Web应用。在上面的例子中的视频网站就是客户端应用。
Access Token,授予对资源服务器的访问权限额度令牌。
客户端应用用于获取新的 Access Token 的一种令牌。
用户的账号密码,用于在 授权服务器 进行验证用户身份的凭证。
1.授权码(Authorization Code)
工作流程图:
2.简化式(Implicit)
工作流程图:
3.用户名密码(Resource Owner Credentials)
4.客户端凭证(Client Credentials)
先来看一下容器与虚拟机的对比区别:
Docker容器对这个进程的隔离主要采用2个核心技术点:
总结来说就是:Namespace 为容器进程开辟隔离进程,Cgroups限制容器进程之间抢夺资源,从此保证了容器之间独立运行和隔离。
举例:打个比方,就像是一个班级,每个人在这个班里都有一个编号,班里有90人,然后来了一位新同学,那他在班里的编号就是91,可是老师为了给这位同学特别照顾,所以在班里开辟了一块独立的看不到外面的小隔间,并告诉这个同学他的编号是1,由于这位同学在这个小空间里隔离着,所以他真的以为自己就是班上的第一位同学且编号为1,当然了,事实上这位同学在班上的编号依然是91。
例如:在 /sys/fs/cgroup/cpu 下面创建一个 dockerContainer 子目录,系统就会自动在这个新建的目录下面生成一些配置文件,这些配置文件就是用来控制资源使用量的。例如可以在这些配置文件里面设置某个进程ID对CPU的最大使用率。
举个例子,假如有文件夹 test1 和 test2 ,这两个文件夹里面的文件 有相同的,也有不同的。然后我们可以采用联合挂载的方式,将这两个文件夹挂载到 test3 上,那么 test3 目录里就有了 test1 和 test2 的所有文件(相同的文件有去重,不同的文件都保留)。
随着微服务的流行,容器技术也相应的被大家重视起来。容器技术主要解决了以下两个问题:
1.环境一致性问题
例如java的jar/war包部署会依赖于环境的问题(操着系统的版本,jdk版本问题)。
2.镜像部署问题
例如java,ruby,nodejs等等的发布系统是不一样的,每个环境都得很麻烦的部署一遍,采用docker镜像,就屏蔽了这类问题。
部署实践
下图是Docker容器部署的一个完整过程:
目前基于容器的调度平台有: