AI+安全网关服务化部署保姆级方案上线！

随着AI浪潮一波一波袭来, 许多企业已经深深感受到深度学习的应用在产业转型及日常工作上带来的助益。而对于企业的开发者来说, 使用服务化(Serving)的Server-Client系统架构部署深度学习服务已经变成一种最常见的方式, 满足了众多非AI从业人员的调用需求, 也让更多人能感受到深度学习的魔力。

 

近年来，微服务架构已经在中大型企业中广泛应用。虽然解决了单体架构带来的隔离/扩展性差、部署开发慢、创新性低等问题，但也带来了一些新的安全问题。在微服务架构中，一个大的应用会被拆分成多个小的单一的服务，这些较小的服务有各自的功能模块和数据库（也可以共用），因此业务系统开发的每个接口都需要独立实现与安全相关的认证、授权和限速，不但需要重复开发、无法统一管理、容易产生遗漏，且使用服务化部署进行微服务串联时，还可能会遇到以下问题：

 

• 服务使用了多种协议，因为不同的协议有不同的应场景，比如可能同时使用 HTTP, AMQP, gRPC 等。

• 服务的划分可能随着时间而变化。

• 服务的实例或者Host+端口可能会动态的变化。

• 服务的安全加密HTTPs功能不支持。

 

这些问题该如何解决呢？Paddle Serving的全新安全网关功能就能一次解决您的所有问题！

 

 

现在越来越多的企业在业务上线时有安全网关的需求。虽然很多开发者有能力把深度学习模型顺利部署到服务端，但如何顺利地把深度学习部署和API网关合并使用，仍是个难题。而这两者的结合恰恰是产业落地AI的关键之一，也是AI服务从一个Demo或者PoC转变成实际落地应用的关键因素。

 

何谓安全网关 （API Gateway）？

 

这里以开源网关框架Kong/Konga为例，给大家解释一下。

 

安全网关通常由一个路由器和一个处理机构成，两个部件结合在一起，即可提供协议、链路和应用级保护。这种专用的网关不像其它种类的网关，需要提供转换功能。作为网络边缘的网关，它们的责任是控制出入的数据流以及保护内网不被非授权的外部网络访问。安全网关联接的内网与外网都使用IP协议，因此不需要做协议转换。

 

企业随着信息系统复杂度的提高，经常出现一个平台需要管理多种应用，以及每一种应用都有其权限设定、访问方式和流量控制。如果没有一个合适的网关，开发者将面临如下问题：

 

• 开发的服务不能以网关的形式提供，访问路径难以管理。

• 开发的服务接口不够安全，需要做相应的鉴权。

• 开发的服务接口不能够控制流量，无法合理利用资源。

 

借助安全网关解决方案，开发者可以大大降低多服务管理成本，避免多服务管理的各种隐患。

 

 

Kong由Mashape开发，并于2015年开源，是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的API网关框架。导入Kong以后，应用系统只需要专注自己的业务实现，缓存、日志记录、认证、授权等均由Kong实现。

 

 

Kong不仅功能强大，还能通过Konga来实现大家想要的UI界面管理工具。

 

 

Konga可以让大家方便的通过人机界面查看当前Kong的所有配置，并对其管理的节点进行查看、监控和预警。

 

Konga的主要特性：

• 多用户管理

• 管理多个Kong节点

• 电子邮件异常信息通知

• 管理所有Kong Admin API

• 轻松的数据库集成（MySQL，postgresSQL，MongoDB）

 

百度AI+安全网关 解决方案简介

 

在介绍完整的深度学习部署网关方案之前，先介绍一下这次我们用来作服务化部署的主要工具─ Paddle Serving。Paddle Serving是百度飞桨针对企业级服务化部署推出的推理框架， 旨在帮助深度学习开发者轻易部署在线预测服务。目标是当用户使用百度飞桨训练出了一个神经网络模型，就能使用该模型做预测服务(Model as a Service)。Paddle Serving的主要亮点如下：

 

• 与百度飞桨训练紧密连接，绝大部分飞桨模型可以 一键部署

• 支持 工业级的服务能力，例如模型管理，在线加载，在线A/B测试等

• 支持客户端和服务端之间高并发和高效通信

• 支持多种编程语言开发客户端，例如C++, Python和Java等

 

而以Paddle Serving为核心, 结合上述介绍的Kong安全网关及Konga网关管理人机界面(GUI)，我们完成了一个完整的服务化网关，系统架构图如下所示：

 

 

手把手搭建实操

 

为了方便演示，我们在这里使用docker-compose来部署安全网关。这个示例的步骤就是 [部署本地Serving容器] – [部署本地安全网关] – [通过安全网关访问Serving]

 

注明：docker-compose与docker不一样，它依赖于docker，一次可以部署多个docker容器，可以类比于本地版的kubenetes，docker-compose的教程请参考docker-compose安装。

 

docker-compose -f tools/auth/auth-serving-docker.yaml up -d

我们可以通过 docker ps 来查看启动的容器。

Docker ID	Image	Port
97c5af96b29e	pantsel/konga:next	0.0.0.0:8005->1337/tcp
01c6af7c6975	registry.baidubce.com/serving_gateway/kong:paddle
bf98bad4a6f6	registry.baidubce.com/serving_gateway/kong:paddle	0.0.0.0:8000->8000/tcp, 127.0.0.1:8001->8001/tcp, 0.0.0.0:8443->8443/tcp, 127.0.0.1:8444->8444/tcp
6643e5925ed1	a2f5ee07c4ac
08c11014a31c	a5a6f28a058f
6db264c231a0	registry.baidubce.com/cce-public/pause:3.1
750be31a8b7f	registry.baidubce.com/serving_dev/serving-runtime:cpu-py36	0.0.0.0:9393->9393/tcp

 

其中serving容器之前是以9393为端口，Kong网关的端口是8443， Kong的Web控制台的端口是8001。接下来我们在浏览器访问 https://$IP_ADDR:8001, 其中 IP_ADDR就是宿主机的IP。

 

 

注册结束后，登录KONGA，可以在左侧 DASHBOARD下面找到SERVICES并点击，然后可以看到serving_service，这意味着我们端口在9393的Serving服务已经在Kong当中被注册。

 

 

然后在ROUTES中，我们可以看到 serving 被链接到了 /serving-uci。

 

 

最后我们点击 CONSUMERS – default_user – Credentials – API KEYS ，我们可以在 Api Keys 下看到很多key。

 

 

接下来可以通过curl访问这个预测服务。

curl -H "Content-Type:application/json" -H "X-INSTANCE-ID:kong_ins" -H "apikey:hP6v25BQVS5CcS1nqKpxdrFkUxze9JWD" -X POST -d '{"feed":[{"x": [0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332]}], "fetch":["price"]}' https://127.0.0.1:8443/serving-uci/uci/prediction -k

 

我们通过命令可以看到这条访问请求已经具备了如下特征，并且这些特征是Paddle Serving安全能力的重要保障。

 

• 使用https加密访问取代传统的http

• 使用serving_uci的路径映射到网关，隐藏了原始的服务路径

• 在header处增加了 X-INSTANCE-ID和apikey，提供了鉴权能力

 

以上操作都可以通过Docker环境来完成。如果您有兴趣进一步在Kubernetes集群上完成更虚拟化的工业级部署，可以参考我们Github的完整教学：

https://github.com/PaddlePaddle/Serving/blob/v0.6.0/doc/SERVING_AUTH_DOCKER.md#k8s%E9%83%A8%E7%BD%B2

 

推荐阅读：

百度世界2021：百度大脑升级、昆仑芯2量产、智能云加速AI落地爆发