Envoy on Windows GA 了！

内容简介：作者：Sotiris Nanopoulos Envoy 项目一直努力使网络对所有运行的应用程序“透明”，而不管编程语言、平台架构和操作系统。今天，我们很兴奋地宣布 Envoy 现在可以在 Windows 平台上使用了！从版本 1.18.3 开始，...

作者：Sotiris Nanopoulos

Envoy 项目一直努力使网络对所有运行的应用程序“透明”，而不管编程语言、平台架构和操作系统。今天，我们很兴奋地宣布 Envoy 现在可以在 Windows 平台上使用了！从版本 1.18.3 开始，你可以在 Windows 上使用 Envoy 用于生产工作负载。

自 2016 年以来，在 Windows 上移植 Envoy 一直是社区的目标。从那以后，Envoy-Windows-Development 小组取得了很大的进展。该团队主要由来自 VMware 和微软的开发者组成，在过去的一年中，该团队合作使 Envoy 从 2020 年 10 月的 alpha 版本到今天的稳定生产就绪状态。

你现在可以在 Windows 上使用 Envoy 来构建原生云应用程序，改善遗留应用程序的可观察性，甚至可以将 Envoy 部署为边缘代理与 Windows 应用程序一起。

在我们深入研究我们为改善 Windows 体验而构建的面向公众的特性之前，我们要感谢 Envoy 开发者社区和维护者们的指导、支持和耐心。

新增特性

自从 Envoy Windows Alpha 版本发布以来，我们增加了更多的功能，支持持续集成，并提高了 Envoy 在 Windows 上的性能和可靠性。

使用合成边缘事件改进轮询机制

Envoy 在 Linux 解决了C10K[1]问题，方法是为每个线程提供多个客户端服务，并使用非阻塞 I/O 和边缘触发就绪更改通知（edge-triggered readiness change notification）。然而，Windows Server 2019 并不支持边缘触发就绪更改通知，这导致 Envoy 在 Windows 上空转和消耗 CPU 资源。

为了解决这个问题，我们设计了类似于边缘事件的合成边缘事件。合成边缘事件是由 Envoy 管理的级别事件，其行为与边缘事件类似。我们通过在新事件到达时手动禁用事件注册，并仅在需要时再次启用它们来实现这一点。

我们在综合测试中观察到，通过切换到合成边缘事件，Envoy 截获的事件减少了 3 个数量级。这是一个显著的改进，允许 Windows 上的 Envoy 扩展到多个并发连接。我们计划进一步完善事件机制。新版本的 Windows 提供了一个原生边缘事件 API，我们计划将其集成到 Envoy 中。

Windows 容器镜像

我们希望操作人员和开发人员能够以最小的摩擦在 Windows 上开始使用 Envoy。自 2020 年 10 月下旬以来，我们一直在docker hub[2]上发布开发者镜像。这些镜像包含各种 SDK 和工具，对于希望扩展或试验 Envoy 的开发人员特别有用。在版本 1.18 中，我们还发布了更精简的镜像，envoy-windows[3]，这更适合于生产环境。

改进的诊断

我们希望操作人员能够在相同配置的不同平台上运行 Envoy。新的流访问日志记录器[4]允许操作人员将侦听器和管理门户产生的访问日志重定向到流程的标准输出。Envoy 使用正确的本地 API 写入标准输出/错误，这取决于它运行的平台。

添加对 Clang 编译器的支持

Envoy 用户利用 Envoy 的通用扩展模型为他们的用例构建自定义过滤器和特性。通用扩展模型的一部分是对 Linux 上不同架构（arm）和编译器 工具 链（Clang 和 GCC）的支持。遵循社区的精神，我们在 Windows 上增加了对 Clang 的支持。自 1 月份以来，CI 在每个提交上都构建了 envoy.exe，通过包括 MSVC 和 Clang 编译器。

改进流程管理

