vlambda博客
学习文章列表

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

传统基础设施面临的挑战

  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监控服务

实际操作