2.《持续演进的Cloud Native 云原生架构下微服务最佳实践》读书笔记-第三章

Posted 2021-04-06 香蜜湖的蜜

传统基础设施面临的挑战

1. 资源利用率低

2. 服务器数量呈爆炸性增长，难以管理

3. 没有标准化

4. 脆弱的基础设施

基于容器的敏捷基础设施

目标如下

1. 标准化

2. 可替换

3. 自动化

4. 可视化

5. 可追溯

6. 快速

容器VS虚拟机

容器：操作系统上进行虚拟化，严格意义上说，容器并不是虚拟化，因为所有容器都共享内核

虚拟机：硬件基础上进行虚拟化，隔离性更高

分析

资源利用率：容器轻量级

创建速度：Docker的启动速度是秒级，虚拟机是分钟级

性能：虚拟机需要运行完整的Guest OS,容器相当于一个进程

隔离性：虚拟机高，容器低

安装Docker

这个要研究一下！

基于公共基础服务的平台化

监控告警服务

监控数据采集

1. 直接上报，通过SDK直接连监控服务，发送OR通过监控拉取相应的监制数据

2. 日志上报：通过日志文件

3. 通过agent上报

监控数据接收模式

1. push

2. pull

通过时间序列数据库存储监控数据

横轴时间，纵轴是数值。如：influxDB，OpenTSDB，druid，Graphite....

特点

• 写多读少，大部分时间是写入，写入是顺序，但读的时候并发量也有可能很高

• 数据量较大，内存一般放不下，属于IO密集型

• 读操作的时候需要按按照时间排序，升序or降序

开源监控系统实现Prometheus

一套开源的监控，报警，时间序列数据库的组合，非常适合监控Kubernetes

特点

1. 存储量大，不依赖其他存储系统，安装非常简单

2. 灵活的查询语言：PromQ1

3. 通过基于HTTP的pull方式采集时序数据，可以通过Pushgateway进行时序列数据推送

4. 多种可视化和仪表盘支持

Prometheus架构

自身的时序数据库，每个采样数据只点3.5byte左右，上百万条时间序列，30s间隔，保留60day，大概只占用200GB。支持通过配置文件，文本文件，ZK,Consul,DNS SRV lookup等方式指定抓取目标：主动抓取，业务推送

架构

1. Retrieval：负责定时去指定的API上抓取采样指标数据

2. Storage：负责将采样数据高效安全持久化存储到磁盘中

3. PromQL：负责提供查询

支持数据类型

1. Counter：单调递增数据，只能增加，不能减少，例如记录请求次数，错误数

2. Guage：当前的状态，常规值，可增可减。例如内存，CPU的使用情况

3. Histogram:主要用于在指定分布范围内(Buckets)记录记录大小or事件的次数

4. Summary：客户端定义的数据分布统计图

Alertmanger

独立的组件，报警功能。

通过Prometheus和Grafana监控服务

实际操作