课程回顾：API网关技术最佳实践

随着企业信息系统复杂度的提高，如何统一管理、如何协调多种协议、如何保障外部的安全访问等问题也随之而来。而如今，API网关很好的解决了这一系列问题。通过 API 网关，您可以封装后端各种服务，以 API 的形式，提供给各方使用，同时隔离了业务系统与外部系统，保障了业务方数据的安全性。

API网关的概念可能大家都有所了解，但如何使用进行产品选型，如何利用API市场快速包装服务，API网关背后的技术难点等等问题，您可能仍然比较迷茫。为此，腾讯云API网关团队邀请OpenResty团队，腾讯云生态产品经理及腾讯云API网关高级工程师们，举办了一场高质量的API网关技术实践课。本文整理了课程《API网关技术最佳实践》的精彩内容，围绕API 网关相关技术以及最佳实践展开讨论。从开源OpenResty高性能解密、到企业如何利用云环境快速上线服务、个人开发者如何轻松创业、API 网关能给你的生活带来哪些改变多个方面深入理解API网关。

OpenResty温铭

以APISIX为例，探探OpenResty中的测试，代码检测和持续集成

OpenResty 除了性能足够好之外，代码的稳定性也是有口皆碑的。如何保证我们自己项目代码的高质量呢？只靠 QA 团队显然是不够的。OpenResty 软件基金会主席温铭以 APISIX 为例，分享了 OpenResty 中技术选型、测试和持续集成的宝贵经验，让你在没有 QA 团队，开发资源也很紧张的情况下，依然能够保持代码的高质量和快速的开发节奏。

PISIX是一个基于云原生、高速可扩展的开源微服务网关节点实现。APISIX在2019.6.6开始开源，不到一个月进入了CNCF全景图，是目前进入CNCF全景图最快的开源项目。图中是APISIX在Github上的star数趋势，从开源起持续受到关注。

相较于行业领头谷歌背书的 apigee，和开源巨头 Kong 等网关，APISIX 具有什么样的优势呢，温铭为我们做了一个详细的对比和讲解。

Apigee 来自谷歌，是最早的 API 网关之一。优势在于功能十分健全，包含了全生命周期，开发者可以完全不懂代码就可以实现从设计到发的一整套流程。缺点是性能差，不开源，只能在Google云上使用，无法做自己的集成。

Kong 的优点是产品思路清晰，每一次迭代都环环相扣，商业版和开源版能满足不同的需求。缺点在于其代码复杂，封装多，改写了一些 Lua 的库函数；依赖于关系型数据库，如果用在微服务/云原生比较格格不入，同时二次开发难度大。

APISIX 基于 Kong 的思路进行了重构，代码的易读性和可维护性更好，插件热加载，插件的二次开发更简单。劣势在于目前只开源了一个月，还需要市场的检验。

如果要做一个API网关，我们应该如何从0开始做网关的技术选型？温铭表示，API网关的核心组件有四个：路由、插件、schema和储存。选择合适的核心组件，能大大提升产品性能。

APISIX目标是打造云原生、高性能、开源的 API 网关。因此在选型上，优先考虑以下原则：

云原生友好：保障后端计算、可拓展性和并行处理都与云架构相匹配；
开发者第一：架构简洁、方便扩展、代码易读、部署简单，方便开发者进行二次开发；
极致性能：时间复杂度、FFI 和Lua 代码

为此，APISIX的核心组件选型，进行了合适的调整与优化：

路由：lua-resty-r3，FFI
插件：灵感来自 Kong，大幅度简化编写难度，热加载
schema：rapidjson，json schema
存储：etcd， lua-resty-etcd，高可用，云原生

而OpenResty在没有专职QA的情况下，是如何保障代码的高性能的呢？这主要是依赖于测试驱动开发，是开源项目的立足之本。提交功能代码的同时，必须有测试案例，同时保证代码覆盖率不能低于 70%。

OpenResty是这么做的：OpenResty 和 lua-resty-* 模块都带有完整的测试案例集；用 perl 编写的 DSL，专门用于 nginx 和OpenResty 的单元测试；每次版本发布前，OpenResty跑完整回归测试、内存泄漏测试、fuzzing 测试，以保证可靠性。

OpenResty的测试方案在APISIX上实践，包括完全基于test::nginx的单元测试，代码风格检测和代码覆盖率检测等，实现了开发即测试，保障了代码高性能。

持续集成的核心在于代码集成到主干之前，必须通过自动化测试。花费在测试和 CI 上的工具和时间都是值得的，回归测试、打包、发布版本和发行包还依赖人的参与。APISIX利用Travis CI，coveralls.io和docker 自动化打包（WIP）来实现持续集成。

最后，温铭总结道，开源资源少，不一定是坏事儿，APISIX 的选型、测试和 CI 都是找“取巧”和自动化的方式，这三者比性能更重要。

腾讯云金鑫

高可靠的API网关背后

