服务网格数据平面的关键:层层剖析Envoy配置
Envoy是一种高性能C++分布式代理,专为单个服务和应用程序设计。作为Service Mesh中的重要组件,充分理解其配置就显得尤为重要。本文列出了使用Envoy而不用其他代理的原因。并给出了Envoy及其服务的配置,然后对其进行详细解读,帮助读者理解其配置,从而掌握Envoy。
服务网格是微服务设置中的通信层,也就是说往返于每个服务的所有请求都通过网格。服务网格在微服务设置中也成为基础架构层,它能够让服务之间的通信变得安全可靠。关于Service Mesh的基础内容,我们已经在这篇文章中详细介绍过。
每一个服务都有自己的代理服务(sidecars),然后所有代理服务一起形成服务网格。Sidecars处理服务之间的通信,也就是说所有的流量都会通过网格并且该透明层可以控制服务之间如何交互。
服务网格通过由API控制的组件提供可观察性、服务发现以及负载均衡等。
实际上,如果一个服务要调用另一个服务,它不会直接调用目标服务。而是先将请求路由到本地代理,然后代理再将该请求路由到目标服务。这一过程意味着服务实例不会和其他服务直接接触,仅与本地代理进行通信。
根据ThoughtWorks Technology Radar(这是一份半年度的文档,用于评估现有技术和新生技术的风险和收益)指出,“服务网格提供一致的发现、安全性、跟踪(tracing)、监控以及故障处理,而无需共享资源(如API网关或ESB)。一个十分典型的用例是轻量的反向代理进程会与每个服务进程或单独的容器一起部署。”
当谈到服务网格时,不可避免谈到的是“sidecar”——可用于每个服务实例的代理。每个sidecar负责管理一个服务的一个实例。我们将在本文中进一步详细讨论sidecar。
服务网格可以交付什么?
当前,越来越多的企业和组织开始转向微服务架构。这样的企业需要服务网格所提供的上述功能。解耦库的使用或自定义代码的方法无疑是赢家。
为什么使用Envoy?
Envoy不是构建一个服务网格的唯一选择,市面上还有其他的代理如Nginx、Traefik等。我之所以选择Envoy,这个用C++编写的高性能代理,是因为我更喜欢Envoy的轻量、强大的路由,及其提供的可观察性和可扩展性。
让我们首先构建1个包含3个服务的服务网格设置,这是我们正在尝试构建的架构:
Front Envoy
在我们的设置中Front Envoy是一个边缘代理,我们通常在其中执行TLS终止、身份验证、生成请求头等操作。
我们来看看Front Envoy配置:
--- admin: access_log_path: "/tmp/admin_access.log" address: socket_address: address: "127.0.0.1" port_value: 9901 static_resources: listeners: - name: "http_listener" address: socket_address: address: "0.0.0.0" port_value: 80 filter_chains: filters: - name: "envoy.http_connection_manager" config: stat_prefix: "ingress" route_config: name: "local_route" virtual_hosts: - name: "http-route" domains: - "*" routes: - match: prefix: "/" route: cluster: "service_a" http_filters: - name: "envoy.router" clusters: - name: "service_a" connect_timeout: "0.25s" type: "strict_dns" lb_policy: "ROUND_ROBIN" hosts: