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

1.jpg

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


以下是分享全文：

Apache APISIX 是一个很年轻的项目，今年 6 月份开源，7 月份加入到 CNCF 全景图，10 月份进入 Apache 孵化器，所以我会先和大家分享一下 APISIX 是如何从 0 到 1 进入 Apache 孵化器的，随后再从以下三方面展开：

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

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

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

从 0 到 1：Apache APISIX 的 Apache 之路

Apache APISIX 现在有 17 个 committer，分别来自 16 家不同的公司，是一个非常社区化的项目。每个 committer 有一票，决定版本的发布、选举新的 committer 和 PPMC 等比较重大的事情。

Apache Way

Apache Way 是大家都比较熟悉的概念：社区大于代码。烂代码可以改，Apache 的导师并不会指导你怎么写出更高水平的代码，他们更关心的是社区是否在健康的发展，只要有一个好的社区，烂代码一定会有更高水平的人进行重构，变成更好的代码。所以只要社区在，那这个项目就能够一直存活下去，这在 Apache 是很重要的。

邮件列表优先是另一个重要的点，没有在邮件列表中出现过的，就当做不存在。这在中国其实是一个非常大的挑战，大家在文化上和习惯上都不太喜欢用邮件：第一是时间不够及时，可能发一封邮件后隔 1-2 天才能收到回复；第二是邮件列表的很多东西是公开的，有些人喜欢私聊；第三邮件列表里面只能出现英文，但其实中国人的英文是不差的，我们比大部分其他国家的人的英语已经好很多了，毕竟我们学了很多年英语，还有各种翻译的软件，即使出现语法错误，都不是大问题。

第三是精英治理，在 Apache 社区中大家用贡献来获得更多的话语权，更高的 title 意味着更多的付出和责任。

第四是民主，所有人都可以参与 Apache 的投票，即使你不在 Apache 社区，但不是所有人的票都是有效的。比如 APISIX 当时进 Apache 孵化器的时候需要投票，我也可以投支持票，但后面要写 no binding，表示我支持并关注这个项目，但我是一个观察员的身份，但这一票对于项目能否进 Apache 是没有决定性的。只有对孵化器做了贡献并得到社区认可的人，即 Apache 孵化器的 PMC，他们的票才是有效的，这就是 Apache 社区的民主。

开源社区的治理方式

我们知道很多开源项目有一些是在基金会下面，有一些则不是。在基金会下面的项目，比如 Linux 基金会、Apache 基金会，他们的治理模式叫做“社区共识”，需要先在社区内讨论，在达成一个共识后进行投票，而非直接投票。如果直接投票，没有前面的讨论和共识，那这个投票是没有意义的。这个效率可能会很慢，但只有整个社区达成共识，后面才没有异议。

第二种是商业公司共识，只要商业公司的人达成共识，那么这个 PR 或者 feature 就可以被合并，而社区的人说话是没有用的，因为它是被商业公司控制的一个项目，而如果你给商业公司贡献代码，能否被合并决定权在商业公司手里。这对于个人开发者可能无所谓，但是对于参与项目的企业则是有所谓的，通常企业会有私有版本，企业想把自己的 feature 贡献回社区，但商业公司可能因为这个东西和自己的商业版本冲突，就会拒绝掉。

第三种是仁慈的独裁者，典型的就是 Python，个人决定着开源项目的发展。

上述是开源社区的三种模式，如果是企业选择项目，一般的我们会推荐 Apache、Linux 基金会的项目，它首先在法律上是没有隐患的，其次它是一个社区共识，我们可以通过向社区贡献这种方式获得更多的话语权，这样就形成了一个良性的循环。

如何进入 Apache 孵化器

Apache 现在有接近 50 个孵化器的项目，其中来自中国的有 10 个，APISIX 是现在国内唯一一个由创业公司进入 Apache 的项目，其他很多是来自华为、阿里、百度等大公司的项目。

