网管接口重构（2014年）
一. 重构方向
以前的网管的使用对象, 默认为开发人员, 关注设备的内部实现, 新网管要改成最终客户, 站在客户角度关注业务.
因为项目时间/人力资源/沟通条件/共识程度/重构风险, 所以需要选取重构重点, 本次重构不重点关注的并不是重要性低.
易懂: 使用客户的语言
网管的重构如果去不掉”调试工具”的包袱, 网管对客户而言还是无法做到易懂, 本次重构重点关注
易用: 提高操作效率
要做到易用, 和其他设备没有直接关系, 本次重构关注重点
统一: 查看全局, 配置全局
网管的重构如果做不到面向”全局的资源和业务”, 网管对客户而言还是无法做到统一; 本次重构只关注网管内部的整合, 不关注跨设备的整合
强大: 透视客户需求,
设计优质方案
要做到强大, 很多时候需要其他设备开发人员的配合, 提供更多的接口; 本次重构不关注
二. 设备交互重构方案
交换机集权
背景: 交换采用LINUX, 具备了数据存储能力.
经过上次初步的讨论, 我的理解如下, 新网管只处理人机交互, 逻辑上, 新网管只是一个网管终端; 新交换机代理网管与其他设备的交互以及网管的数据存储, 逻辑上, 新交换机集成了网管服务器的功能, 新交换机和系统其他设备不再需要从新网管加载数据, 系统其他设备也不和新网管连接.
优点: 减少了设备间依赖, 减少了设备间交互流程, 保持数据一致性更容易.
缺点: 加大了新交换机的职责, 对新交换机的设计要求较高. 原先是网管代理了交换机和其他设备的数据存储和调试工具, 客户上导致了网管难用, 对设备的接口频繁变动; 现在是交换机集成了网管服务器, 对新网管和交换机之间的职责划分和接口理解, 可能也需要经过一番洗脑才能提高; 对交换机内模块的职责划分和接口定义, 随着交换机责任的增加, 能力要求也随之提高, 责任少的时候,
设计差点, 修修补补也能实现, 责任多的时候, 不提升设计,修修补补的工作量可能是Z = A*B*C(高耦合)的增长.
分离应用服务
为了系统的扩展性和稳定性, 可以将原网管的告警/话单独立成应用服务. 话单和录音合并或关联, 这样一来, 关闭新网管对系统没有任何影响.
传输方式
网管与交换的传输使用TCP, 能保障在网络差的情况下数据传输的可靠性, 不需要自定义事务层, 整体上比使用UDP+自定义的事务层简单可靠.
网管与其他应用服务器(如话单服务器)之间的传输, 因为会话简单(无状态), 可以考虑采用”短连接”/”服务”性质的基于HTTP传输json/XML方式(WebService也可以, 基于现状, 不推荐), 既能保障一定的通用性和低耦合, 实现也较容易(因为无需关注传输层).
报文格式
之前的报文头的设计很复杂, 没必要/不利于调试/不够通用, 理论上报文头只需要功能码(功能标识)+报文内容长度两个字段就够了, 为了容错可以加上报文头识别码, 为了保障严谨完善的设备”会话”, 可以加上”发送方事务标识”和”接收方事务标识”, 为了保障安全性可以加上”注册标识”.
字段 | 类型 | 长度(字节) | 说明 |
起始标识 | Int16 | 2 | 固定为0xAAAA，用于识别报文开始 |
报文内容长度 | Int16 | 2 | 余下所有字段长度， |
功能标识 | Int16 | 2 | 用于识别报文类型 |
|
|
|
|
发送方事务标识 | Int32 | 4 | 由发送方指定。当会话类型为请求型时，用于区别发送方的不同请求；当会话类型为通知型时，固定为0。 |
接收方事务标识 | Int32 | 4 | 由接收方指定。当会话类型为请求型时，用于区别接收方的不同请求，特别的，会话开始的第一条报文，发送方的该字段填0；当会话类型为通知型时，固定为0。 |
报文内容还是使用UTF8文本编码(利于调试诊断), 封装格式使用json(更节约)或xml, 对象属性推荐使用中文(利于调试诊断).
三. 人机交互重构方案
此次重构能做的是在现有网管基础上, 进行删减和重组, 优化易懂易用性.
1. 去除合法设备验证, 配到系统中的设备都是合法的, 其他都是非法的.
2. 设备信息只输入一次, 简化设备间关联配置. 例如交换机IP, 各个基站IP, 只输入一次, 其他用到地方, 使用选择方式; 如果设备间的关联是固定的, 那么就不需要在网管上配. 例如之前向系统一个基站, 添加时还需要输入交换机信息, 添加完还需要在交换机配置上重新输入该基站参数, 还要在相邻基站中重新输入该基站参数, 可以考虑在添加基站时去掉输入交换机信息, 去掉在交换机配置上再次输入基站信息, 在相邻基站配置中选择基站.
3. 区别告警与设备基本状态, 建立通用协议, 具体讨论可以参见另一份文档.
4. 去除工程和开发参数配置. 特别是只配一次的. 去掉后, 最直接的访问方法是通过配置文件, 教会测试和工程人员修改就行, 如果配置很多就写一个配置文件的访问工具.
5. 优化UI. 选用成熟CSS框架, 既能减少bug, 也能增强视觉美观性, 也能增强交互的友好性, 也能适应更多类型浏览器和分辨率.
6. 离线配置. 优先级最低. 使用保存任务这种离线方案, 有较多的限制, 只能局部的应用.
四. 迭代规划
先介绍一下概念, 因为要逐步消除风险, 所以需要迭代: 每次迭代都必须生成可以运行的程序, 通过验证可运行程序来获得反馈, 从而消除风险; 每次大的迭代称为阶段或里程碑, 每个阶段或里程碑内又可以包含多个版本.
1 第一阶段: 能呼叫
集群的基础功能就是呼叫, 所以第一阶段的重构是围绕”能进行简单呼叫”.
可选选择功能:
设备接入: 交换机/基站/媒体网关/手台
业务配置: 号码范围/分组方案/通话限时/媒体资源/频率资源/基站关联
运营状态: 设备基本状态/活动用户/信道监控
运营数据: 话单/设备连接告警
另一方面, 上述功能也涵盖了网管与交换间通信的主要类型, 包括: 请求型(网管->交换->网管), 通知型(交换->网管), 还有一种通知型(网管->交换)比较简单, 涉及不到没关系.
