知乎上找来的答案啊

先说结论：Nginx要搞自己的Service Mesh

去年IBM伙同Google和Lyft一起开源了微服务治理项目Istio。工作原理很简单：

1. 利用Kubernetes的Pod机制，在每个业务容器所在的Pod里自动注入一个Envoy容器
2. Envoy容器接管业务容器的所有进出流量
3. 这样Istio的控制平面（Control Plane）通过操作Envoy容器来实现一系列微服务治理的功能比如：
1. 蓝绿发布
2. 流量切分
3. 授权
4. 策略配置
5. （反正就是各种配置Envoy这个代理而已……）

这个项目巧妙地利用了Kubernetes推崇的容器化设计模式（Pod + 自动注入容器）实现了非常优雅的流量接管，打脸了一票Mesos党（雾）。又借助Google站台和跟Kubernetes原生绑定（虽然不lock），很快打开了云服务市场。而此时，类似的服务治理能力在容器化集群中还是一片空白呢。

有意思的是，Lyft在整个项目中，实际上就贡献了一个Envoy。但相比Nginx那一坨配置和插件，Envoy的好处很明显：基于API的配置方式，grpc+http2，非常适合作为容器部署。所以伴随着Istio的大热，Envoy很快就火了，不仅在各大公司里都有了落地，还有很多从Nginx迁移到Envoy的案例刷刷地冒了出来（比如：https://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d），很多startup甚至一上来就直接选Envoy来做proxy了。

这，就让Nginx很尴尬了。

所以Nginx先是做了个Nginx Mesh，其实就是把上图中的Envoy容器换成了Nginx容器。无奈Nginx实在是太“原始”了，尤其是配置太难用了。所以这次的Unit，其实就是按照Envoy的模式重新做了一个方案，从而让Nginx真正有能力去扛Service Mesh的大旗。这么看，它的三个关键特性就很容易理解了：

Multi-language support = 方便部署

Programmable = 基于API的配置方式

Service mesh = 支持Istio的现有功能

当然，要想直接撼动Istio现在的地位还是很难的。所以可能也会先考虑跟Istio集成，然后可以再发布一套类似的方案？毕竟这一块大家目前都走的不远，还有一大票优化、特性可以做呢。

其他回答里有说没啥卵用的，这东西你单机装一个玩必然没啥卵用。不妨把咱那套Kubernetes集群上的灰擦一擦？

不支持反向代理http2.0

没有回答，我就只能自己回答了。

查了下代码，进行gdb跟踪调试后发现：这个主要是因为，每个worker单独维护一个前后端 “链路”关联的四元组信息，在多个worker的情况下，不同的worker保存“链路”关联信息相互独立，彼此不共享。因此即使是相同的IP和端口发来的消息，只要是分配到不同的worker进行处理，都有可能查不到之前的“链路”关联信息，从而无法复用。

解决办法：

1. 单worker配置（性能可能偏低）

2. 修改代码，使用共享内存保存已有的前后端“链路”关联信息，不同worker之间共享结果