干货 | API 网关在平安城市解决方案中的应用

Posted 2021-04-21 华为开发者社区

上学的时候，语文老师都会要求我们做句子的分析，说白了，就是将一个句子中标出基本成分（主语、谓语、宾语）和次要成分（状语、补语）。这样的分析，能方便大家快速准确地理解一个句子的意思。用这个方法分析下本文的标题，不难得出，本文需要搞清楚 3 个问题：1、华为平安城市解决方案长什么样； 2、什么是 API 网关；3、这两者之间怎么就扯上了关系了呢。

华为平安城市

解决方案

先从我们的主线第 1 个问题说起，平安城市解决方案在华为是怎么定义的。

面对当前全球日益复杂的社会治安形势和暴力恐怖事件，防恐、反恐、治安被各国政府提到前所未有的高度。以前生活在太平盛世、安定祥和的西欧国家的人们，最近几年也频繁遭受暴力恐怖事件，比如去年 7 月法国的南部城市尼斯卡车冲撞人群事件（造成至少 75 人死亡，数百人受伤），去年 3 月比利时首都布鲁塞尔机场和地铁站发生系列爆炸事件（造成 34 人死亡，超过 170 人受伤）等等，这些事情哪件不是令人谈虎色变，然而这些事情是可以提前预防的。平安城市解决方案的出现就是要跟这些暴力恐怖事件“Say No”的。华为作为一个维护世界和平的使者（看到了百亿级美刀的商机），需要协助各国政府，打造一个平安城市的解决方案来解决这些难题，造福全球人们。

不多说，且看华为平安城市解决方案的架构和系统组成全景图。

华为平安城市解决方案逻辑架构

（注：上图中橘色底色部分为 ISV 的应用）

解决方案华为产品全家福

从上图可以看出，平安城市解决方案涵盖了华为大多数产品线（如云核心网的 ICP、IoT、IVS，IT 产品线的云计算、大数据等，无线产品线的 eLTE、网络产品线的敏捷网关、各种 IP 设备等等），是一个真正的整合公司各个水平产品线的垂直解决方案。

说了这么多，对于不了解平安城市的同学来说，可能还是不太清楚解决方案能提供哪些能力，且看下图分解。

上图中的 ICP 是 Integrated Communication Platform，集成通信平台的简称，是专门为交付平安城市解决方案而成立的。

从上图可以清晰看出，平安城市解决方案分为 3 个组成部分：

• 左上角是应急指挥中心，在平安城市中成为接处警中心，主要使用角色为调度坐席和应急指挥官，处理的应用场景如下：

• 左下角为各种 IoT 传感设备和视频监控摄像头，同时包含报警人通过多种渠道的报警。这一部分主要为接处警指挥中心上报警情数据。

• 右边为警察处理各种突发事件的场景，通过 eLTE、窄带集群等终端跟指挥中心通信。

什么是 API 网关？

介绍了这么多，相信对于那些不太了解平安城市的同学对这个解决方案也有了一个初步的认识了。现在开始回答本文一开始提出的第 2 个问题：“什么是 API 网关”。

说到 API 网关，不得不提现在火的不行的“微服务”。提起微服务，我们又要从传统的 Web 开发方式说起。我们以一个当前很火的电商 App 开发为例，传统的开发模式是将所有的功能打包在一个 WAR 包里，基本没有外部依赖（除了容器），部署在一个 J2EE 容器(Tomcat、JBoss、WebLogic)里，包含了 DO/DAO、Service、UI 等所有逻辑。

这种开发模式比较适合小项目，优点是：

• 开发简单直接，集中式管理

• 基本不会重复开发

• 功能都在本地，没有分布式的管理开销和调用开销

它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；

• 代码维护难：代码功能耦合在一起，新人不知道何从下手；

• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；

• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉；

• 扩展性不够：无法满足高并发情况下的业务需求。

所以，现在主流的设计一般会采用 Microservice Architecture，就是基于微服务的架构。简单来说， 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

微服务的具体特征:

• 一些独立的服务共同组成系统

• 单独部署，跑在自己的进程里

• 每个服务为独立的业务开发

• 分布式的管理

其实每个人对微服务都可以有自己的理解，不过大概的标准还是有一些的。