随着微服务的兴起和发展，用户开始关心如何让业务方安全地对外开放，快速调用外部接口。API网关解决了诸多问题。但市面上大多开源产品代码复杂，二次开发难度高，难以适应性的应对客户需求，而独立开发耗费大量人力、运维成本。腾讯云API网关则提供了一个完整的API托管服务，协助开发者轻松完成 API 的创建、维护、发布、监控等整个生命周期的管理。腾讯云中间件中心后台高级研发工程师金鑫，从实际的客户案例出发，分析客户的需求场景，深入探讨客户的核心诉求，同时从腾讯云API网关的架构入手，分析腾讯云API网关是如何实现高可靠的。

典型案例：

金鑫首先分享了三个客户案例，来介绍API网关是如何服务客户需求，优化产品性能的。

第一个客户是某互联网监控企业，需求是将其自身业务数据在docker中的分析结果定向给到自身的客户。具体要求包括：1）根据客户权限，允许客户调用数据，定时给客户推送数据；2）需要区分客户，对不同客户做不同的流量控制。针对客户权限，腾讯云API网关给出了客户鉴权的解决方案，提供完整的鉴权能力，区分客户是否有权限进行数据获取，以及是否有权限建立Websocket长连接，可保证客户业务的管控与安全性。针对流量控制，API网关对每个调用客户的密钥对进行鉴权，以此进行QPS限制，实现精准的流量控制。

第二个案例来自某旅游企业，金鑫介绍了利用API网关，如何解决客户的技术痛点。该客户面临的问题有三：一是访问终端多样，不同终端访问标准不统一，鉴权复杂；二是前端访问数量难以预估，对后端资源的压力难以控制；三是没有过渡访问环境进行引流，后端变更容易引发事故。而API网关的特性刚好可以解决这些问题。API网关可对不同终端的访问接口进行统一鉴权和管理，同时可对前、后端解耦，并对前端访问进行限流，解决了鉴权和后端访问压力的问题。使用API网关的生产、预发布、发布环境，可有效降低人为事故。

最后，金鑫介绍了某工业企业的案例，其目标是进行系统改造，以及售卖部门自身能力。客户大部分业务有老系统存在，希望将部分业务改造为微服务框架，并对微服务与老系统统一管理。同时希望能把自身的一些业务能力，以及合作伙伴注册在自身的能力开放出去售卖，提供给自己的用户，同时保证自身的数据安全。对此，腾讯云给出的解决方案是，使用API网关对接后端微服务与原系统的业务，统一进行管理；使用API网关支持API市场方案，将自身的能力开放给用户进行统一的售卖。接入腾讯云API网关后，该客户实现了统一管理后端多种框架的业务，同时兼容新的微服务框架和不可变更的老业务系统。业务上，不但可开放API给内部使用，也可以开放API市场，将能力售卖出去，价值变现，形成自己的生态。此外，API网关还成功对接客户自身的Oauth服务器，提供云监控查看视图，流量、请求清晰可见。

网关架构：

那么腾讯云API网关是如何设计，来支持这些功能的呢？我们先从架构入手。

腾讯云API网关分为三部分：接入层，逻辑转发层，转发到后端。

高可靠的接入层——多层容灾能力：

数据进入腾讯的TIX，首先经过核心交换机，双活设计，通过vip的奇偶策略转发数据到下一层交换机，保证流量的均分。交换机层，同样双活设计，通过源目hash选择lD，vip1 落在交换机A，一半流量从交换机A 转发给一半集群，另外一半从交换机B转发。

同时，采用宙斯盾，是一个高防系统，可抗DDOS攻击。

逻辑转发层：

腾讯云API网关受Kong的启发，并对其进行改造。这里简单介绍一下 Kong和腾讯云实现的区别。Kong的转发进程是在进程中监听不同端口来获取配置类的指令，进而存储到DB写到内存，Kong轮训配置，直接生效。而腾讯云API网关逻辑是：配置下发后需要发布后才能生效，指令暂存DB，待发布后，由Master 将制定的配置送入agent，agent更新共享内存。同时给nginx发送信号，将共享内存数据加载到本地内存，实现配置更新。秒级生效。

后端架构：

以微服务为例（即腾讯云微服务TSF），后端的资源节点可以是docker容器部署方式，也可以是虚拟机部署方式。这里以容器为例。

技术难点：

挑战一：如何在不同网络之间进行通信。GRE 协议包，GRE封包格式会记录目的母机IP VPCID。大家可能会有疑问，只记录母机和dockerip，中间还有一层子机呢。如何找到目的地呢？

这里是腾讯云强大的IAAS层，VPC私有网络专门针对容器设计的网络方案，母机上都会记录每个容器的cidr。不同的CVM会分配不同的cidr。从而根据dockerip即可找到对所属的CVM进而找到docker

挑战二：CVM在某些场景会进行热迁移，例如母机资源利用率需要进行动态调整，故障迁移等。此时，子机从母机1到母机2，如果API网关逻辑层不能快速处理或者处理错误，都会影响网络转发。

