单个应用承载复杂逻辑,应用实例数量有限,本地Debug可以解决大部分问题。
业务逻辑模块化拆分,节点数量依然可控,简单节点指标检查和架构自带调用链可以满足诉求。日志检索问题初现。
服务部署容器化,节点数量无法手动管理。K8s控制面+Prometheus成为标配,ELK协助日志汇聚,检索。Tracing诉求强烈,OpenTracing&OpenTelemetry出现。
运行时虚拟化,应用架构层次增多。复杂架构直接影响故障排查速度。
我们逐渐我们来到了容器时代,来了微服务来到了微服务时代,K8s架构给我们带来了很多很好的功能,比如说负载均衡,比如说我们的弹性可伸缩的能力,但是它其实本质上在我们整个的一个架构中间加了一层。
我个人认为K8s给我们开发者就是最大的一个关键点,就是它抽象出了Pod的这样一个概念。我们以前都是把服务部署在虚拟机上或者是物理机上面,现在我们的服务都是部署在一个个的Pod之上,Pod变成了一个逻辑性的概念,它并不是绑定到某一台机器,如果你的服务CPU消耗很大,或者说内存消耗很大,它可以去调度到比如说资源更大的这样的一个Pod的这样一个节点机器上面去,他提供了这样的一种很灵活的一种调度能力。
由于中间多个一层,给我们的监控给带来了一个比较大的挑战,也是随着k8s的这样的一种能去调度这样一种去编排一种架构的一种盛行的话,我们现在特别多的业务都是在微服务化,一个请求它会经过几十个服务生上百个,你还是通过这种单点的方式,其实没有办法去快速的定位到问题。
所以这个时候其实催生就应运而生的,我们有一个确实ID这样的一个唯一ID的东西,能够去把我们的不同的节点不同的服务之间给串起来。
我们有了这样一个东西,我们就能够画出一个拓扑图,能够很快的去能够看到到底哪里在出问题。
这就是我们微服务的我们K8s架构的发展,然后给我们监控带来的挑战,然后也是我们的推进的一个凸现,然后我也给我们带来了一些应对这样的复杂架构的一些可观测,然后去定位问题一种能力。
随着DevOps模式的普及,规划、开发、测试、交付的效率越来越⾼。
架构从开始的⼀体化到分层模式,再到现在的微服务架构模式。
容器化的部署模式动态性增强,每个实例的⽣命周期变得更短。
云原⽣应⽤依赖云上的各类产品,上下游变得更多。
首先是我们的单体应用时代,通过指标,然后通过日志去解决问题,我们通过把非结构化的日志给抽象成了指标,然后我们能够去能够去产生一种告警,但其实大家仔细去想这个关系,我们的日志跟指标其实是串不起来的,很多时候我们是这样子去处理问题的,比如说我们收到一个指标的告警,比如说是一台机器的CPU的告警,或者是一个错误率的告警,这个时候一般我们开发者是怎么做的,其实大多数都是这样子,我们先去拿到对应的,比如说拿了一个apid或拿了一个uid这样的一种标识用户的信息,然后再拿到他的时间戳,然后可能再拿到返回码,可能还有一些比如说像一些什么接口名称,像一些应用名称等等这样的信息,我们拿了之后,我们再去到日志里面去搜索,我们去看这个时间段内用户他调用了这些接口,然后我们要一个个的把它们串起来,这个时候我们有日志有指标,但其实说实话它本质上他们是串不起来的,他们是在完全独立的去做一些事情。
当我们收到一个指标的告知,我们可以去点开任何一条链路,发现有问题的一个链路,然后确实ID能够去注入到这样一个日志里面去,这个时候我们就能够去把确实把tracing ID,然后将max跟log连给关联起来,这个时候其实我们就能够以一个比较快速的方式去定位我们的问题,就能够以一个远远高于以前的一种问题定位的效率去解决我们的日常的问题。
衡量应⽤系统当前的状态,信息量少,可通过添加维度来添加额外信息,相同维度之间的指标可聚合(累加、平均),通过指标告警可以快速发现异常。
⼀个请求从接收到处理完毕整个⽣命周期跟踪路径,相⽐指标多了请求相关的信息,通过排查链路可以快速定位问题。
应⽤运⾏产⽣的事件或程序执⾏过程中产⽣的⽇志数据,可以详细的解释系统运⾏的过程,通过应⽤的⽇志来排除故障⽇志。
应用层的统一可视化,多维分析告警等等这样的通用的能力,到我们的各个应用的场景,比如说我们的压测,然后从前端的一个视角的监控,从偏后台的一个视角的监控,尽可能的让用户以最小的成本最小的门槛去使用,不管是开源的监控产品,还是说各个云厂商的一个监控产品,因为协议是统一的,使用方式大概是统一的,所以能够在各个云厂商或者是开源项目之间能够很灵活的切换,谁的体验做得好就用谁的。
基础资源的一个监控跟告警,比如说像CPU使用率,像内存使用率这样的一些监控的告警,这些都是可观测平台技术中需要关注的关键点。
从前端的视角,我们的监控的话,最重要的指标要一个手屏渲染时间,不管是在web端还是小程序端还是安卓端,因为之前c端有一个理论,我记得是比如说你的一个响应时间里,你比如说增多一一秒,然后你整个的一个用户的停留的几率的话,其实你会降低50%以上,所以这个指标是非常重要的。
从后台接口的一个可能性分析,也就是刚刚我们提到的我们指标与日志的一个打通,其实再去抽象这个过程指标,确实我们的日志其实是一个宏观到微观的一个过程,也就是我为什么在这里强调是从指标到trace到日志,其实日志是最全的,日志是一个很详细的东西,因为日志太多了,查询起来会很复杂,而指标跟链路是一个从宏观到微观的过程,从指标的告警,到我们的链路的情况,这是一个很自然的过程,然后再去查日志,整体上我们通过这样的方式也能够去提高我们的一个定位问题的效率,而不是我们从很传统的一上来我们有任何问题,我们就直接去看日志。
我们能够去绘制出我们整个服务的一个调用的拓扑图,不管是团队的技术负责人,或者是产品的负责人,其实看到右上角这样的这么凌乱的一个炒股图,就是你不会对你自己的自家的一个产品是有信心的,还是可以通过服务治理的手段,我们去捋清楚上下游的一个关系,然后能够去逐渐的把一些没有关系的微服务去掉,比如说像右上角的图,它这里有个四方形的这样一个拓扑的调用,其实就是一个非常奇怪的情况,我们能够绘制出这样的一个科普图的话,其实也能够让我们很容易的就能够发现我们的工作重点,再通过我们的分析,然后去把这样的一个拓扑图再进行一个微服务的架构治理。
然后下面介绍一下整体架构,整体架构分三分为三层,第一层是我们的输入层,第二层是我们的中台的一个处理的数据处理层,第三层是我们的上层的一个应用层。然后从输入层的话,我们的数据其实分为两块,一块是我们的日志,另一块是指标的数据,指标的数据会通过我们的流处理进行一个聚合,日志的数据我们可以根据情况来看是否需要对它进行处理,比如说计算一些上下游的关系等等。