Alpha 版本关注的是功能而不是可用性。从那时起，我们为开发者和 Windows 原生操作人员添加了一些功能，以便轻松管理 Envoy 进程的生命周期。现在，当 Ctrl + C 和 Ctrl + Break 事件发送到控制台时，Envoy 优雅地结束了，跟它处理 SIGINT 和 SIGTERM 的方式是一样的。此外，我们还增加了对 Envoy 作为Windows 服务[5]运行的实验性支持。

贡献的统计数据

虽然这些统计数字本身并不能说明很多问题，但我们想回过头来看看我们在过去一年中所取得的成就：

1. Windows 开发小组已经为 Envoy 仓库贡献了 189 个补丁。

2. 435 个 Envoy 的测试中有 416 个在每次提交时都在 Windows 上运行。由于缺乏平台对特定功能的支持，16 个测试没有在 Windows 上编译，其余 3 个测试在新添加的 QUIC 支持中失败。

3. 我们支持两个编译器（MSVC 和 Clang），三个运行时（win32 原生、SCM 和容器），以及多个版本的 Windows 操作系统（客户端和服务器版本 1809 及以上）。

Envoy Windows 的下一步是？

我们还有很多工作要做，让 Windows 上的 Envoy 与 Linux 平起平坐。我们期待：

1. 添加更多演示不同用例的示例沙箱。

2. 改进二进制文件的发布。

3. 测试和改进性能。

4. 在即将发布的Windows Server 2022[6]版本中集成服务网格解决方案，如OSM[7]。

我如何提供反馈并参与其中？

我们期待你的反馈和意见。有多种方法可以接触到我们，所有的方法都是同等有效的，所以你可以选择一个你喜欢的。

你可以在Envoy slack 工作空间[8]#envoy-windows-dev 频道中与致力于 Envoy on Windows 的贡献者联系，提出问题或提供反馈。此外，我们跟踪和分类所有Github 问题[9]。我们也会关注envoy-dev[10]和envoy-announce[11]谷歌群，并回答问题。我们还在文档网站上维护一个FAQ[12]。

重要的一点是，如果你遇到了导致 Envoy 崩溃的 bug，请联系 envoy-security@googlegroups.com。你可能无意中发现了一个不应该在我们修补它之前公开的安全漏洞。

像每个 CNCF 项目一样，我们每两周举办一次会议，你可以在Envoy CNCF 日历[13]上找到。这些会议是一个开始参与 Envoy on Windows 路线图并为之做出贡献的好地方。

Envoy Windows 开发小组，

Sunjay Bhatia、Bill Rowe（VMware）

Praveen Balasubramanian、Nick Grifka、Randy Miller、Sotiris Nanopoulos、David Schott（微软）

参考资料

[1] C10K: http://www.kegel.com/c10k.html

[2] docker hub: https://hub.docker.com/r/envoyproxy/envoy-windows-dev

[3] envoy-windows: https://hub.docker.com/r/envoyproxy/envoy-windows

[4] 新的流访问日志记录器: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/stream/v3/stream.proto#standard-streams-access-loggers

[5] Windows 服务: https://www.envoyproxy.io/docs/envoy/latest/start/quick-start/run-envoy#run-envoy-with-the-demo-configuration

[6] Windows Server 2022: https://cloudblogs.microsoft.com/windowsserver/2021/03/02/announcing-windows-server-2022-now-in-preview/

[7] OSM: https://openservicemesh.io/

[8] Envoy slack 工作空间: https://envoyslack.cncf.io/

[9] Github 问题: https://github.com/envoyproxy/envoy/issues

[10] envoy-dev: https://groups.google.com/g/envoy-dev

[11] envoy-announce: https://groups.google.com/g/envoy-announce

[12] FAQ: https://www.envoyproxy.io/docs/envoy/latest/faq/overview#windows

[13] Envoy CNCF 日历: https://goo.gl/PkDijT

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• Envoy on Windows GA 了！

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。