电信计费业务：预后融合消息计费

现在离线计费系统(OFCS)和在线计费系统(OCS)的主要差异之一就是OFCS采用文件计费，OCS采用消息计费，提预后融合，也一直在提OFCS需要提供消息计费的能力。然而，文件系统和消息计费，实际只是各个模块之间接口协议的不同，流程并不应该因此产生差异。也就是说，具备消息计费的能力这句话，不是仅仅把话单转为消息然后计费即可，而应该理解为，文件计费与消息计费流程上的统一。

虽然消息计费相对于文件计费，存在一些优势，但是也存在一些劣势。明显的优势和劣势因为计费的粒度不同而引发。消息是粒度更加细的，文件计费的数据源是文件，一个文件包含了N条话单，而消息计费的数据源是消息，一条消息只有一条话单（又没人给稿费，我写这么多废话干嘛….）。粒度更细，代表了在做计费任务分配和任务跟踪时，粒度更细，也更加方便，比如负载均衡，资源分配等，劣势其实也很明显。更细粒度的任务分配和跟踪意味着效率的下降，也意味着管理更加困难。

但是这些不是是文件计费还是消息计费的根本原因。这个问题上，我觉得流程才是重点。这里面有两个重点，第一是统一流程，第二是做到业务组件化。

不管是流程统一上还是业务组件化上，消息计费都有很大的优势。首先流程统一这个层面上，文件计费不得不向消息计费过度，如果要满足在线计费的需求，文件粒度计费的实时性是无法保证的。而离线计费话单转成消息后，基本是可以满足需求的。

业务组件化这个层面上也存在优势。业务组件化需要对业务组件的输入和输出的抽象，这里面有一个关键就是接口协议的标准化，这个方面，消息计费比文件计费更加强大。在线计费系统的DCC消息的协议，是3GPP的标准之一，有成熟的字段定义，相对于文件类的，标准更加统一，也更加贴近与计费本身。这句话的意思其实是，消息的格式，基本定义好了，考虑的也比较全面，文件的格式，都要自己定义，难免有这种那种考虑不周的地方。

这里面引发的争论是：既然流程统一了，何必再组件化？业务组件其实是统一流程的基础，统一实际就是一种变化，如果做到了业务组件化，流程是可配置的，变化起来就会变得简单。就拿文件计费和消息计费来说，文件计费是先合帐、入库，再扣减余额，消息计费是先扣减余额，再合帐，入库。如果扣减余额、合帐、入库这三个子流程，其接口已经抽象成文件计费和消息计费可用，那流程统一就不是什么难事。

可能还会问：还既然业务组件化了，那预付和后付计费流程自然可以随便组合，为啥还要统一？所谓预后融合，首先应该是在线计费系统和离线计费系统对套餐支撑能力，对用户服务能力的统一，流程统一自然是前提。业务层面的抽象才是最好的抽象。

所以两者并不矛盾，这里面其实折射的是维护者和研发者看问题角度的不同，对于维护角度出发，自然希望流程是统一的，最好就是输入一条话单，输出一个结果，中间没有那么乱七八糟的过程，因为我们的需求复杂，这个想法未免天真。虽然说研发也希望这样，但是研发考虑问题要长远一点，想把流程切成一段段的，做一些抽象，做成业务组件。修改也只在一段做出修改，甚至有啥新需求拿一段就可以用，这个想法有时候会过度，维护起来就非常不方便。

扯远点，想起一个笑话，说有人要过河，写shell的那根绳子游泳把那个人拖过去了，VB砍了点木头搞了艘船把人运过去了，PB搞了很多木头架了坐桥把人运过去了，VC拿来了钢筋和水泥…..把业务组件抽象到什么程度，其实归根结底还是在于业务需求到底是什么样子的，具体要怎么做，就要看有多少人不想摸着石头过河了。

装X了好久，太累了。以后想清楚了再扯这个问题。