电信级Inventory系统的NoSQL实现（未完成）

之前一直是从事通信行业OSS系统的设计和实现。
电信OSS领域有两个至关重要的系统Inventory， Service Desk，这两个系统可以看成是整个OSS业务中的两个数据泵，是整个OSS Solution集成的枢纽。
Service Desk是作为人机交互的request数据(来自business或者trouble)的流转枢纽。
而Inventory则作用更偏向于solution-solution集成的枢纽。
不同厂商的Solution或者同一厂商的不同业务域软件，都会在这两个软件节点上做集成。
在各种OSS架构图中可以很容易发现，这两个系统通常都会位于整个星形结构的中心部位。
因此可以说，这两个系统的设计实现水平和实施水平，会直接最大程度影响整个OSS的实施质量和管理难度，这两个系统也是最容易为公司整个OSS产品线打下大单的核心系统，掌握了这两个系统，就掌握了整个OSS集成的主动权
不管是基于ITIL还是eTom模型划分，这两个系统都会贯穿整个分层模型中的没个部分都要和其中至少1个打交道

 

电信Inventory系统由于涉及不同业务领域，各个领域需求与模型差异又很大。比如传输和无线，这两个领域规范模型和业务关注点就大相径庭。但抽象来说，各种Inventory系统最后都会集中在几个方面上：

1.层级关系

2.物理关系，主要指网元与网元间的连接拓扑关系，这里还不涉及真实的物理位置

3.Service到resource的承载关系

3.地理关系甚至包括更细化的物理位置信息

 

其中获得层级关系相对是最容易实现，如果设备提供了标准化的北向接口，则很容易通过这些接口从EMS获取这些数据，再通过ID层次建立各个领域的设备层级关系。如果没有北向接口，则可能要通过文件ftp或者数据库同步的方式从要管理的设备中抽取设备信息和层次结构。通常情况取得层次结构的设备id已经足以构建出网元设备的从属结构。

 

物理关系相对就复杂很多，不同的业务solution对这个物理关系理解的深度和广度差异会很大。

以无线资源网管为例，它关心的物理关系大多只是网元到网元层次的物理连接，除了在无线和核心交接处的网元连接会呈现小规模网状连接，其他多数情况是星形(也可以说是树形)连接层次。

在传输网中物理关系则会涉及高阶低阶的复用承载关系，自愈环是否闭合这些更复杂的网状拓扑信息，这种网络是多层次的大规模网状结构。

传输网的invenroty采集和拓扑分析往往是电信网invenroty系统比较核心的也比较复杂的部分，它的难点在于整合集成不同厂商北向接口和复杂的拓扑关系计算上。