标签:自己 陷阱 占用 png mode 体系结构 假设 菜单 imp
Envoy为什么能战胜Ngnix——线程模型分析篇导读:随着Service Mesh在最近一年的流行,Envoy 作为其中很关键的组件,也开始被广大技术人员熟悉。作者是Envoy的开发者之一,本文详细说明了Envoy的线程模型,对于理解Envoy如何工作非常有帮助。内容较为深入,建议细细品读。
关于Envoy的基础技术文档目前相当少。为了改善这一点,我正在计划做一系列关于Envoy各个子系统的文章。 这是第一篇文章,请让我知道你的想法以及你希望涵盖的其他主题。最常见的问题之一是对Envoy使用的线程模型进行描述。
本文将介绍Envoy如何将连接映射到线程,以及Envoy内部使用的线程本地存储(TLS)系统,正是因为该系统的存在才可以保证Envoy以高度并行的方式运行并且保证高性能。
线程概述
图1:线程概述
Envoy使用三种不同类型的线程,如图1所示。
连接处理
如上所述,所有工作线程都会在没有任何分片的情况下监听所有侦听器。内核将接收的socket分派给工作线程。 现代内核一般都很擅长干这个; 内核使用诸如IO优先级提升之类的功能来尝试提高线程处理能力而非使用其他线程处理,这些线程也在同一个套接字上侦听,并且对每个连接来说不需要使用自旋锁来处理。
一旦Worker接受了连接, 连接就永远不会离开那个Worker。所有进一步的处理都在Worker线程内完成,其中包括转发。 这就意味着:
非阻塞意味着什么
到目前为止,在讨论主线程和Woker线程如何操作时,已经多次使用术语“非阻塞”。 所有代码都是在假设没有任何阻塞的情况下编写的。 然而,这并不完全正确。 Envoy确实使用了一些进程范围的锁:
线程本地存储
由于Envoy将主线程职责与Worker线程职责分开,因此需要在主线程上完成复杂的处理,然后以高度并发的方式让每个Worker线程处理。 本节将介绍Envoy线程本地存储(TLS)系统。 在下一节中,我将描述如何使用它来处理集群管理。
图2:线程本地存储(TLS)系统
如已经描述的那样,主线程基本上处理Envoy中的所有管理/控制面功能。(控制面在主线程似乎有点多,但在考虑到Worker做的工作时,似乎也是合适的)。 主线程执行某些操作是一种常见模式,然后通过Worker线程获取结果,并且Worker线程不需要在每次访问时获取锁。
Envoy的TLS系统的工作原理如下:
虽然非常简单,但这是一个非常强大的范例,与RCU锁的概念非常相似。(实质上,Worker线程在工作时从不会看到TLS槽中的数据发生任何变化。变化只发生在工作事件之间的静止期)。
Envoy以两种不同的方式使用它:
群集更新线程
在本节中,我将描述TLS如何用于集群管理。
群集管理包括xDS API处理和/或DNS以及运行状况检查。
图3:集群管理器线程
图3显示了以下组件和步骤的总体流程:
1.集群管理器是Envoy的内部组件,用于管理所有已知的上游集群,CDS API,SDS/EDS API,DNS和运行状况检查。 它负责创建上游集群的最终一致视图,其中包括已发现的主机以及运行状况。
2.运行状况检查器执行活动运行状况检查,并将运行状况更改报告给集群管理器。
3.执行CDS/SDS/EDS/DNS以确定群集成员资格。 状态更改将报告回集群管理器。
4.每个工作线程都在不断运行事件循环。
5.当集群管理器确定集群的状态已更改时,它会创建集群状态的只读快照 ,并将其发布到每个Worker线程。
6.在下一个静止期间,工作线程将更新分配的TLS槽中的快照。
7.在需要确定要负载均衡主机的IO事件期间,负载均衡器将在TLS插槽中查询主机信息。 执行此操作不需要获取锁。 (另请注意,TLS还可以在更新时触发事件,以便负载均衡器和其他组件可以重新计算缓存,数据结构等。这超出了本文的范围,但在代码中不同位置使用)。
通过前面描述的过程,Envoy能够在处理请求的时候不需要任何锁(除了之前描述的那些)。 除了TLS代码之外,大多数代码都不设计线程相关操作,可以编写为单线程程序。 除了达到出色的性能之外,这使得大多数代码更容易编写。
其他使用TLS的子系统
TLS和RCU在Envoy内广泛使用。 其他一些例子包括:
还有其他例子,但前面的例子应该已经说明了TLS在Envoy内部如何广泛使用。
已知的性能陷阱
虽然Envoy整体表现相当不错,但是当它以非常高的并发性和吞吐量使用时,还是有一些需要注意的地方:
结论
Envoy的线程模型旨在支持简单编程范式和大规模并行,但如果调整不当可能会浪费内存和连接。该模型允许Envoy在非常高的Worker数量和吞吐量下有良好表现。
正如我在Twitter上提到的那样,该设计也适合在DPDK之类的用户空间网络堆栈上运行,这可能让商用服务器可以达到每秒钟几百万请求处理速度。 看看未来几年能做到什么样也是非常有趣的。
最后一点:我多次被问到为什么我们为Envoy选择C++。 原因是它仍然是唯一广泛部署的生产级语言,在该语言中可以构建本文所述的体系结构。 C++当然不适合所有项目,甚至许多项目,但对于某些用例,它仍然是完成工作的唯一工具。
代码链接
本文中讨论的一些接口和头文件的链接:
https://github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
https://github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
https://github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
https://github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h
英文原文:
https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310
更多 Envoy 介绍:
https://www.envoyproxy.io/
相关阅读:
阿里云故障,仅是运维操作失误?
微博开源的Motan RPC最新进展:新增跨语言及服务治理支持
Java 微服务框架新选择:Spring 5
从单体应用走向微服务:一次API Gateway升级的启示
他们将生产环境从nginx迁移到envoy,原因竟然是……
本文作者mattklein,由方圆翻译,转载本文请注明出处,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。
标签:自己 陷阱 占用 png mode 体系结构 假设 菜单 imp
原文地址:https://blog.51cto.com/14977574/2546798