• 分布式服务组成的系统

• 按照业务而不是技术来划分组织

• 做有生命的产品而不是项目

• Smart endpoints and dumb pipes（强服务个体和弱通信）

• 自动化运维(DevOps)

• 容错

• 快速演化

传统方式的开发，所有的服务都是本地的，UI 可以直接调用，现在按功能拆分成独立的服务，一般跑在独立的虚拟机上的 Java 进程。客户端 UI 如何访问它呢？后台有 N 个服务，前台就需要记住和管理 N 个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N 个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理(OAuth)。

所以，一般在后台 N 个服务和 UI 之间一般会有一个代理或者叫 API Gateway（说了这么久，我们的主角终于登场了），它的作用包括：

• 提供统一服务入口，让微服务对前台透明

• 聚合后台的服务，节省流量，提升性能

• 提供安全，过滤，流控等 API 管理功能

我的理解其实这个 API Gateway 可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的 MVC 框架，甚至是一个 Node.js 的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过 API Gateway 也有可能成为单点故障点或者性能的瓶颈。

一般用过 Taobao Open Platform 的就能很容易的体会，TAO 就是这个 API Gateway。

说了这么多，大家是不是越来越困惑了，平安城市解决方案跟 API 网关好像就是两个世界的人，八竿子扯不到一块的。不急，我们先从华为当前交付的平台城市架构说起（对了，不得不提一下，本文一开始介绍的平安城市解决方案的架构图是目标架构图，是在 ICP 产品线成立之后才考虑统一平台和架构的）。实际上华为现在交付的平安城市架构是这样子滴。

大家看这个图是不是似曾相识呢，没错，就是刚介绍微服务和 API 网关时举的例子提到的，如果不太记得了，大家可以再翻上去对比看看。我们可以将上图中的各个产品看作是一个“微服务”，按当前的烟囱式的架构，ISV 的应用需要跟各个产品对接，更为糟糕的是，每个产品提供的鉴权方式不一样，提供的接口协议也不一样，由于涉及到的产品又特别多，ISV 在集成过程中叫苦不迭。同时，对于一些非功能性的公共服务，比如安全、告警、流控，每个产品都提供自己的一套，ISV 管理起来非常麻烦，而且非常容易出错。

说到这里，大家是不是会很自然的联想到上面介绍的 API 网关了？对，API 网关的出现就是要来解决这些问题的（其实我在一开始就埋了一个伏笔，细心的读者可能会发现，就是一开始介绍平安城市解决方案架构图的时候，图中靠上最接近 ISV 应用的那一层“统一能力开放平台”指的就是 API 网关）。

从上图可以清晰的看出，ISV 在开发应用时，只需要面对一个网元，也就是 API 网关，他们不再需要关注华为各个子产品的实现细节。

API 网关作为平安城市解决方案能力开放的统一出口，提供了统一的 RESTful 接口（控制面），ISV 只需要关注能力，不需要关注华为的产品（比如只需要关注接警的能力，而不要再关注华为产品 IPCC；只需要关注视频融合会商的能力，而不用再去关注 eLTE、IVS 和 TP 之间的联系和差异）。

由于 RESTful 是基于 HTTP 协议的，对开发平台不敏感，通过开放服务端 RESTful 接口，还可以适配 ISV 多样化的操作系统和开发语言，提高了对接的灵活性。实现统一鉴权，避免平安城市里面各个角色在调用华为不同产品时，输入不同规则的账号和密码，再提升效率的同时，还增强了体验。通过网关的编排能力，实现业务的编排，可以将平安城市中复杂的业务场景编排提炼成为几个简单易用的 API 从网关开放出去，真正对 ISV 实现“一关在手，万事无忧”。

周超

华为 2012 实验室

 eSDK 开发部工程师

作者简介：

从事过开发、支持和设计等工作。多年企业通信开放性领域开发、设计经验，熟知企业客户针对企业通信的解决方案和对通信平台的诉求。现主要对口华为公司公共安全行业领域的二次开发支持，对平安城市解决方案有深入的了解。同时，熟练掌握底层嵌入式软件的开发，对物联网领域也有一些认知，希望和开发者一起交流沟通。

点这，“ 利用华为开放能力 构建平安城市解决方案  ”。