平安城市运维管理软件架构

1. 平安城市运维管理挑战

平安城市是一个由各式软硬件组成的复杂网络系统，视频业务是其核心业务。在平安城市网络中部署着众多视频图像信息采集、传输、处理设备和应用软件系统。这些设备与应用软件系统在满足治安管理、城市管理、交通管理、应急指挥等多样化需求的同时，也对运维管理提出了新的要求与挑战。
平安城市的运维管理所面对的挑战如图1所示。
平安城市运维管理软件架构

针对平安城市的运维管理挑战，平安城市运维管理系统(以下简称运维管理系统)的功能和范围定义如图2所示。
平安城市运维管理软件架构

不同于电信网络、计算机网络的运维管理系统，平安城市的运维管理系统所管理的管理单元更为多样化与复杂化，在功能上聚焦为用户提供多层次价值。
图3以苏州科达建设的一个典型平安城市项目为例，描述了运维管理系统与平安城市中各类管理单元间的关系。
平安城市运维管理软件架构

2. 平安城市运维管理思路

我们将运维管理系统涉及到的管理单元分为两类：一类为设备，包含通用设备、视频图像信息采集设备等设备；一类为应用软件系统，包括视频图像信息应用系统、视频监控平台、视图库等软件系统。
对于设备的运维管理，可充分参考电信等工程领域的运维管理标准和实践，本文不再赘述。
对于应用软件系统的运维管理，是一个新课题，面临的主要问题有以下三点：
1. 平安城市项目建设周期较长，持续采购的应用软件由不同厂家提供，差异性较大：不只在技术架构上存在较大差异（如有的软件是单体（monothetic）设计，有的软件是面向服务的设计），对外提供的接口也具有较大差异（缺乏相应的标准约束是主要原因）。
2. 平安城市中的应用软件系统能够提供用户关注的价值（如数据采集、统计、分析等），这些价值需要在运维管理系统中体现，提供更良好的用户体验。
3. 避免“重复造轮子”，对于平安城市中的应用软件系统已经提供的诊断测试、统计分析等功能，运维管理系统应尽量引用这些功能，而不是重新开发。

3. 平安城市运维管理架构

3.1. 逻辑结构

针对应用软件系统运维管理面临的挑战，我们首先将应用软件系统做逻辑上的抽象：
将应用软件系统抽象为软件服务的容器，表示为S={ð}：S表示为一个应用软件系统， ð表示软件系统S能够提供的软件服务。
将软件服务ð抽象定义为三元组，则ð=(o,d,i) :其中o表示该软件服务提供的操作；d表示该软件服务提供的数据；i表示该软件服务提供的交互接口。
经过上述逻辑抽象，应用软件系统的运维管理转换为运维管理系统对每个ð的管理。
根据图2的功能范围定义及平安城市建设中的实践经验，我们将ð归纳为以下几类服务：

远程诊断、测试操作服务：平安城市中的应用软件系统，有些是独立的设备管理系统，能够提供一系列针对设备的远程诊断、远程测试功能，将这些功能抽取出来、包装为软件服务提供给运维管理系统，便于用户在运维管理系统中实施一站式对多种类型设备的远程诊断、测试操作功能。

数据统计展示服务：平安城市中的应用软件系统，有些提供完整的数据统计，挖掘，展示功能(如常用的报表系统)。这些饱含分析价值的数据图表可抽取出来作为数据展示服务提供给运维管理系统。便于用户在运维管理系统中方便地在各类数据报表间切换。

数据导出服务：平安城市中的应用软件系统，有些包含数据仓库。构建数据导出服务将这些数据仓库中的数据导出到运维管理系统，便于用户在运维管理系统中对于多领域的数据进行综合分析。
除上述三类主要服务外，还有一些通用软件服务，如系统状态、异常信息上报，服务治理等。这些通用软件服务的管理可参考微服务架构系统的运维管理思路，本文不作深入探讨。

3.2. 软件架构

为便于描述，本文约定涉及的软件系统均为B/S架构。
平安城市中存在着大量已服役多年的应用软件系统，运维管理系统需要的软件服务依赖于这些遗留的应用软件系统。很显然，通过对遗留应用软件系统进行大幅改造来提供软件服务的方法不可取。遵循软件设计的“开-闭”原则，对于这些应用软件系统，我们将系统可提供给运维管理系统的软件服务进行抽取、包装，增加Microgateway (微网关)作为应用软件系统与运维管理系统之间的桥梁（有没有一瞬间让你想到电信网管的北向接口），为运维管理系统提供软件服务，平安城市运维管理的整体软件架构如图4所示。
平安城市运维管理软件架构
图4的架构是一个典型的类微服务架构（portal好比apigateway,运维管理系统和各应用软件系统好比各微服务，其它一些部件(如服务注册)被省略），根据图4，我们梳理一下用户的操作流程：
1. 用户通过平安城市的portal进入门户页面，向平安城市中的统一授权服务器（authorization server）使用SSO(单点)登录进行身份验证，并获取访问令牌(access token)。
2. 用户从门户页面跳转到运维管理系统，重定向请求中携带访问令牌。
3. 运维管理系统验证访问令牌确定用户身份，返回操作页面。
4. 用户在运维管理系统中消费目的应用软件系统软件服务。操作请求中携带访问令牌，被发送到目的应用软件系统对应的Microgateway。
5. Microgateway验证访问令牌确定用户身份，根据请求选择对应的服务路由，调用目的应用软件系统的相应服务，并将调用结果返回给运维管理系统。

