基于 Apache APISIX 的下一代微服务架构

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

温铭，深圳支流科技创始人，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 的一些痛点。

上图是目前 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 可以帮助用户处理 L四、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 个服务，3 个服务分别作了 3 件不一样的事，但它们里面有不少重复的功能，好比限流限速、身份认证等，是每一个接口都要作的。每一个 API 作了不少与业务不关可是又不得不作的事情。这种模式的痛点是作了大量的重复开发，若是在容器里面跑，不只重，修改起来也麻烦，而且一旦把限流限速的逻辑修改了，那么每一个服务都要修改。

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

• 微服务从类库到 proxy

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

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

• 微服务从 proxy 到 sidecar

不少 proxy 都是基于 Nginx 来实现的，众所周知 Nginx 全部的功能都是根据配置文件实现的，所以 proxy 存在路由、上游、证书等不能动态的痛点。在 K8S 体系下，上游与证书常常会发生变化，若是使用 Nginx 来处理就须要频繁重启服务，所以咱们就抛弃了 proxy 的方式，转而采用 sidecar 的模式，即 Service Mesh。

服务对 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 里作流量管理的控制。

以上是我今天的所有分享，谢谢你们！

演讲视频观看及PPT下载：

基于 Apache APISIX 的下一代微服务架构