python微服务之网关选择

引言

书接上文python微服务方案，上回书我们说到，python微服务方案我们的简单设想。设想归设想，终归是要落地的，经过近些时间的实验，我们也略有成效，再次不才，这次我们来聊聊从微服务的最上层组件—网关：

1. 网关是什么？

当我们决定使用微服务时，不可避免的就会存在多个服务，每个服务都需要权限校验、限流以及监控等，显然，在每个服务中都实现一次“权限校验、限流以及监控”，显得有些ugly，且不符代码复用的方针。

网关就很好的解决了这个问题，它将“权限校验、限流以及监控”这些功能抽离解耦出来，以过滤器的方式放于网关。这样微服务只需要关注自己的核心功能就可以，权限相关的逻辑全全教育网关即可。

简单来说： 网关 = 路由转发 + 过滤器

2. 网关的作用？

• 路由转发：接收一切外界请求，转发到后端的微服务上去
• 过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）
• 负责均衡：API网关结合负载均衡技术，利用Eureka或者Consul等服务发现工具，通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡
• 安全认证：校验参数合法性，用户合法性
• 日志监控：记录请求的出参、入参，响应时长等
• 数据转换：对不同客户端请求数据加工等

3. 常用的网关有哪些？

主流的有nginx和java两大阵营

4. 我们选择的网关APISIX

4.1 技术栈

我们组主语言是python，关于java相关的组件没做太多考虑，维护和扩展对我们有较高的学习成本，所以我们对java相关的组件选型时，优先级会比较低。

Kong 和 Apisix就是我们的选择对象了。参考了对比微服务网关 Kong 和 APISIX后，我们决定选择了Apisix。

主要有三个原因：

1. 在不开启插件的情况下，APISIX 的性能（QPS 和延迟）是 Kong 的2倍
2. 开启了两个常用插件后，APISIX 性能就是 Kong 的十倍
3. APISIX支持python插件
4. APISIX 是国内公司贡献给Apache的，中文社区很活跃，文档也丰富（可以跟作者母语交流，舒坦）

4.2 选型声明

1. 必须承认我们的选型并不严谨，其原因在于我们对网关的要求并不高，市面上常用的网关几乎都能满足我们的要求，因此我们主要从小组成员的技术栈和使用习惯上进行选型。
2. 必须强调，要考虑网关的可维护性和扩展性，Nginx+Lua这个组合掌握的人不算多，java相关技术栈可能更稳妥些。

5. 如何使用APISIX

这里只简单介绍我们使用的基础功能路由和鉴权配置。关于简介、安装、集群模式以及其他功能，可参考APISIX官方github和APISIX使用说明。

5.1 架构说明

Apache APISIX 是一个动态、实时、高性能的 API 网关， 提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。

你可以使用 Apache APISIX 来处理传统的南北向流量，以及服务间的东西向流量， 也可以当做 k8s ingress controller 来使用。

Apache APISIX 的技术架构如下图所示：

核心概念

• 上游（Upstream）：上游列表包含了已创建的上游服务（即后端服务），可以对上游服务的多个目标节点进行负载均衡和健康检查。
• 路由（Route）：通过定义一些规则来匹配客户端的请求，然后对匹配的请求执行配置的插件，并把请求转发给指定的上游。
• 消费者（Consumer）：消费者是路由的消费方，形式包括开发者、最终用户、API 调用等。创建消费者时，需绑定至少一个认证类插件。
• 服务（Service）： 可以理解为一组路由的抽象。它通常与上游是一一对应的，路由与服务之间，通常是多对一的关系。
• 插件（Plugin）：API网关对请求的增强操作，可以对请求增加限流、认证、黑名单等一系列功能。可以配置在消费者、服务和路由之上。

5.2 简单的安装

# 从github下载apisix源码
git clone https://github.com/apache/apisix-docker.git
cd apisix-docker/example
​
# 使用docker-compose启动
docker-compose -p docker-apisix up -d

安装后会获得四个地址：

1. 前端地址为： http://192.168.2.128:9000
2. 后端地址为： http://192.168.2.128:9080
3. 测试服务1（web1）：http://192.168.2.128:9081
4. 测试服务2（web2）：http://192.168.2.128:9082

注：192.168.2.128 为笔者测试环境的内网ip，使用时注意替换，且不要用127.0.0.1代替

5.3 配置上游（后端服务）

配置上游web1，如下图（web2同理）

5.3 配置路由

配置web2的路由，如下图（web1同理）

 配置好后可通过postman测试

5.4 配置鉴权

5.4.1 修改路由，增加鉴权插件

以jwt-auth举例，如图所示（注意key，要与5.4.2中的消费者对应）

5.4.2 增加消费者

创建消费者如图

5.4.3 增加创建token的接口

curl -X PUT 'http://192.168.2.128:9180/apisix/admin/routes/r1' \
   -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
   -H 'Content-Type: application/json' \
   -d '{
   "uri": "/apisix/plugin/jwt/sign",
   "plugins": {
       "public-api": {}
  }
}'

5.4.4 验证

1. 不使用token访问web1，需要JWT认证

​​​​​​​

2. 生成token

3. 使用token，访问web1，访问成功

6. 后记

今天的故事，到这里也就结束了，最后多啰嗦几句：

网关是流量的入口，除了做鉴权之外，还能做很多事情（限流、转发、监控等），本次只是抛砖引玉，简单分享下我们目前对网关的选型逻辑，以及简单的使用说明，仅供参考，望能帮助到需要的朋友。

7. 参考

1. 微服务下的网关如何选择
2. 对比微服务网关 Kong 和 APISIX
3. APISIX官方github
4. APISIX使用说明​​​​​​​