3.2.1. 关于系统安全

系统安全是软件设计中永恒的话题。在平安城市中，我们设计了统一的授权服务器，如果平安城市中已建设好PKI（Public Key Infrastructure），授权服务器应充分利用已有的PKI，同时作为一个SSO服务器，支持OAuth3协议，用户可从portal,运维管理系统和其它应用软件系统中任意一个系统登录进行验证，并获取授权服务器颁布的访问令牌，访问令牌建议使用JWT(Java Web Token)格式，用于在系统的各个服务之间调用时验证身份。
如果JWT使用了签名方式，如使用的是“RS256”这样的PKI签名方式，平安城市中的各个系统(服务)需要向统一授权服务器申请用于验证签名的公钥证书。
需要注意的是，JWT是有期限的，对于JWT过期的情况，各系统(服务)需要重新申请。
对于系统资源的访问控制，如果已有建设好的PMI（Privilege Management Infrastructure），应优先使用已有的PMI用于访问控制，当使用JWT表示身份验证结果时，可在JWT的payload中携带PMI属性证书中的部分内容（如用户所属群组与所属角色），这样做法的好处是将待实施访问控制系统去PMI平台获取用户属性证书的过程省略了，提升了效率，但如果系统中用户的群组和角色变换频繁，则不宜使用这种方式。如果没有可用的PMI，各系统需要自建自身的访问控制体系，对于携带访问令牌的访问请求，各系统可利用自身建设的访问控制体系识别用户身份进行访问控制。
从系统一致性的角度，我还是强烈建议在平安城市中建立统一的PKI/PMI体系，达到统一认证、授权、鉴权的目标，提供完美的用户体验。

3.2.2. 关于Microgateway

Microgateway的定义了解一下，美国CA公司对于Microgateway的定义如下：
CA Microgateway is a lightweight, containerized gateway, designed to scale within highly decentralized environments. It supports common microservices patterns by providing service-discovery, routing, rate-limiting and last-mile security, and is easily deployable and configurable by developers at design time using provided policy templates.
由定义可以看到，Microgateway可视为一个局部gateway,用于解决“最后一公里”的问题。Microgateway又提供灵活可配置的模板供用户在设计时使用，用户可在运行时通过修改模板的配置数据使得Microgateway不需要修改代码及重新编译部署就能实现新的功能。
平安城市中应用软件由不同厂家提供，应用软件的更新升级可能导致提供的接口也发生变化，如果运维管理系统针对每次应用软件的升级更新导致的接口变更都做修改的话，那么工作量是巨大的。Microgateway可以通过灵活可配的策略模板来将这种变化封装在Microgateway内。
如针对应用软件系统的数据库，Microgateway对运维管理系统提供Restful的查询接口，查询应用软件系统的数据库对应数据。可在Microgateway中编写数据库查询模板，在模板配置文件中设置待查询的数据库表、字段以及Restful接口的URI以及返回数据格式。当运维管理系统需要增加查询接口时，只需要在模板配置文件中增加对应条目即可；当应用系统的数据库发生变化时（如表字段发生变化时），修改模板配置文件中对应字段即可。模板配置文件使得运维管理系统不感知所管理应用软件系统的接口变化。
针对应用软件系统的HTTP接口，Microgateway同样可编写路由模板，在模板配置文件中设置HTTP请求的路由规则，将来自运维管理系统的请求根据路由规则路由到应用软件系统提供的软件服务(是不是有点像spring cloud的zuul)。
需要注意的是，Microgateway并非silverbullet，Microgateway所实现的柔性扩展也是基于约束的，这个约束用于指导模板的设计。

4. 示例DEMO

本节介绍一个示例DEMO，模拟演示第3节提到的运维管理架构。该DEMO的代码存放位置为：https://github.com/solarkai/IomsSimu/ 。该示例中没有涉及系统安全(以后考虑补上)。
此DEMO中，分别模拟了一个运维管理系统、一个交通管控平台中的报表服务和一个针对该报表服务的Microgateway。
模拟交通管控平台中的报表服务使用spring-boot框架编写，提供了一个Restful接口提供简单的报表数据（数据格式为JSON格式）。
报表服务的Microgateway使用Node.js和Express框架编写，使用“http-proxy-middleware”中间件定义了一个HTTP路由模板，处理来自运维管理系统的操作请求。路由模板的配置文件由gateway.json文件定义，内容示例如下：

{
"gatewayList": [
{
  "path": "/chart1",
  "method": "get",
  "proxy": {
    "target": "http://127.0.0.1:8082",
    "pathRewrite": {
      "^/reports/chart1": "/loadChart1"
    }
  }
}
]
}

Microgateway提供一个报表展示页面，数据来自于模拟交通管控平台中的报表服务。图5是报表展示页面。
平安城市运维管理软件架构
模拟运维管理系统使用Node.js和Express框架编写，该运维管理模块的模拟运维管理系统的应用软件系统管理界面是长这样的。

在模拟运维管理系统，可配置Microgateway提供的软件服务信息，并消费这些软件服务。图7显示了对Microgateway提供的报表服务的消费。
平安城市运维管理软件架构