知乎上找来的答案啊

先说结论：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集群上的灰擦一擦？

参考：client_body_timeout 5s;

client_header_timeout 5s;