idou老师教你学Istio 29:Envoy启动流程

  • 功能概述
  • Envoy启动时,会启动一个进程,并在这个进程中启动很多线程,这样,可以启动很多worker线程,一般worker线程数与核心数相同,每个worker线程处理所有已配置的listener上的请求,管理连接并处理filterchain,非阻塞;同时,在这个进程中会启动一个主线程,它负责启动和停止envoy,也是通过API提供配置管理的线程,同时它收集不同的指标,管理其它线程,也是非阻塞的。

    1. 重要数据结构定义

    2.1 Filter

    过滤器,包括listener filter、network filter和http filter。Listener filter可以用于操作连接元数据,在新接收的套接字上进行操作,例如获取原始目的地址,重定向连接等;network filter主要负责数据读写;http filter主要负责数据处理。

    2.2 Listener

    监听器,envoy中支持在每个线程中配置任意数量的监听器,每个监听器独立配置一定数量的network filter,也可以选择性的配置listener filter,listener filter在连接建立之前处理,network filter在连接建立之后处理。

    2.3 Worker

    一个worker对应一个envoy的执行线程,将listener绑定在worker上,worker负责监听、过滤和转发,每个连接的生命周期会绑定在一个单独的worker上,通常情况下,envoy实现了100%的非阻塞。

    1. 代码流程

    3.1 流程概述

    Envoy启动时,首先启动主线程,在主线程中对listener和filter进行初始化操作,然后将listener绑定到worker上,并由主线程拉起worker线程,由worker线程负责监听新连接。


    3.2 初始化

    3.2.1 main入口


    main函数是envoy启动的总入口,首先生成main_common,用于后面的初始化。

    3.2.2 初始化main_common



    在main_common里面会生成maincommonbase,它会做server instance的初始化,一个instance是一个服务的实例.

    3.2.3 Instance初始化


    在maincommonbase里调用InstanceImpl函数后,首先对启动携带的配置信息进行注册,然后执行instance的初始化。


    Instance的初始化包括两部分:

    ① 将当前instance注册到ListenerManager,来管理更新;

    ② 创建并初始化MainImpl,MainImpl用来初始化监听listener;


    MainImpl根据配置文件获取静态监听listener列表,将它们实例化并注册到ListenerManager。

    3.2.4 初始化listener

    tener,根据配置文件为它创建ListenerFilterFactoryList,并根据配置为它添加ListenerFilterFactory。

    listener filter有三个:original dst filter,proxy protocol filter, TLS inspector filter,一一按照配置判断是否加入ListenerFilterFactoryList。



    配置ListenerFilterFactoryList的同时,也会根据配置为这个listener创建NetworkerFilterFactoryList,供后续建立在这个listener上的连接使用。

    3.3 启动

    3.3.1 启动入口


    在main_common初始化正常完成后,执行main_common→run()启动,从而后续执行instance的run()方法,在instance的run()方法,会执行网络级别上的listener初始化。


    3.3.2 启动worker,将listener绑定到worker上



    此处,会将从配置文件读取的所有listener绑定到所有的worker上,worker是服务的并发线程,数目一般和核心数相同,将listener绑定到worker上后会通过connectionhandler模块将其初始化。



    3.3.3 Listener初始化

    Listener的初始化过程首先生成ActiveListener,通过ActiveListener调用network包内的创建函数来对listener进行网络级别的初始化。



    3.3.5 启动worker线程,进入监听

    Listener绑定在worker上,当listener初始化完成后,需要启动worker服务才能真正进入监听流程。





    此处,为每个worker启动新线程,并调用libevent的event_base_loop进入监听,等待连接事件到达触发后,回调onAccept进入处理流程。

    1. 总结

    本文从程序入口main函数开始,分析了envoy如何启动,以及如何对listener、worker这些核心数据结构进行初始化,并详细阐述了从envoy主线程启动到worker线程进入监听行为的全过程。

    相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

    原文地址:https://blog.51cto.com/14051317/2355620

    时间: 2024-08-30 16:11:36

    idou老师教你学Istio 29:Envoy启动流程的相关文章

    idou老师教你学Istio 07: 如何用istio实现请求超时管理

    前言 在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理.看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了,当然还存在部分被idou老师的文采刚吸引过来的新同学. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地

    idou老师教你学istio:监控能力介绍

    经过了一年多的开发和测试,Istio于北京时间7月31日发布了1.0版本,并且宣布1.0版本已经可以成熟的应用于生产环境.对于istio的各项主要功能,之前的文章已经介绍的非常详细,并且还会有更多的文章来分析原理和实践功能.今天我们主要介绍的服务是istio流量监控能力.我们知道每个pod内都会有一个Envoy容器,其具备对流入和流出pod的流量进行管理,认证,控制的能力.Mixer则主要负责访问控制和遥测信息收集.如拓扑图所示,当某个服务被请求时,首先会请求istio-policy服务,来判定

    idou老师教你学Istio 04:Istio性能及扩展性介绍

    Istio的性能问题一直是国内外相关厂商关注的重点,Istio对于数据面应用请求时延的影响更是备受关注,而以现在Istio官方与相关厂商的性能测试结果来看,四位数的qps显然远远不能满足应用于生产的要求.从发布以来,Istio官方也在不断的对其性能进行优化增强.同时,Istio控制面的可靠性是Istio用于生产的另一项重要考量标准,自动伸缩扩容,自然是可靠性保证的重要手段.下面我们先从性能测试的角度入手,了解下Istio官方提供的性能测试方法与基准,主要分为以下四个方面展开. 一.函数级别测试

    idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?

    本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式.并基于Istio中埋点的原理解释来说明:为了输出一个质量良好的调用链,业务程序需根据自身特点做适当的修改,即并非官方一直在说的完全无侵入的做各种治理.另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式. Istio一直强调其无侵入的服务治理,服务运行可观察性.即用户完全无需修改代码,就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集.原文是这样描述的: Istio

    idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

    摘要使用 Istio 可以很方便地实现微服务间的访问控制.本文演示了使用 Denier 适配器实现拒绝访问,和 Listchecker 适配器实现黑白名单两种方法. 使用场景 有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务. 访问控制属于策略范畴,在 Istio 中由 Mixer 组件实现. Mixer拓扑图,来源官方文档 如上图所示,服务的外部请求会被 Envoy 拦截,每个经过 Envoy 的请求都会调用 Mixer,为 Mixer

    idou老师教你学Istio 20 : Istio全景监控与拓扑

    根据Istio官方报告,Observe(可观察性)为其重要特性.Istio提供非侵入式的自动监控,记录应用内所有的服务. 我们知道在Istio的架构中,Mixer是管理和收集遥测信息的组件.每一次当请求到达的时候,Envoy会调用Mixer进行预检查,在请求处理完毕后也会将过程上报给Mixer. 今天我们会结合开源监控插件(Jaeger)与嵌入Istio服务的应用性能管理服务来为大家展示部分Istio的全景监控能力. 1Jaeger Istio结合Jaeger使用可以解决端到端的分布式追踪问题.

    idou老师教你学Istio 25:如何用istio实现监控和日志采集

    大家都知道istio可以帮助我们实现灰度发布.流量监控.流量治理等功能.每一个功能都帮助我们在不同场景中实现不同的业务.那Istio是如何帮助我们实现监控和日志采集的呢? 这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序.首先在集群中安装并部署Istio. 1 收集遥测数据 创建一个新的YAML文件,用来保存Istio将自动生成和收集的新度量标准和日志流的配置.如下图所示: 通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件

    idou老师教你学Istio 27:解读Mixer Report流程

    1.概述 Mixer是Istio的核心组件,提供了遥测数据收集的功能,能够实时采集服务的请求状态等信息,以达到监控服务状态目的. 1.1 核心功能 ?前置检查(Check):某服务接收并响应外部请求前,先通过Envoy向Mixer(Policy组件)发送Check请求,做一些access检查,同时确认adaptor所需cache字段,供之后Report接口使用: ?配额管理(Quota):通过配额管理机制,处理多请求时发生的资源竞争: ?遥测数据上报(Report):该服务请求处理结束后,将请求

    idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

    Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用. readiness探针用来使容器准备好接收流量.当所有容器都ready时被视为pod此时ready.比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除. 使用场景: liveness