针对这一难点，要如何做呢？依然利用强大的IAAS层，私有网络会记录新的子机所在的母机2，从而转到母机1的流量会中继给母机2，从而实现流量不断。当API网关处理完，再通知vpc oss，已经处理完，不再做中转。

在高可靠的服务基础上，API网关支持日志收集、腾讯云市场、鉴权、Websocket、跨域、监控告警等功能。由于篇幅有限，在此不再展现功能的实现方式。

无论是客户希望使用 API 网关服务，还是供应商希望通过云市场将自己的服务开放出去，都可以使用 API 网关。API网关支持多类型的前端、后端，解耦前后端业务，帮助客户鉴权和限流，使用场景多样。针对不同的客户需求场景，腾讯云API网关都交出了一份满意的答卷。

腾讯云高树磊

基于云一小时搭建在线甲醛检测

新房装修，甲醛检测如何做？甲醛检测的复杂流程，一直是新居主人们心中的痛，单次检测不可持续，现场操作费时费力。那么云时代的甲醛监测，是否有其它的玩法呢？腾讯云高级生态产品经理高树磊，与大家分享了一种新的解决思路，通过API网关、无服务器云函数、云数据库等多个云产品与树莓派的组合，仅依靠单人数小时的工作，即可实现对甲醛的持续监测，帮助用户更好的了解甲醛治理的效果。

设计思路：

无论是小型创业团队还是个人开发者，搭建产品的最大阻碍在于人力成本。如何确定实现方案？不如从需求入手，再合理规划资源，逐步理清计划。功能上，我们希望在本地的终端能够实时监测和展示所测甲醛数据信息，同时建立API接口，可在云端要储存和显示最新数据和历史数据。而在技术实现上，希望整体系统能安全、稳定、分级可用且易于维护。

树莓派支持多种语言，开发简单，接口较全，通信方便，为此，我们在硬件上选取树莓派和甲醛传感器来实现甲醛数据的采集与计算。而对于个人开发者来说，自建API网关、数据库等所需的人力成本过高，故选择接入腾讯云，使用腾讯云API网关、云函数、云数据库和腾讯云图服务来实现云端数据存储和展示。

终端实践：

硬件上选取树莓派进行数据采集、处理、传输与显示。传感器获取数据后，通过UART协议进行传输。处理的数据结果通过OLED屏在树莓派上显示。

如前所说，对于创业者和个人开发者来说，自建服务器、数据库所需的人力成本过高，同时，对其进行运维也需要不小的开支。而使用腾讯云服务则可以大大降低开发成本。

本次甲醛检测中采用的云服务有API网关、云函数、云数据库、腾讯云图。利用这些服务，可以低成本、低耗时的实现数据的安全包装、输出、储存和云端显示。

API网关：腾讯云API网关实现完整API 托管的服务，协助开发者进行API 的创建、维护、发布、监控等。利用腾讯云API网关，可以大大简化编程流程，仅需在控制台上进行创建、配置、设置鉴权等简单操作，即可对数据输出进行包装，安全的对外输出。而腾讯云API网关只对 API 网关中的 API访问和网络出流量付费，无需为 API 的管理、文档维护、SDK生成、流量控制和权限控制付费。使用成本低、开发难度低，大大缩减小型创业团队和个人开发者的开发时间和成本。

腾讯云API网关保障用户的通讯安全。QCloud 子域名 HTTPS 支持和客户域名 HTTPS 支持，保证 API 的安全通讯。可使用 secretid secretkey 的方式进行用户认证，保障认证安全可靠。

无服务器云函数：腾讯云SCF（Serverless CloudFunction）是腾讯云为企业和开发者们提供的无服务器执行环境，支持在未购买和管理服务器的情况下运行代码，实时文件处理和数据处理等场景下理想的计算平台。在SCF上配置好代码和触发方式（API网关），即可上线服务。

云数据库：在云数据库上建立库表，储存短期（10m）和长期（7d）的测量数据

腾讯云图：腾讯云图可实现在云端的数据展示，通过图形化界面拖拽显示控件，并指定显示的数据源，即可进行实时监控。无需前端开发，操作简单方便，10分钟零门槛打造专业的数据屏展示。

至此，一套完整的甲醛检测系统打造完毕，工程简单，又满足了所有的需求。合理设计系统、合理使用云服务可大大简化开发流程，降低开发成本。

OpenRestyle王院生

APISIX 网关高性能实战

APISIX 已经在 6 月宣布开源，目标是运行最快的微服务 API 网关，从架构设计开始第一天，就把性能作为第一要素，在支持保持动态的同时性能依然不减。OpenResty软件基金会联合创始人王院生分享了APISIX的九大优化技巧，深入探讨APISIX如何做到强大的扩展性与高性能。

作为一个新开源的API网关服务，APISIX目前最新版本0.5（etcd libr3 rapidjson），超70% 的代码覆盖率，核心代码覆盖率超过 90%，有可能是目前性能最高的开源API 网关。同时，虽然开源仅两个月，APISIX的功能和性能却不容小觑。单worker可支持23-24k的QPS，4worker可支持68k的QPS。