envoy 代理 socket.io
最近在做web 长连接消息通道的方案与实现， 目前web 的方案主要有websocket。 后来经过调研发现socket.io 的浏览器兼容性更好。于是
使用socket.io 作用通信连接。本文记录在此过程中遇到的问题。
主要的问题：
envoy 代理socket.io .
<h2>1. socket.io </h2>
socket.io 集成了websocket 和polling，并可以感知浏览器的是否支持websocket， 建立websocket 连接，如果不支持websocket
就使用ajax polling. 故兼容性比较好， 具体可以google socket.io.
2. 为什么会有envoy 代理socket.io ？
这和我们是实现方案有关， 下面是我们的服务简单的部署拓扑。
这个方案是基于mesh service 的sidecar 方式部署， 前面有一个front-Envoy 作为一个接入层。
front-evnoy 其实就是在docker里部署一个envoy。
后端的services 是一个服务的集群， 上图有2个socket.io service 组成的连接管理服务。
总体来看，数据经过两次代理，sidecar 内地代理很简单，配置简单，只有配置envoy websocket 和http 就可以。
只有设置route_config 相应virtual_hosts 设置use_websocket 为true 。
另外一个代里是本文记录的重点。
就是front-evnoy 到后端的service 集群。 简单分析可知，socket.io service 其实是一个有状态的服务， 它一个连接管理器。
假设client A 要使用socket.io 建立长连接， front-envoy 要正常工作必须保证， A 的后续的所用的包都发送到后端的同一个service.
这就是envoy 如何代理socket.io 的问题。
3. envoy 的负载均衡
envoy 支持很多很多中负载均衡方式， 但是目前满足我们需求的只有ring hash 这种负载均衡。
可以参考envoy 文档
envoy ring hash
ring hash 可以配置一个http header的字段作用hash key.
经考察，我使用了这个x-forwarded-for字段， x-forwarded-for 这字段一般填的是client 的ip.
部分配置如下：
"route_config":
{
"virtual_hosts":
[
{
"name" : "backend",
"domains" : ["*"],
"routes" : [
{
"prefix" : "/",
"cluster": "websocket_cluster",
"use_websocket": true,
"hash_policy": {
"header_name": "x-forwarded-for"
}
}
]
}
]
},
...
{
"name":"websocket_cluster",
"type":"static",
"connect_timeout_ms":2500,
"lb_type":"ring_hash",
"ring_hash_lb_config": {
"minimum_ring_size": 1024,
"use_std_hash": false
},
"hosts":[{"url":"tcp://10.10.62.120:3000"},{"url":"tcp://10.10.62.121:3000"}]
}
4. e
有疑问加站长微信联系（非本文作者）
