怎么看 NGINX 团队新出的 NGINX-UNIT?

貌似是 nginx https://www.nginx.com/products/nginx-unit/

而且还是开源的:nginx/unit

看起来应该是将 PHP 等一些模块直接编译进去了?是不是性能将更加优于 php-fpm

邀请回答
提问于 2020-08-27 12:26
333 次浏览
共1个回答

发表评论
  • 守望
    2020-08-27 12:54

    知乎上找来的答案啊

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

    2
    回复
    举报
提问者

阿尔巴

如果你联盟

  • 12

    文章

  • 11

    粉丝

  • 19

    被赞

阿尔巴
按Enter键发送
您已邀请位用户
版权所有©F5 Networks,Inc.保留所有权利。京ICP备16013763号-5