文/安宁刚

西安交通大学校园网始建于1994年，建立之初至今，一直致力于提升用户服务水平，构建一套完整的用户服务体系。

2007年后，随着数字化校园平台的建成，网络中心基于数字化校园平台构建了用户自服务系统，由于综合业务管理系统构建之初，没有考虑到以后用户服务体系的扩展，因此后面的用户自服务系统很多业务模块代码都必须重写，如果一个业务发生变化，两套系统都要更改代码，造成了巨大的代码维护量。2012年，我们提出了基于SOA架构重新构建校园网用户服务体系，将业务逻辑分层隔离出来，向下调用网络服务及应用系统，向上为业务平台提供服务。基于业务逻辑层之上，我们相继搭建了基于Web的网络用户服务系统、基于语音电话的用户服务系统、基于圈存机、查询机的用户自服务系统、基于移动平台、微信的自服务系统，这些子系统都是调用相同的业务逻辑接口，因此做到了业务逻辑统一，而且不用再为每一套子系统重构业务代码。用户服务平台上线后，用户可以在任何时间、任何地点、通过任何方式完成网络业务的办理，同时这套服务体系满足了不同人群的使用习惯，完全覆盖了所有网络用户。

面向服务的架构

面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

由于校园网络内各种网络业务、应用在服务层面在业务逻辑上都是同构的，比如都有开户、查询、计费、管理、销户等业务逻辑，但是这些网络服务和应用的实现层面上都是异构的，有着不同的硬件平台、操作系统、编程语言，这些服务和应用有的是购买的产品，也有自主开发的，各不相同，要让这服务及应用能够交换数据，采用松耦合的SOA模型是最好的解决办法。

系统的设计与实现

系统的结构设计

校园网用户服务平台的系统架构可以简单分为三层：底层网络业务实现层、中间业务逻辑层、上层业务表现层。底层网络业务实现层是校园网提供的所有网络服务、应用管理接口的具体实现；中间业务逻辑层是实现网络用户服务平台的业务逻辑，中间层只关心业务逻辑，如开通业务、查询业务、管理、销户，而不管这些逻辑在具体的业务中是如何实现的；上层业务表现层是服务平台的具体表现，包括Web、portal、校园门户、圈存机、查询机、语音电话、移动客户端、微信，这些不同的业务入口都向下调用统一、标准的业务逻辑组件。下面详细介绍各层的设计。

底层网络业务实现层：业务实现层主要是要实现平台与底层各个网络服务及应用的接口。网络业务一般可分为3大类，第一类是网络接入，包括静态IP接入、portal认证接入、802.1X认证接入、PPPOE认证接入、无线接入。第二类是网络服务，包括VPN、代理、云桌面、云存储、电子信箱。第三类是应用系统，主要是数字化校园的各个应用系统。每个业务的接口实现没有一个统一标准或规范，主要是根据具体业务的体系结构来设计，这些业务有些是自主开发的，有些是厂商产品，实现的原则是稳定可靠、简单易行、容易维护。在我们的用户服务平台接口实现中，具体用到的有简单网管协议SNMP、远程过程调用RPC、SOAP协议、JSON数据交换、SOCKET通信、厂商提供的第三方接口、数据库直连等等。

中间业务逻辑层。中间业务逻辑层主要是业务逻辑的实现，是整个服务平台的核心。业务逻辑主要有以下要素：用户、策略、模板、计费、开户、管理、销户。每个用户都通过唯一的NETID绑定一个具体的业务，用户的身份决定了开户的时候使用该身份相对应的模板和策略，模板决定了该用户使用这个服务的规格，比如网络带宽、网络流量、使用时段、空间大小等等，这样就可以针对不同的用户群体进行精细化管理，比如对本科生使用网络控制较为严格，研究生较为宽松，甚至可以更精细的根据学习成绩设定模板。策略决定了如何管理该用户的服务，何时何地能使用，何时何地不能使用，同时策略也决定了如何计费。管理主要有状态查询、打开服务、关闭服务、修改服务四种通用的操作，修改服务的操作里通常有修改服务的规格、修改密码。有了业务逻辑层后，就不用每种业务都写一套业务逻辑的代码了，在系统中只需要初始化一个业务，系统会自动生成该业务的所有逻辑，并生成业务所有的数据库表项，然后配置好模板、策略、计费，这个业务就可以运行了，

