2019 年 12 月 14 日,又拍云联合 Apache APISIX 社区举办 API 网关与高性能服务实践丨Open Talk 广州站活动,Apache APISIX PPMC 温铭做了题为《Apache APISIX 的 Apache 之路》的分享。本次活动,邀请了来自ApacheAPISIX、又拍云、腾讯云、HelloTalk 等企业的技术专家,分享网关和高性能服务的实战经验。

1.jpg

温铭,深圳支流科技创始人,Apache APISIX PPMC,《OpenResty 从入门到实战》专栏作者,创业之前在互联网安全公司工作了 10 年,主要从事服务端的开发和架构,负责开发过木马云查杀、反钓鱼系统和企业安全产品。曾在奇虎 360 担任架构师,开源委员会发起人、委员。支流科技是一家开源底层技术初创公司,致力于微服务相关技术的创新和实现。

下面我会从以下几个方面介绍今天的主题:

  • Apache APISIX 是什么,能解决什么问题

  • 回顾微服务是怎么从单体变成现在的     Service Mesh

  • 介绍 Service Mesh 是银弹吗,以及我眼里的下一代微服务架构


Apache APISIX

简单来说 Apache APISIX 是一个微服务 API 网关,它不仅可以处理南北向的流量,也可以处理东西向的流量即服务之间的流量。很多 API 网关的数据库可能是 postgreSQL、mysql 等,它在云原生的环境下需要几秒钟才能启动,而作为 sidecar 也特别重,我们希望 Apache APISIX 在容器里面能够很轻巧地、毫秒级别地启动,和 K8S 的技术栈很接近,基于 Nginx 和 etcd 来实现。

Apache APISIX 集成了控制面板和数据面,与其他 API 网关相比,Apache APISIX 的上游、路由、插件全是动态的,修改这些东西时都不用重启。并且 Apache APISIX 的插件也是热加载,可以随时插拔、修改插件。

Apache APISIX 今年快速地成长,从 6 月 6 日开源,7 月被纳入 CNCF 全景图,8 月迎来首家付费央企,9 月份贝壳找房上生产环境,每日处理近 5 亿流量。10 月进入 Apache 孵化器,是国内唯一由初创公司贡献的项目,11 月全面支持 ARM64 平台,并推出 apisix-ingress-controller,拥有动态路由的能力,解决了官方 K8S 的一些痛点。

2.jpg

上图是目前 Apache APISIX 的部分用户,NASA(美国的航空航天局)也在使用 Apache APISIX,而且是在一个很重要的地方——火箭推进实验室,包括探月项目、火星探测的项目都是在这个实验室做的,他们使用 Apache APISIX 去处理微服务之间和南北向之间的流量。


Apache APISIX 的功能和作用

API 网关的传统功能包括反向代理、负载均衡、动态 SSL 证书、动态限流限速、主动/被动健康检查、服务熔断等功能,这些功能 Nginx 也同样具备。

在云原生的架构下,会衍生出很多新的功能需求:

  • 对接更多的监控和链路追踪,希望 API 和微服务之间的流量做到可视化,如 Prometheus、Zipkin、Skywalking

  • gRPC 代理和协议转换(REST     <=> gRPC)、websocket

  • 身份认证:OpenID Relying     Party、OP(Auth0、okta…)

  • Serverless

  • 高性能、无状态、随意扩容和缩容

  • 支持多云、混合云

  • 容器优先,Kubernetes 友好

性能上,Apache APISIX 比空转的 OpenResty 性能只低了 15%,在我们下一个商业版本里,即使有插件的逻辑存在,也会保持和 OpenResty 空转的性能相同,这里有我们的一些黑科技在里面。

Apache APISIX 能够帮助用户处理 L4、L7 层流量:HTTP、HTTPS、TCP、UDP、MQTT、Dubbo、gRPC、TLS…如果用户有自定义的 4 层RPC 协议也可以实现。

Apache APISIX 可以替代 Nginx,把它从一个静态的配置文件管理的服务器变成一个纯动态的 API 控制的 Web 服务器。也可以用 Apache APISIX 替代 Envoy 处理服务间的东西向的流量,它会更加高效且稳定。

