基于 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 能够帮助用户处理 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 个服务，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 里做流量管理的控制。