一个项目要想进入 Apache 孵化器，需要明白以下名词和步骤：

  • Champion：他是你项目的引荐人，这是你首先要去联系到的重要的角色，他需要熟悉你以及这个项目。

  • Mentor：项目的导师，在项目进入 Apache 孵化器之后，Champion 就转换成导师的角色，一个项目至少需要 1 个 Champion，2 个 Mentor，所以至少需要找到 3 个合适的人选。Mentor 会指导项目怎么从孵化器里边的一个项目，一步一步地成长为 Apache 的顶级项目，这其中包括发布 Apache 版本、品牌管理、壮大社区等。如果变成了顶级项目，那么这个项目以后就是社区自治了。

  • Proposal：找到 Champion 和 Mentor 之后，下一步需要写一个 Proposal，即一个提案，介绍我是谁，解决了什么问题，为什么要加入 Apache，项目现在的代码文件有没有和 Apache license 冲突的地方，初始的 committer 有哪些人、来自哪些公司，有没有什么潜在的风险，后面要如何发展等。

  • Discuss：接着会发起一个讨论的邮件，看有多少人对这个感兴趣，这个阶段也可以找到一些有兴趣的 PMC 来加入 Mentor 指导项目。

  • Vote：需要投票，投票通过，项目就可以进入 Apache 孵化器了。

Apache Way 和国内开源文化的冲突

国内的 Apache 项目会遇到很多不一样的挑战，这和国内外的开源环境和文化有关系。

比如国内的工程师会觉得太忙，经常 996 加班，所以没有时间和精力去做开源。但其实不少工程师在工作中也会使用到开源项目，写过开源项目的 feature，但是他们并不会主动提交 PR，也不会在写代码之前在社区内发起讨论，这就是很多文化上不同的地方。

沟通方式上，Apache 提倡的是在邮件列表中公开讨论，但是国内的很多开发者更喜欢微信、QQ、电话等非公开的方式来沟通。特别是如果一个项目的 PPMC 大都来自同一家公司，那么可能开早会的时候就把一个功能敲定了，但在邮件列表里也没有出现，这就不符合 Apache 的文化。

关于投票，很多开发者可能觉得自己英语不好或者人微言轻，不太愿意在邮件列表中发表自己的意见，也不参与投票，那么他就会被忽略掉。所以你需要积累一些”功绩“，去帮助别人，慢慢地增加自己的影响力。Apache 是一个由个人组成的基金会，每个人的行为都只代表自己，不代表公司，每个PMC 的一票都是对等的。

关于 Title，在 Apache 里，第一职位叫做 Apache 基金会主席，每个项目的管理者是 VP，然后是 PMC（项目管理员会）、 Committer、 Contributor ，他有一个类似于我们企业内职称晋级的通道。但是在 Apache里，即使你的职位变得很高，也并不意味着拥有更多的投票权，更多的是义务，比如对于 Apache APISIX 选举新的 committer 的投票而言，孵化器主席的票和我的票是一样的。Title 在 Apache 里面更多的是一种荣誉，因为 Apache 基金会是一个非营利组织，它强调的是贡献，这就是文化上的冲突。

版权问题

版权是一个非常重要的问题，前段时间发生的 Nginx 作者被抓就是因为版权问题。一个项目在正式加入 Apache 孵化器之前，所有 committer 和公司都要签署 CLA，说明将这个项目的版权，全部捐给 Apache 基金会。加入 Apache 孵化器之后，重要的里程碑就是发布第一个 Apache 的 Release，这个版本就是要理清 license 上的风险，让用户可以放心的使用。所以，商业公司使用 Apache 的项目是有保障的，不会涉及到版权不清晰的问题。

Apache APISIX 是一个正在快速发展的开源项目，希望大家多多参与和贡献，多谢。

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

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。

6.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 里做流量管理的控制。


以上是我今天的全部分享，谢谢大家！