原文链接:http://blog.csdn.net/zvayivqt0ufji/article/details/78351355
女主宣言
本文出自于ADDOPS团队,该文章的译者霍明明参与了360 HULK云平台容器化及虚拟化平台相关服务建设,对微服务有着独到的见解。今天的主角Istio是Google/IBM/Lyft联合开发的开源项目,估计很多同学在此之前可能完全没有听过这个名字,请不必介意,因为Istio出世也才五个月而已。让我们跟着作者一起揭开Service Mesh的神秘面纱。
PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!
前言
有人将 Service Mesh 看成是一次 "Network Application Revolution",我还是非常认同的,所以也就有了进一步了解和学习Service Mesh的动力。
在看本文章前,强烈建议先看一下这两篇文章《深度剖析Service Mesh服务网格新生代Istio》,《从分布式到微服务,深挖Service Mesh》,了解一下Service Mesh的历史。
1
Envoy 简介
在 Service Mesh 模式中,每个服务都配备了一个代理“sidecar”,用于服务之间的通信。这些代理通常与应用程序代码一起部署,并且它不会被应用程序所感知。Service Mesh 将这些代理组织起来形成了一个轻量级网络代理矩阵,也就是服务网格。这些代理不再是孤立的组件,它们本身是一个有价值的网络。其部署模式如图所示:
![640?wx_fmt=png&wxfrom=5&wx_lazy=1](https://img-blog.csdnimg.cn/img_convert/1de7830e4514e46194aac243cd2d8c8f.png;wxfrom=5&wx_lazy=1)
-
绿色部分代表应用程序
-
蓝色部分则是sidecar
服务网格是用于处理服务到服务通信的“专用基础设施层”。它通过这些代理来管理复杂的服务拓扑,可靠地传递服务之间的请求。 从某种程度上说,这些代理接管了应用程序的网络通信层。
Envoy是 Service Mesh 中一个非常优秀的 sidecar 的开源实现。我们就来看看 Envoy 都是做些什么工作。
2
Envoy 用到的几个术语
-
Host: 通常我们将 Host 看做是一个具备网络通信功能的实体(可以是一台物理机,也可以是一台移动设备等等) 。在 Envoy 中,host 是一个逻辑网络中的应用. 可能运行在由有多个主机组成的底层硬件,只要它们各自独立寻址。
-
Downstream: 请求发起者(服务请求方)。
-
Upstream: 请求接收者(服务提供方)。
-
Listener: 服务(程序)监听者。就是真正干活的。 envoy 会暴露一个或者多个listener监听downstream的请求。
-
Cluster: upstream 集群。Envoy 通过服务发现定位集群成员并获取服务。具体请求到哪个集群成员是由负载均衡策略决定。通过健康检查服务来对集群成员服务状态进行检查。
-
Mesh: 在本文中 "Envoy mesh" 指的是由一组 Envoy 代理组成的,为不同服务之间可靠传递请求的服务网格。
-
Runtime configuration: Envoy 配置是热更新的,无需重启。
-
Filter: 过滤器。在 Envoy 中指的是一些“可插拔”和可组合的逻辑处理层。是 Envoy 核心逻辑处理单元。
3
Envoy 基础概念
线程模型
Envoy 使用单进程多线程模式。一个主线程,多个工作线程。主线程协调和管理这多个线程来工作。每个线程都独立监听服务,并对请求进行过滤和数据的转发等。
一个连接建立后,这个线程将会管理该连接的整个生命周期。通常 Envoy 是非阻塞的,对于大多数情况建议每个 Envoy 配置的工作线程数等于机器的 CPU 线程数。
Listeners
Envoy 中真正干活的(通常是一个监听服务端口的工作线程)。
Envoy 会启动一个或者多个listener,监听来自 downstream 的请求。当 listener 接收到新的请求时,会根据关联的filters模板初始化配置这些 filters,并根据这些 filters 链对这些请求做出处理(例如:限速、TLS 认证、HTTP 连接管理、MongoDB 嗅探、TCP 代理等等)。
Envoy 是多线程模型,支持单个进程配置任意数量的 listeners。通常建议一个机器上运行一个 Envoy 进程,而不关心配置了多少个listerners(如上:大多数情况listener数量等于机器的CPU线程数)。
目前 Envoy 只支持 TCP 类型的 listeners。每个 listener 都可以独立配置一些L3/L4层的 filters。
Listener 还可以通过 listener 发现服务来动态获取。
Network (L3/L4) filters
network (L3/L4) filters 构成了Envoy连接处理的核心。 在 listener 部分我们介绍过, 每个 listener 可以组合使用多个 filters 来处理连接数据。
目前有三种类型的 network (L3/L4) filters:
-
Read: 当 Envoy 接收来自下游服务请求数据时被调用。
-
Write: 当 Envoy 向上游服务发送数据时被调用。
-
Read/Write: 上面两种fileter都是单向控制,Read/Write filters 在接收来自下游服务请求数据和向上游服务发送数据时被调用,是双向控制。
这些 filter 通过分析原始字节流和少量连接事件(例如,TLS握手完成,本地或远程连接断开等)对连接进行处理。
Network Filter(L7)/HTTP Filter
HTTP 协议是当前许多服务构建的基础协议,作为核心组件,Envoy 内置了 HTTP 连接管理 filter。 该 filter 将原始数据字节转换成 HTTP 协议类型数据(比如: headers、body、trailers等)。它还会处理一些通用的问题(比如:request日志、request ID生成和request追踪、请求/响应头控制、路由表管理和状态数据统计等)。
HTTP 连接管理提供了三种类型的filter:
HTTP 协议是当前许多服务构建的基础协议,作为核心组件,Envoy 内置了 HTTP 连接管理 filter。 该 filter 将原始数据字节转换成 HTTP 协议类型数据(比如: headers、body、trailers等)。它还会处理一些通用的问题(比如:request日志、request ID生成和request追踪、请求/响应头控制、路由表管理和状态数据统计等)。
HTTP 连接管理提供了三种类型的filter:
-
Decoder: 解析请求数据流时(headers,body,trailers等)调用,属于入口单方向控制。
-
Encoder: 编码响应数据流时(headers, body, and trailers)调用,属于出口单方向控制.
-
Decoder/Encoder: Decoder/Encoder 用于入/出口双向控制.
HTTP Filters
(https://envoyproxy.github.io/envoy/configuration/http_filters/http_filters.html#config-http-filters)
HTTP protocols
Envoy HTTP 连接管理原生支持HTTP/1.1, WebSockets 和 HTTP/2,暂不支持 SPDY。
Envoy 对 HTTP 的支持在设计之初就是一个HTTP/2的多路复用代理。对于 HTTP/1.1 类型连接,编解码器将 HTTP/1.1 的数据转换为类似于 HTTP/2 或者更高层的抽象处理。这意味着大多数代码不用关心底层连接使用的是 HTTP/1.1 还是 HTTP/2。
access log
HTTP 连接管理支持 access log,可以记录访问日志,且可以灵活的配置。
HTTP 路由
Envoy 包含了一个 HTTP router filter,该 filter 可以用来实现更高级的路由功能。它可以用来处理边缘流量/请求(类似传统的反向代理),同时也可以构建一个服务与服务之间的 Envoy 网格(典型的是通过对HTTP header等的处理实现到特定服务集群的转发)。
每个HTTP连接管理 filter 都会关联一个路由表。每个路由表会包含对 HTTP 头、虚拟主机等的配置信息。
{
"cluster": "...",
"route_config_name": "route_config_example",
"refresh_delay_ms": "3000"
}
route_config_example:
{
"validate_clusters": "example",
"virtual_hosts": [
{
"name": "vh01",
"domains": ["test.foo.cn"],
"routes": [],
"require_ssl": "...",
"virtual_clusters": [],
"rate_limits":
"request_headers_to_add": [
{"key": "header1", "value": "value1"},
{"key": "header2", "value": "value2"}
]
},
],
"internal_only_headers": [],
"response_headers_to_add": [],
"response_headers_to_remove": [],
"request_headers_to_add": [
]
}
路由表有两种配置方式:
-
静态配置文件。
-
通过RDS(Route discovery service) API动态配置。
RDS 是一组API用来动态获取变更后的路由配置。
router filter 支持如下功能:
-
支持 Virtual hosts。映射 domains/authorities 到一系列的路由规则上。[和nginx等一样]。
-
基于前缀和精确path的规则匹配(有的对大小写既敏感,有的不敏感)。 由于 Regex/slug 会使得用程序来判定路由规则是否与其它规则冲突很困难, 所以,目前暂不支持。由于这个原因,我们不建议在反向代理层面使用基于regex/slug的路由, 当然了,未来我们会根据需求添加对它的支持。
-
Virual host 层面的 TLS 重定向。 分两类:
-
all: 所有请求都必须使用TLS。如果请求没有使用TLS,返回302。
-
external_only: 只要求外网请求使用TLS。如果来自外网的请求没有使用TLS。 如果,改参数没有配置,该virtual host将不会对TLS有要求。
-
路由层面对 Path/host 重定向。
-
host重写。 支持两种重写方式:
1. 固定值。host_rewrite参数配置。
2. 动态配置。根据upstream 主机的 DNS 类型动态配置。 具体的值是由cluster manager从upstream中选出来的,其主机名作为重写的值。 这种方式只用在route的目的集群是 strict_dns or logical_dns 类型的场景。其它集群类型不起作用。 将 auto_host_rewrite 设置true即可。这两个参数不能同时使用。
-
前缀重写(prefix)。
-
路由层面对 Websocket upgrades. 配置该规则后,来自 HTTP/1.1 客户端到该路由规则的连接都会被转换成 WebSocket 的连接。 如果配置为 true, Envoy 对于该路由的第一个请求需带 WebSocket upgrade headers。如果没有添加该header,请求江北拒绝。如果设置了, Envoy 将会在client和upstream server之间设置TCP代理 。upstream 负责断开该连接,否则 Envoy 任然会转发数据到该upstream server。
-
请求重试和超时设置 Envoy 有两种方式来设置请求重试。
1. 通过route设置。
2. 通过request header设置。 支持的配置项有: 2.1 最大重试次数: 每次重试之间会使用指数退避算法.另外,所有重试都包含在整体请求超时之内。这避免了由于大量重试而需要较长的请求时间。 2.2 重试条件: 可以根据应用的需求配置触发重试的条件。例如: 网络错误, 5xx 返回码, 幂等的4xx返回码, 等等。
-
运行时对来自上下游数据的嗅探。
-
使用基于 weight/percentage-based 的路由,对来自多个上游的数据进行拆分。
-
任意 HTTP 头匹配路由规则。
-
支持虚拟集群。
-
基于路由的优先级。
-
基于路由的 hash 负载均衡。需要在 header 中设置 hash 使用的策略。
-
对于非 TLS 的转发支持绝对 urls。
其中:重定向、超时、重试对于 websocket upgrades 是不支持的。
Connection pooling
对于 HTTP 类型,Envoy 提供了对连接池的抽象,连接池屏蔽底层协议类型(HTTP/1.1、HTTP/2),向上层提供统一的接口。用户不用关心底层是基于HTTP/1.1的多线程还是基于HTTP/2的多路复用方式实现细节。
TCP proxy
TCP 代理,L3/L4层连接的转发。这应该是 Envoy 最基础的功能。一般是作为 downstream 客户端与 upstream 服务集群之间的连接代理。TCP 代理既可以单独使用,也可以与其它 filter 组合使用,例如( MongoDB filter 或者 限速filter)。
在 TCP 代理层还可以配置 route 策略,比如: 允许哪些IP段和哪些端口进来的请求访问,允许访问哪些IP段和哪些端口的服务。
TCP 代理配置如下:
{
"name": "tcp_proxy",
"config": {
"stat_prefix": "...",
"route_config": "{...}"
}
}
-
stat_prefix: 统计数据前缀,主要是用于区分统计数据。
-
route_config: filter 的路由表。
例如:
{
"name": "tcp_proxy",
"config": {
"stat_prefix": "...",
"route_config": "{
"routes": [
{
"cluster": "...",
"destination_ip_list": [
"192.168.3.0/24",
"50.1.2.3/32",
"10.15.0.0/16",
"2001:abcd::/64"
],
"destination_ports": "1-1024,2048-4096,12345",
"source_ip_list": [
"192.168.3.0/24",
"50.1.2.3/32",
"10.15.0.0/16",
"2001:abcd::/64"
],
"source_ports": "1-1024,2048-4096,12345"
},
]
}"
}
}
简单说,就是上下游服务的访问控制。
TPC 代理支持的一些统计数据:
-
downstream_cx_total 处理的连接总数.
-
downstream_cx_no_route 不匹配route的总数.
-
downstream_cx_tx_bytes_total 发送给下游的总字节数
-
downstream_cx_tx_bytes_buffered Gauge 当前为下游服务缓存的字节数
-
downstream_flow_control_paused_reading_total 被流控暂停从下游服务读取数据的次数
-
downstream_flow_control_resumed_reading_total 被流控控制重新从下游服务读取数据的次数
gRPC 的支持
Envoy 在传输层和应用层两个层给予gRPC的高度支持。
-
Envoy 是当前极少数能同时正确支持HTTP/2 trailers和传输gRPC请求和响应的的HTTP代理。
-
gRPC 运行时对于一些语言而言还是不太成熟。为此,Envoy 支持一个叫 gRPC bridge 的 filter,它允许gRPC请求能够通过HTTP/1.1发送给Envoy。 Envoy 会将该请求转换成HTTP/2传输到目的server。响应会被转换成 HTTP/1.1 返回。
-
当装了bridge filter后, bridge filter 除了收集全局HTTP统计之外,桥接过滤器还收集每个RPC统计信息。
-
gRPC-Web is supported by a filter that allows a gRPC-Web client to send requests to Envoy over HTTP/1.1 and get proxied to a gRPC server. It’s under active development and is expected to be the successor to the gRPC bridge filter.
-
支持 gRPC-web。通过 filter 能够将使用 HTTP/1.1 发送到Envoy 的 gRPC-Web 客户端请求代理到 gRPC server。该 feature 正在开发阶段。
-
JSON 转换器支持基于 JSON 的 RESTFUL 客户端通过 HTTP 发送请求给 Envoy 并代理给 gRPC 服务.
WebSocket 的支持
Envoy 支持HTTP/1.1连接到WebSocket连接的切换(默认是支持的)。
条件:
-
client 需要显示添加 upgrade headers 。
-
HTTP 路由规则中显示的设置了对 websocket的支持(use_websocket)。
因为 Envoy 将 WebSocket connections 作为 TCP connection 来处理,因此,一些HTTP的特性它不支持,例如: 重定向、超时、重试、限速、 shadowing . 但是, prefix 重写, host 重写, traffic shifting and splitting 都是支持的.
Envoy对WebSocket的代理是TCP层,它理解不了WebSocket层的语义,所以对于连接断开应该由upstream的client来主动关闭。
Envoy对WebSocket的支持与nginx对WebSocket的支持是相同的。
关于 Envoy 对 WebSocket 的支持可以参考 nginx 对 WebSocket 的支持。
(http://www.itfanwan.com/xinwen/6385)
4
高级概念
集群管理器(Cluster manager)
Envoy 集群管理器管理所有 upstream 集群节点。
upstream 集群节点都由一些列 L3/L4/L7 层 filter 链组成,它们可用于任意数量的不同代理服务。
集群管理器向 filter 链暴露一组API,这组API允许 filters 获取发往 upstream 集群的L3/L4层的连接或抽象的 HTTP 连接池的数据。在 filter 处理阶段通过对原始字节流的分析确定是一个连接是 L3/L4 层的连接还是一个新的 HTTP 流。
除了基本的连接类型分析外,集群管理器还要处理一些列的复杂工作,例如:知道哪些主机可用和健康,负载均衡,网络连接数据的本地存储,连接类型(TCP/IP, UDS),协议类型(HTTP/1.1,HTTP/2)等。
集群管理器支持两种方式获取它管理的集群节点:
-
通过静态的配置文件
-
通过动态的集群发现API(CDS)。
CDS:Cluster discovery service,是一个可选的API,Envoy用它来动态的获取cluster manager的成员。
集群管理器配置项如下:
{
"clusters": [],
"sds": "{...}",
"local_cluster_name": "...",
"outlier_detection": "{...}",
"cds": "{...}"
}
Service discovery(SDS)
服务发现有几种方式:
-
静态配置。通过配置文件配置(IP/PORT、unix domain socket等)。
-
基于DNS的服务发现。
-
Original destination
-
Service discovery service (SDS)
-
On eventually consistent service discovery
更多服务发现内容
(https://envoyproxy.github.io/envoy/intro/arch_overview/service_discovery.html)
主动健康检查
根据配置的不同, Envoy 支持3种健康检查方式。
-
基于 HTTP
Envoy 向 upstream 节点发送一个 HTTP 请求,返回 200 代表健康, 返回 503 代表该host不再接收请求/流量。
基于 HTTP 的健康检查支持3种策略:
1.1 No pass through
这种模式 Envoy 不会将健康检查的请求转发给本地的服务,而是根据当前节点是否被 draining 返回 200 或者 503.
1.2 Pass through
与第一种模式不同,这种模式 Envoy 会将健康检查的请求转发给本地服务,调用本地服务的健康检查接口,返回 200 或 503.
1.3 Pass through with caching
这种模式是前两种模式的高级版,第一种方案数据不一定准,第二种请求太频繁会对性能有影响。
该模式加了个缓存的支持,在缓存周期内结果直接从缓存中取,缓存失效后再请求一次本地服务加载到缓存中。
这是推荐的一种模式。 健康检查时 Envoy 与 Envoy之间是长连接,他们不会消耗太大性能;对于 upstream 节点而言,则是新请求新连接。
-
基于 HTTP 的健康检查支持身份认证。
如果你在云平台中用了最终一致性的服务发现服务或者容器环境中,赶上服务水平扩展,这个时候其中一个节点挂掉后又"回到平台"且使用的是同一个 IP 是有可能的,但是确是不同的服务(在容器服务中尤为明显)。一种解决方案是,对不同的服务使用不同的健康检查URL,但是这种配置复杂度非常高。Envoy 采用的方案是在 header 中添加一个 service_name 选项来支持。如果设置了该选项,在健康检查时会对比 header 中的 x-envoy-upstream-healthchecked-cluster 是否和该选项值匹配,如果不匹配则会忽略该请求。
-
L3/L4
基于L3/L4层的健康检查, Envoy 向 upstream 节点发送定义好的一个字符串. 如果 upstream 节点返回该值,则代表健康, 否则不健康。
-
Redis
Envoy 向 Redis 发送一个 PING 命令, 返回 PONG 代表健康, 其它的代表不健康。
Passive health checking(钝态检查)
Envoy 通过 Outlier detection 进行钝态(实在是找不出太合适的词)检查
Outlier detection,用来检查某些集群成员在给定范围内是否“正常”,不正常则将其从负载均衡列表中移除。
有时候一个节点虽然在进行主动健康检查是是正常的,但是会存在某些不正常的状态被遗漏的情况,而 Outlier detection 则是弥补这个“漏洞”的 。它通过跟高级的一些算法来判定该节点是否是正常的。
Outlier detection 有两种检查类型:
-
基于连续的 5xx 错误码
upstream 成员连续N次返回5xx错误码, N默认为5(可配置)。
-
基于成功率
基于成功率的检查在两种情况下是不处理的:
-
针对集群中单个节点
单个节点的请求数量在聚合区间内少于outlier_detection.success_rate_request_volume值时(默认100)。
-
集群级别
集群中 outlier_detection.success_rate_minimum_hosts 个节点在检查周期内请求量都小于 outlier_detection.success_rate_request_volume 时。
配置项:
{
"consecutive_5xx": "...",
"interval_ms": "...",
"base_ejection_time_ms": "...",
"max_ejection_percent": "...",
"enforcing_consecutive_5xx" : "...",
"enforcing_success_rate" : "...",
"success_rate_minimum_hosts" : "...",
"success_rate_request_volume" : "...",
"success_rate_stdev_factor" : "..."
}
“
主动健康检查和钝态检查可以配合使用,也可以单独使用。
Circuit breaking(断路器)
断路器是一种分布式的限速机制,它针对每个upstream的host设置,有时候也需要针对整个cluster进行限制, 这个时候全局的限速就非常有必要了。Envoy支持全局限速(L3/L4、HTTP 都支持),它有一个集中的限速服务, 对于到达该集群的每个连接,都会从限速服务那里查询全局限速进行判断。 Envoy 是通过一个全局的gRPC限速服务来实现全局限速。通过redis来做后端存储。
Envoy 的断路器可以控制 envoy 与 downstream 节点的最大连接数、集群最大支持的 pending 请求数、集群最大支持的请求数(适用HTTP/2)、集群存活最大探测次数。
断路器配置:
{
"max_connections": "...",
"max_pending_requests": "...", # 默认 1024
"max_requests": "...", # 默认 1024
"max_retries": "...", 默认 3
}
-
max_connections:Envoy 与 upstream 集群所有节点能够建立的最大连接数量。该参数适用于HTTP/1.1,因为HTTP/2是使用单个连接与每个host建连,连接复用(默认1024)。
-
max_pending_requests: 等待线程池有可用连接时的最大排队请求数量。该参数适用于HTTP/1.1,HTTP/2采用多路复用方式,无需排队请求(默认 1024)。
-
max_requests: 给定时间内最大请求数,该参数适用于HTTP/2,HTTP/1.1 通过max_connections来限制。(默认 1024)。
-
max_retries: 给定时间内Envoy与请求upstream集群时的最大重试次数,该值不宜设置过大,重试过多可能会带来更多其它的级联故障,甚至导致雪崩。(默认 3)。
热更新
简化操作是Envoy一个非常重要的设计目标。除了强大的统计和本地管理接口, Envoy还具备自身热重启的功能。 这意味着 Envoy 能够全自动的更新自己(包括代码和配置的变更),而不会丢失任何连接。
看下热更新的过程:
-
统计数据和一些lock都放到了共享内存中。进程在重启时这些数据是持久的,不会丢失。
-
新旧进程通过RPC协议进行通信。
-
新的进程在接管旧进程的unix domain socket前,先完成一系列的初始化(比如:加载配置, 初始化服务发现和健康检查, 其它)。然后,新的进程开始监听服务,并告诉老的Envoy进程进入驱逐阶段。
-
在旧进程驱逐阶段, 旧的进程尝试平滑的关闭已存在的连接。具体如何做要依赖于配置的filters。 --drain-time-s 配置项用来配置等待平滑退出的时间。如果平滑退出花费的时间超过了这个值,进程会强制关闭和回收。
-
驱逐过程结束后, 新的Envoy进程告诉旧的Envoy进程关闭自己。参数 --parent-shutdown-time-s 用来配置关闭自己的超时时间。
-
Envoy 的热重启的设计支持新老进程同时存在时也能正常工作。新旧进程之间的通信只能是通过unix domain socket。
5
Envoy 部署方式
这一块是大家关注的重点,也就是应用程序如何与 Envoy 结合来使用的、请求是如何转到 Envoy 的等等。
根据不同的使用场景,Envoy有不同的部署方式。
Service to service only
这是最简单的部署和使用方式,在这种方式中 Envoy 作为内部与外部服务通信的总线。Envoy 启动多个 listeners 用于本地流量转发和服务与服务之间的流量转发。
![0?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/fe58fecdca80034026802c9903b083f0.png)
上图展示了最简单的 Envoy 部署方式。在这种部署方式中 Envoy 承担的是SOA服务内部流量的消息总线角色。在这种场景中, Envoy 会暴露一些 listeners 用于本地流量或者本地服务与远端服务之间流量的转发。
listener 类型:
-
Service to service egress listener
本地服务到远端服务的出口 listener。该类型 listener 会监听在某个指定的端口上,所有内部应用出去的请求都重定向到该端口上,由该 listener 处理并转发到目的服务集群节点。
例如:http://localhost:9001 或 tcp://localhost:9001。 HTTP 和 gRPC 类型请求使用 host header,HTTP/2使用 authority header 来指定访问的远端服务集群。 在数据流经 Envoy 过程中会进行服务发现、负载均衡、限速等处理。
本地 Services 只需要知道本地的Envoy,无需关心它们自己所处的网络拓扑及环境。
-
Service to service ingress listener
本地服务到远端服务的入口 listener。该 listener 提供远端 Envoy 调用本地 Envoy 的端口。
例如:http://localhost:9211。 进入本地 Envoy 的请求都被路由/重定向到本地 service 的监听端口。根据需要,本地的Envoy 会进行一些缓存、断路检查等处理。
-
Optional external service egress listeners
有时,需要访问外部的服务,此时需要提供一个端口提供访问。因为,有些外部服务SDK不支持host header的重写来支持标准的HTTP反向代理行为。
例如:http://localhost:9250 might be allocated for connections destined for DynamoDB.我们建议为所有外部服务使用本地端口路由,而不是使用主机路由和专用本地端口路由
-
Discovery service integration
集成外部服务发现组件来提供服务到服务的发现功能。
service to service 模式配置模板
(https://github.com/envoyproxy/envoy/blob/master/configs/envoy_service_to_service.template.json)
Service to service plus front proxy
![0?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/883b995749a4bdfe4cb9ac68ddf9d17a.png)
上图展示了在 service to service 模式前增加 Envoy 集群作为7层反向代理的部署模式。
该部署模式有以下特点:
-
TLS 卸载
-
同时支持 HTTP/1.1 和 HTTP/2
-
完整的 HTTP 7层路由支持
-
前端的 Envoy 代理集群使用标准的 ingress 端口与后端的 service to service 集群通信。对于后端服务集群节点使用服务发现方式获取。前端的 Envoy 集群节点是完全对等的提供服务,没有任何差异。
这种方式和 service to service 方式相比多出了 前端七层代理的部分。可以适配更多的使用场景。
Service to service plus front proxy 配置模板
(https://github.com/envoyproxy/envoy/blob/master/configs/envoy_front_proxy.template.json)
Service to service, front proxy, and double proxy
![0?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/69c60bf40680a3145f4e76238f77e786.jpeg)
双代理模式
双代理模式的设计理念是: 更加高效的卸载TLS、更快速的与client端建立连接(更短的TLS握手时间,更快的TCP拥塞窗口调整,更少的丢包等等)。 这些在双代理上卸载TLS后的连接最终都会复用 已经与数据中心完成连接建立的 HTTP/2 连接。
Service to service, front proxy, and double proxy 配置模板
(https://github.com/envoyproxy/envoy/blob/master/configs/envoy_double_proxy.template.json)
总结
以上就是ServiceMesh 数据面板 Envoy
的基本介绍。如果大家对 Istio 感兴趣,可以之后自行浏览 Istio 的官方网站,我也预期会在之后阅读其源码,更深入的了解 Envoy 工作原理,并会陆续给出Istio相关的文章和分享。