上层业务表现层。上层业务表现层主要是业务逻辑在服务平台上的不同发布方式，默认的发布方式是Web，我们称为为综合业务管理系统，主要是面向工作人员。其它发布方式有用户自服务平台、基于SIP的语音电话系统、用户自服务系统、校园信息门户、多媒体触摸屏、圈存机、移动客户端、短信、微信。表现层各个系统对业务逻辑的操作，都是调用中间业务逻辑层的接口，不能对底层的具体业务系统进行操作。

业务逻辑的设计

方法：CreatUser创建业务、DropUser删除业务、ModUser修改业务参数、CloseUser停用业务、OpenUser启用业务。每个方法实例化的时候，首先要绑定一个用户的netid，其次要指定具体的业务ID，系统会在接口库里调用该业务注册的接口函数，完成动作。

模板：Template的实现。Template的属性包括业务ID、参数数组，参数数组存储了该业务的规格参数。在创建业务时，如果有模板选项，就将模板里的参数传给接口函数。

策略：策略是一组由定时器定时执行的任务脚本，策略可以调用最基本的方法与接口函数，完成管理、计费的动作。比如检查到用户的费用到期，就要执行CloseUser的动作关闭用户的业务，检查到交费的动作，就要执行OpenUser的动作启用业务。

安全方面设计

1.中间业务逻辑层与底层业务实现层之间的安全设置，基本上结合接口的实现，各自做一些安全防护，比如业务系统之间秘钥通讯，设置IP访问限制。

2. 中间业务逻辑层与上层业务表现层之间有防火墙保护，防止非法调用，并且记录了所有的访问日志。

3.权限控制。每个业务表现层的应用都在权限表里有一条数据，只有权限表里授权才能调用业务逻辑。

图1 校园网用户服务平台结构设计

系统的实际运行效果

在校园网用户服务平台建立之前，所有的网络业务都是孤立的，每一个网络业务都有一套独立的用户管理系统和独立的用户数据库，各个业务系统之间的用户没有关联，用户在网络中心办理业务的时候，工作人员需要在多个业务组件之间来回切换，多次操作，如果要变更业务，需要更新多个业务的数据，比如用户地址、联系方式。服务平台建立之后，各个网络业务不再各自维护一套用户数据，而是通过统一数据交换平台获取用户数据，只要知道用户的NETID或学工号，管理员就可以在用户服务平台上完成有关该用户的所有查询、业务办理的操作，用户也可通过统一身份认证登录自服务系统或校园信息门户，查询或办理名下所有的网络业务。

在搭建用户服务平台之前，用户服务工作及业务办理主要集中在网络中心现场办理以及服务热线，高峰期排长队，电话打不进来，用户体验很差。搭建用户服务平台之后，用户可以自主选择最习惯的方式办理业务，95%以上的业务办理被分散到网络、圈存机、触摸屏终端、移动终端上，大大减轻了现场办理业务的压力和服务电话的压力，用户免去了排队等待和办理业务的时间限制。

问题和体验

服务平台业务层是整个服务平台的核心，一旦出现故障，就会造成所有业务办理中断，因此业务层采用了双机热备，能够确保业务不中断。上层由于是相互冗余的，所以一种途径出现故障影响不大。底层交互采用了同步、异步两种模式，如果一个业务调用出现错误，系统会放入队列再次尝试，直到成功。这样就确保了底层出现故障，不影响业务办理。

用户服务平台的后期的维护和开发，主要在与各个业务系统的接口上面。如果一个业务发生变化，就有可能需要修改业务接口。因此在购买、升级产品之前，需要与厂商沟通，先做好接口的测试工作，选择一个简单、稳定的接口方式，确保业务接口能够实现。

数据同步的问题。必须保证服务平台业务数据库的用户数据与业务系统的数据保持一致，因此要有一个定期数据校验和数据同步的机制。比如，一个用户的无线账号是可用的，必须定期到无线管理系统里检查这个账号的状态是否为可用，如果状态不正确，需要及时修正错误。