微服务网关调研 | Zhang Jian Ao Notes

所谓微服务网关通常包含服务注册，发现，请求分发，流量控制甚至认证等功能。

在微服务架构下，由于不能将所有微服务直接暴露给客户端进行访问，微服务网关（或者 API Gateway）是必不可少的设施，关于 API Gateway 设计模式的描述可以看这里：https://microservices.io/patterns/apigateway.html

另外，近年在云原生环境中兴起了Service Mesh的概念，相关的Service Mesh系统通常也包含了微服务网关的功能，个人认为Service Mesh是可以代替传统的微服务网关的。

Zuul#

Netflix开源的微服务网关，在非云原生的Java项目中比较常见。

Kong是基于Nginx进行开发的，可能性能和吞吐量会好一些，也是在非云原生环境中比较常见。

Kong是一个商业公司，Kong Gateway有开源的社区版本。

另外Kong也在做Service Mesh的项目，Kong Mesh是一个基于Envoy的Service Mesh项目。也有一个开源项目叫：Kuma https://kuma.io/

HashiCorp的Service Mesh产品，其特点是号称可以在多个平台上部署，并且可以将不同网络下的服务链接到一起，也可以将不同的Datacenter下的服务器联通。

最著名的Service Mesh开源项目，复杂度较高。

也是著名的Service Mesh开源项目，只支持K8S，其2.0版本据说用Rust重写后性能很强。

Traefik Proxy 是一个云原生应用代理，完全用go实现，小巧易用，但功能上可能不如其它项目丰富。

Traefik Mesh 是一个简单易用的Service Mesh工具，与一般的Service Mesh的Sidecar模式不同，Traefik Mesh使用的是代理方式。

如果是非云原生的环境，可以考虑Kong和Zuul，Kong适应性更强，Java项目可以考虑Zuul

云原生环境下（主要指K8S环境），如果只需要微服务网关，Kong和Traefik是不错的选择

如果直接上Service Mesh，那么这里有一篇文章对比了Istio，Linkerd，Consul：https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/

Traefik的Service Mesh由于架构不同，感觉更像是借用Traefik Proxy魔改出来的，小型项目可以尝试使用

常规的 Service Mesh 主要是对于服务间通信的管理，但是 Dapr 更进一步，通过 Sidecar 提供了一些运行时的基础功能（例如：发布订阅等），值得深入研究。