什么是会话保持 我们可以从这篇文章了解到 从上面的文章中截取一些要点: The difference between persistence and affinity Affinity: this is when we use an information from a layer below the application layer to maintain a client request to a single server Persistence: this is when we use Application layer information to stick a client to a single server sticky session: a sticky session is a session maintained by persistence 也就是说 affinity 是一种利用应用层以下的将请求映射到一个 server 的方式。而 persistence 是利用应用层的信息让来自一个 client 的请求都"粘"在一个 server 上。Affinity 不保证会话一定能保持，而 persistence 可以。 Read more

Concepts TransportSocket TransportSocket 是 Envoy 中为 socket 定义的通用接口，其底层实现可以拓展, tls TransportSocket 插件就是利用这一机制在连接建立时处理 tls 相关逻辑。 Configuration Envoy 可以作为 server 接收下游连接，同时作为 client 发起上游连接。所以 tls TransportSocket 配置也分为 Server 和 Client 配置。 Envoy 提供了 double-proxy 的例子 https://github.com/envoyproxy/envoy/tree/v1.18.3/examples/double-proxy 该例子中部署了一个 app + envoy 和一个 db + envoy, 网络拓扑是 [ app --http--> proxy ] --https--> [ proxy --http--> db ] 下游 上游 下面是截取上游的 proxy 的 Listener 配置: listeners: - name: postgres_listener address: socket_address: address: 0.0.0.0 port_value: 5432 listener_filters: - name: "envoy. Read more

Intro 在将内部 Envoy 工程适配上游 1.17 的过程中，我发现原来使用 HeaderMap 的地方都换成了 RequestHeaderMap, ResponseHeaderMap。HeaderMap 仍存在，成为了后者的 base class。Envoy 对标准或者常用的 header 做了优化，定义了一个 inline header 集合，对这些 header 的操作是 O(1) 开销，内存开销也更少。在 1.17 中，优化更进一步，RequestHeaderMap 和 ResponseHeaderMap 维护独立的 inline header 数据结构。 HeaderMap 的主要实现仍然在HeaderMapImpl上，RequestHeaderMap 和 ResponseHeaderMap 只负责声明各自的 inline headers。 class HeaderMapImpl { public: // ... virtual HeaderEntryImpl** inlineHeaders() PURE; } class class RequestHeaderMapImpl final: public TypedHeaderMapImpl<RequestHeaderMap>, public InlineStorage { public: // ... protected: HeaderEntryImpl** inlineHeaders() override { return inline_headers_; } private: HeaderEntryImpl* inline_headers_[]; } HeaderMapImpl 通过虚函数 inlineHeaders 在运行时获取到实际的 inline headers。 Read more

Introduction Envoy 热重启功能的目的是为了减少 Envoy 重启/升级所需的 downtime。当一个新的 Envoy 进程启动时如果有在运行的 Envoy 进程，新的 Envoy 就会执行热重启逻辑。 热重启的实现主要依赖 SHM(Linux Shared Memory), UDS(Unix Domain Socket) 和 Protobuf。SHM 存储了热重启的基本状态，和用于进程间同步的锁。Envoy 启动后会首先检测 SHM 中的状态，如果存在错误则立即退出。UDS 用于 child 和 server 之间的通信，消息以 Protobuf 格式序列化，消息类型包括从 parent 获取 listen sockets, 从 parent 获取 stats。 Envoy 热重启会保证 listen sockets 和 stats 在进程间无中断转移，而 parent 上已经建立的连接是会断开的。如果 7 层协议具有优雅断开机制，则流量无损。如果像是 tcp_proxy 这样的连接则是可能有损流量的。 SHM struct SharedMemory 是 SHM 对应的数据结构，size_ 是结构体大小, version_ 为热重启协议版本，只有版本相等进程之间才能进行热重启。log_lock 和 access_log_lock 用于控制进程间日志操作的同步，这里可以先忽略。flags_ 存储状态标志，目前只有 SHMEM_FLAGS_INITIALIZING，表示 Envoy 是否处于初始化阶段。 // Increment this whenever there is a shared memory / RPC change that will prevent a hot restart // from working. Read more