• 网管接口重构(2014年)


    一. 重构方向

    以前的网管的使用对象, 默认为开发人员, 关注设备的内部实现, 新网管要改成最终客户, 站在客户角度关注业务.

    因为项目时间/人力资源/沟通条件/共识程度/重构风险, 所以需要选取重构重点, 本次重构不重点关注的并不是重要性低.

    易懂: 使用客户的语言

    网管的重构如果去不掉”调试工具”的包袱, 网管对客户而言还是无法做到易懂, 本次重构重点关注

     

    易用: 提高操作效率

    要做到易用, 和其他设备没有直接关系, 本次重构关注重点

     

    统一: 查看全局, 配置全局

    网管的重构如果做不到面向”全局的资源和业务”, 网管对客户而言还是无法做到统一; 本次重构只关注网管内部的整合, 不关注跨设备的整合

     

    强大: 透视客户需求, 设计优质方案

    要做到强大, 很多时候需要其他设备开发人员的配合, 提供更多的接口; 本次重构不关注

     

    . 设备交互重构方案

    交换机集权

    背景: 交换采用LINUX, 具备了数据存储能力.

     

    经过上次初步的讨论, 我的理解如下, 新网管只处理人机交互, 逻辑上, 新网管只是一个网管终端; 新交换机代理网管与其他设备的交互以及网管的数据存储, 逻辑上, 新交换机集成了网管服务器的功能, 新交换机和系统其他设备不再需要从新网管加载数据, 系统其他设备也不和新网管连接.

     

    优点: 减少了设备间依赖, 减少了设备间交互流程, 保持数据一致性更容易.

    缺点: 加大了新交换机的职责, 对新交换机的设计要求较高. 原先是网管代理了交换机和其他设备的数据存储和调试工具, 客户上导致了网管难用, 对设备的接口频繁变动; 现在是交换机集成了网管服务器, 对新网管和交换机之间的职责划分和接口理解, 可能也需要经过一番洗脑才能提高; 对交换机内模块的职责划分和接口定义, 随着交换机责任的增加, 能力要求也随之提高, 责任少的时候, 设计差点, 修修补补也能实现, 责任多的时候, 不提升设计,修修补补的工作量可能是Z = A*B*C(高耦合)的增长.

     

    分离应用服务

    为了系统的扩展性和稳定性, 可以将原网管的告警/话单独立成应用服务. 话单和录音合并或关联, 这样一来, 关闭新网管对系统没有任何影响.

     

    传输方式

    网管与交换的传输使用TCP, 能保障在网络差的情况下数据传输的可靠性, 不需要自定义事务层, 整体上比使用UDP+自定义的事务层简单可靠.

     

    网管与其他应用服务器(如话单服务器)之间的传输, 因为会话简单(无状态), 可以考虑采用短连接”/”服务性质的基于HTTP传输json/XML方式(WebService也可以, 基于现状, 不推荐), 既能保障一定的通用性和低耦合, 实现也较容易(因为无需关注传输层).

     

    报文格式

    之前的报文头的设计很复杂, 没必要/不利于调试/不够通用, 理论上报文头只需要功能码(功能标识)+报文内容长度两个字段就够了, 为了容错可以加上报文头识别码, 为了保障严谨完善的设备”会话”, 可以加上”发送方事务标识”和”接收方事务标识”, 为了保障安全性可以加上”注册标识”.

    字段

    类型

    长度(字节)

    说明

    起始标识

    Int16

    2

    固定为0xAAAA,用于识别报文开始

    报文内容长度

    Int16

    2

    余下所有字段长度,范围0-1000字节

    功能标识

    Int16

    2

    用于识别报文类型

    注册标识

    Int32

    4

    类似于动态密码,客户端注册成功后获得,特别的,客户端注册与服务器端响应注册时填0xFFFFFFFF

    发送方事务标识

    Int32

    4

    由发送方指定。当会话类型为请求型时,用于区别发送方的不同请求;当会话类型为通知型时,固定为0

    接收方事务标识

    Int32

    4

    由接收方指定。当会话类型为请求型时,用于区别接收方的不同请求,特别的,会话开始的第一条报文,发送方的该字段填0;当会话类型为通知型时,固定为0

     

    报文内容还是使用UTF8文本编码(利于调试诊断), 封装格式使用json(更节约)xml, 对象属性推荐使用中文(利于调试诊断).

     

    . 人机交互重构方案

    此次重构能做的是在现有网管基础上, 进行删减和重组, 优化易懂易用性.

    1. 去除合法设备验证, 配到系统中的设备都是合法的, 其他都是非法的.

    2. 设备信息只输入一次, 简化设备间关联配置. 例如交换机IP, 各个基站IP, 只输入一次, 其他用到地方, 使用选择方式; 如果设备间的关联是固定的, 那么就不需要在网管上配. 例如之前向系统一个基站, 添加时还需要输入交换机信息, 添加完还需要在交换机配置上重新输入该基站参数, 还要在相邻基站中重新输入该基站参数, 可以考虑在添加基站时去掉输入交换机信息, 去掉在交换机配置上再次输入基站信息, 在相邻基站配置中选择基站.

    3. 区别告警与设备基本状态, 建立通用协议, 具体讨论可以参见另一份文档.

    4. 去除工程和开发参数配置. 特别是只配一次的. 去掉后, 最直接的访问方法是通过配置文件, 教会测试和工程人员修改就行, 如果配置很多就写一个配置文件的访问工具.

    5. 优化UI. 选用成熟CSS框架, 既能减少bug, 也能增强视觉美观性, 也能增强交互的友好性, 也能适应更多类型浏览器和分辨率.

    6. 离线配置. 优先级最低. 使用保存任务这种离线方案, 有较多的限制, 只能局部的应用.

     

    四. 迭代规划

    先介绍一下概念, 因为要逐步消除风险, 所以需要迭代: 每次迭代都必须生成可以运行的程序, 通过验证可运行程序来获得反馈, 从而消除风险; 每次大的迭代称为阶段或里程碑, 每个阶段或里程碑内又可以包含多个版本.

     

    1 第一阶段: 能呼叫

    集群的基础功能就是呼叫, 所以第一阶段的重构是围绕能进行简单呼叫”.

    可选选择功能:

    设备接入: 交换机/基站/媒体网关/手台

    业务配置: 号码范围/分组方案/通话限时/媒体资源/频率资源/基站关联

    运营状态: 设备基本状态/活动用户/信道监控

    运营数据: 话单/设备连接告警

     

    另一方面, 上述功能也涵盖了网管与交换间通信的主要类型, 包括: 请求型(网管->交换->网管), 通知型(交换->网管), 还有一种通知型(网管->交换)比较简单, 涉及不到没关系.

     





  • 相关阅读:
    【Java多线程】Fork/Join 源码分析(三十一)
    【Java多线程】Fork/Join 框架(三十)
    【Java】 Iterator(迭代器)
    【Java多线程】ScheduledThreadPoolExecutor实现原理(二十九)
    【Java多线程】ScheduledThreadPoolExecutor详解(二十八)
    【Java多线程】Executor框架 (二十七)
    【Python基础编程252 ● 包 ● 使用import 包名 as 别名 语句导包】
    【Python基础编程251 ● 包 ● 使用from 包名 import * 语句导包】
    【Python基础编程250 ● 包 ● 导包的方式】
    【Python基础编程249 ● 包 ● 包的基本概念、作用和命名规则】
  • 原文地址:https://www.cnblogs.com/wangk/p/5731601.html
Copyright © 2020-2023  润新知