此外,你也可以把 Apache APISIX 作为 k8s ingress controller ;基于灵活的插件,提供了 MQTT 的插件可以作为 IoT 网关,借助 IdP 插件成为零信任网关。我们希望 Apache APISIX 能够快速处理所有业务的流量。


微服务演进史

我们先来回顾微服务的演进史,回顾历史才能更好地知道未来做什么。

  • 从单体到微服务

3.jpg

如上图,这其实是一个单体,下面有 3 个服务,3 个服务分别做了 3 件不同的事,但它们里面有很多重复的功能,比如限流限速、身份认证等,是每个接口都要做的。每个 API 做了很多与业务不关但是又不得不做的事情。这种模式的痛点是做了大量的重复开发,如果在容器里面跑,不仅重,修改起来也麻烦,并且一旦把限流限速的逻辑修改了,那么每个服务都要修改。

API 网关的作用就是把业务无关的功能剥离出来,让你的 API 只关心业务本身,与业务无关的功能全都丢给 API 网关,包括协议的转换、限流限速、安全、统计、可追踪、缓存、日志报表等。如此,业务才能跑得更快,这就是为什么微服务会从单体变成 API 网关的架构。

  • 微服务从类库到 proxy

很多 Java 工程师微服务架构会选择 Spring Cloud 或者 Dubbo, 这种是语言绑定的,它用类库的方式放在代码里,升级困难,如果团队是多语言就需要维护多个类库,假设你有 10 个版本,10 个语言,就需要维护 100 个类库。

4.jpg

这里可以使用 proxy 的方式来解决,即 API 网关,它用代理的方式把多版本和多语言的问题解决了。

  • 微服务从 proxy 到 sidecar

很多 proxy 都是基于 Nginx 来实现的,众所周知 Nginx 所有的功能都是根据配置文件实现的,因此 proxy 存在路由、上游、证书等不能动态的痛点。在 K8S 体系下,上游与证书经常会发生变化,如果使用 Nginx 来处理就需要频繁重启服务,因此我们就抛弃了 proxy 的方式,转而采用 sidecar 的模式,即 Service Mesh。

5.jpg

服务对 Sidecar 是无感知的,进来的流量和出去的流量都会被边车劫持。API 网关做的与业务无关的功能,都在边车里面来实现。简单地来说,把 API 网关打横了,其实就变成了边车,功能基本相同,区别就在于一个是处理南北向流量,一个处理东西向流量,

  • 从 sidecar 到 Service Mesh

如果只是简单的边车,它还不够通用,并且抽象的层次也不足,因此有了 Service Mesh 想作为基础设施下沉到每个服务旁边。在此之前,边车其实是可选的,但是在 Service Mesh 里边车是一个必选项,Istio 和 Envoy 一个做控制面,一个做数据面,挂在每个服务旁边。

但是这种方式也是存在问题的,每个微服务都要带 sidecar,如果做多次流量转发,性能是有问题的,Istio 和 Envoy 经常会被大家吐槽性能的问题和稳定性。


下一代微服务

我认为 sidecar 的模式到最后也会消失,它会变成一个可选项,而非在 ServiceMesh 里的必选项。我们希望通过 Apache APISIX 把 sidecar 从微服务的边车模式抽取出来,用户可以部署一个或多个 APISIX,可以和微服务部署在同一台机器上,也可以分开部署,走向中心节点或者集群的模式。我们认为下一代的网关可以替代掉 Service Mesh,因为大家解决用户的问题是一样的,包括服务治理、流量管理、及时动态感知变化等。

Apache APISIX 能够做到全动态、全协议支持、高性能、云原生友好。我们希望 Apache APISIX 不仅能把 Nginx 的南北向流量吃掉,同时把微服务东西向的流量吃掉,我们也希望 Apache APISIX 不仅能做 API 网关,也能做 k8s ingress controller,更可以在 Service Mesh 里做流量管理的控制。