转载

专访Matt Klein关于在Lyft构建Envoy的问答

由Microservices.com主办的从业者峰会是一个由从业者驱动的微服务会议，该会议聚焦于现实世界应用中采用微服务的实际问题。该峰会2017年1月31日在美国旧金山召开，演讲嘉宾包括来自Uber、New Relic、Lyft、PayPal，以及Google的微服务从业者。

Matt Klein是一名来自于Lyft公司的资深软件工程师，他也是本次峰会的发言嘉宾之一。Klein在Lyft负责Envoy，这是一个七层通信总线，贯穿于整个Lyft的面向服务体系架构。

峰会举办之前InfoQ和Klein讨论了针对Lyft通信需求构建定制工具的受益点，同时也讨论了这个工具可以如何帮助其他微服务体系架构。

InfoQ：现代面向服务体系架构高度依赖网络通信和RPC调用，而不是在一个整体内处理。Envoy如何改进对于复杂网络基础架构的依赖？

Matt Klein：过去5->10年我们看到了SoA的几个重大进步。首先，有很多伙伴正在构建SoA，并且这个过程放在了基础架构生命周期的早期进行。更重要的是，我们看到很多公司同时使用多种语言进行部署（通常同时使用超过3种语言）。

过去，许多成熟SoA通信网络的复杂性已经通过非常复杂的网络通信库解决。解决方案包括负载均衡、路由、服务发现、重试、限速、断路、统计、日志、跟踪等等。除非一个组织使用很少的语言或者拥有很多的资源，否则慢慢地不太可能针对每一种生产环境的语言实现一个成熟的网络通信库。

Envoy是一个进程外的高性能代理，它一次性解决了通用SoA的网络通信问题。Envoy的设计目的是与应用程序（任务语言）一起运行，并且从应用程序开发人员手中抽象出许多复杂的网络通信业务。应用程序开发人员专注于业务逻辑，并且仅仅需要和本地Envoy交互，本地Envoy接着会去处理服务发现、负载均衡、路由等等。可能Envoy最重要的存在感是提供了针对SoA每一个步骤的一致性观察，从调试的角度来看这个特性非常重要。

InfoQ：在Lyft，微服务开发人员需要了解多少网络通信协议栈？Envoy是否有助于减少这种知识积累成本开销？

Matt Klein：非常少！随着完整的Envoy部署在Lyft，我们已经创造了一个世界，开发人员和一个极端的瘦客户端沟通，我们称这个瘦客户端为EnvoyClient。无论代码运行在开发环境、调试环境或是生产环境，开发人员实例化一个EnvoyClient并使用它和远程服务通信。在底层，所有的库都被设置了一些标签并与本地Envoy通信，而本地Envoy执行了所有工作。我们鼓励开发人员设置适当的重试机制、超时，等等。通过这个库，我们差不多可以完成这些功能。开发人员仅仅是启动一次调用并收到回复，其他东西就不需要多担心了。

因为Envoy可以运行在任何地方，我们也可以生产出大量的一致性数据，以此帮助开发人员调试（统计、日志、跟踪、可视化，等等）。

InfoQ：在Envoy就位以前，哪些组件参与了L7路由？为什么这些组件不够高效，创建一个自定义解决方案过程中我们做了哪些努力？

Matt Klein：就像很多现代公司一样，Lyft是一个多语言公司。当前我们在生产环境中运行了PHP、Python和Go服务。在Envoy出现之前，我们采用了混杂不同解决方案的方式，包括每种语言的不同的库、不同的统计方式，等等。我们严重依赖于Aws的Elb产品，伴随着它们所有的内部问题（不稳定、较差的可观察性，等等）。总之，我们完全处于混乱状态。开发人员不信任网络通信，无法调试复杂的问题，并且对于在关键路径上创新高性能网络通信服务存在抵触。

很显然我们需要一个共同的基础功能，我们之前的许多经验和观察指引着我们构建Envoy。